ROI Case File No.555: 'Members Vanished Just Because They Forgot a Procedure'
![]()
Members Vanished Just Because They Forgot a Procedure
Chapter 1: They Don't Want to Quit, Yet They Vanish
"We want to replace our membership-management system. Every year, about 500 people end up withdrawn without meaning to."
Masato Mawaritani, president of Globex Tech, described his situation as he spoke. His company runs a membership program called the Kaiyu system. "Free student members forget the procedure at each yearly renewal. That automatically treats them as withdrawn. They don't want to quit, yet 500 people vanish every year."
"Is the current system suited to membership management?" Claude asked.
"It isn't," Mawaritani answered. "It's been repurposed since around 2021 from a reservation system meant for sports gyms and lesson studios. As we changed the program a few times, the gap between the system and reality widened. For membership management like an academic society's, it no longer fits."
"By when do you want it running?" I asked, to confirm.
"By year's end," Mawaritani answered. "The 2026 budget is secured, and we want the automatic-renewal feature for free members running before next year's renewal. Rather than a perfect ideal form, we first want to stop the 500 from vanishing. Realization is the top priority."
"Rather than drawing the ideal, running it by year's end comes first," I replied. "Let's break it down with REALIZATION_FIRST."
Chapter 2: REALIZATION_FIRST Asks—Place Realization First
"This case calls for REALIZATION_FIRST."
Claude wrote "REALIZATION_FIRST" on the whiteboard.
"REALIZATION_FIRST—realization first—is an ROI Detective Agency original method that places, above the completeness of the ideal form, realizing something that works within the deadline first," I explained. "The key is narrowing the goal to a single point. This time, the goal is to 'stop free members from vanishing through missed renewals.' Pile on this feature and that, and it won't run by year's end. It's the tool that places realization first and builds from the features directly tied to the goal."
"Let's measure the current cost first," Gemini said, opening ROI Polygraph, and entered the data Mawaritani had provided.
"The monthly cost is in," Gemini read out. "Manual hours for deadline management and renewal procedures per membership type average 140 hours a month; at ¥3,800 an hour, that's ¥532,000 a month. Lost opportunity from membership fees and future value of the 500 annual withdrawals from free members' missed yearly renewals averages ¥600,000 a month. Operational workarounds and double management from program divergence due to the repurposed reservation system average ¥380,000 a month. Rework on withdrawal processing and roster reconciliation averages ¥280,000 a month. The risk of degraded member experience from being unable to keep up with program changes averages ¥260,000 a month. The total is ¥2,052,000 a month—roughly ¥24.62 million a year."
Mawaritani stared at the figures. "I thought it was just the fees from withdrawals. Once you include manual work and double management, I never imagined it would be this much."
"Then let's design it with REALIZATION_FIRST," I continued.
[Current-state analysis—Pin down the origin of the divergence]
"First, we pin down the divergence between the current system and reality," Claude said. "Where did repurposing a reservation system stop fitting membership management? Narrow the origin of the divergence and the scope to rebuild gets decided."
[Requirements definition—Place automatic renewal at the center]
"Next, we define requirements with free members' automatic renewal at the center," Gemini continued. "We fix the technical spec to automate deadline management per membership type. We put the feature directly tied to the goal at the core and push the rest to later. Because we don't pile on, we make the deadline."
[Development and verification—Work backward from year-end go-live]
"After requirements, we develop working backward from the year-end go-live," I continued. "We build the automatic-renewal feature first and confirm through testing that it reliably runs. Rather than aiming for the ideal form all at once, we bring the minimal form that fulfills the goal to a state that runs within the deadline."
[Go-live—Place realization first]
"Finally, we go live by year's end," Claude continued. "Rather than waiting for perfection, we run the feature that first stops the 500 from vanishing. After it's running, we add the member-experience improvements. It's a structure that places realization first."
[Estimating the payback]
"Let's run the numbers with ROI Proposal Generator," Gemini proposed.
- Initial cost: New membership-management system build, automatic deadline management per membership type, a free-member automatic-renewal feature, and existing-data migration—¥4,800,000 total
- Monthly cost: System operations and ongoing maintenance combined—¥200,000 a month
- Monthly savings: Withdrawal prevention through automatic renewal (fee recovery) = ¥580,000 a month; automated deadline management = ¥400,000 a month; double management eliminated = ¥300,000 a month; rework on withdrawal processing reduced = ¥220,000 a month; ¥1,500,000 a month total
- Net monthly savings: ¥1,500,000 − ¥200,000 = ¥1,300,000 a month
- Payback period: ¥4,800,000 ÷ ¥1,300,000 = about 3.7 months
"Payback in just under four months," Gemini summarized. "What works is realizing from automatic renewal, which is directly tied to the goal, rather than chasing the ideal form. Pile on features and it won't run by year's end, and the 500 vanish again. Because you place realization first, it runs within the deadline and the withdrawal outflow stops. The investment doesn't whiff."
Mawaritani said, checking the figures, "I'd been trying to build a perfect system. Place realization first, and the outflow you should stop first comes into view."
"REALIZATION_FIRST is the tool that places realization before the ideal," I replied.
Chapter 3: A Rollout Plan That Works Backward from Year-End Go-Live
"Let me lay out the approach," I said, standing at the whiteboard.
"Month 1—analyze the current system's divergence and fix the scope to rebuild. Month 2—define requirements with free-member automatic renewal as the core. Months 3–4—develop the automatic-renewal feature and per-type deadline management. Month 5—migrate existing data, test, and prepare for the year-end go-live. Month 6—begin operation and verify the effect. Month 7 onward—add member-experience improvements and settle in operations."
"Will it really make it by year's end?" Mawaritani asked, to confirm.
"It will make it," Claude replied. "It fails to make it because you try to build the ideal form all at once. With REALIZATION_FIRST, we've narrowed the goal to automatic renewal and pushed the rest to later. Because you run only the core feature within the deadline, it makes the yearly renewal. Place realization first and the outflow of 500 people stops this year."
Mawaritani said, taking notes, "Before drawing the ideal, place realization first. The order was backwards."
Chapter 4: The Day the Vanishing 500 Remained
Nine months later, a report arrived from Mawaritani.
Free-member withdrawals dropped sharply after the automatic-renewal feature went live. "Student members who'd been vanishing because they forgot the procedure now get renewed automatically. People who didn't want to quit properly remained," Mawaritani had written.
The manual work of deadline management vanished, too. Deadlines per membership type are managed automatically, and they're no longer chased by withdrawal processing. "The work of cross-checking the roster by hand and processing withdrawals is gone," the report said.
The biggest change appeared in how they got it done in time. From a state stalled aiming for perfection, they could realize something that runs by year's end. "We'd kept drawing the ideal form forever and lost 500 people every year. Once we placed realization first, it ran by the yearly renewal. This year, no one vanished," Mawaritani had written.
The divergence from the program also headed toward resolution. The strain of repurposing a reservation system was replaced by a design suited to membership management. "Even when we change the program, the system can now keep up," the report said.
As a secondary effect, the way development was pursued changed. The idea of placing realization first took root inside the company. "We stopped 'moving only after waiting for perfection.' We came to proceed with 'put out something that works within the deadline first,'" Mawaritani had written.
At the end of his report, he wrote: "I thought the membership-management trouble was that the system was old. But the real problem was chasing the ideal form and being unable to get it running by year's end. The moment we placed realization first with REALIZATION_FIRST, automatic renewal made it in time. Before drawing the ideal, realizing it came first."
The day a company where members vanished just because they forgot a procedure became a company that could stop them from vanishing, the system overhaul had changed from the pursuit of an ideal form into a design that places realization first and runs within the deadline, the report noted.
"System-overhaul requests usually come in the form of 'we want to build the ideal system.' But there's something to ask before drawing the ideal. What is the outflow you most want to stop, and by when do you run it? What REALIZATION_FIRST asks is the top priority of realization. Run the feature directly tied to the goal within the deadline and the outflow stops this year. The day a company where members vanished just because they forgot a procedure could stop it, what changed wasn't the system's newness but the very perspective that places realization before the ideal."
Related Files
Tools Used
- ROI Polygraph — Visualizing deadline-management hours, the lost opportunity of missed-renewal withdrawals, and double-management cost
- ROI Proposal Generator — Payback simulation for a membership-management system overhaul starting from realization first