ROI Case File No.509 'A Double-Booking Near-Miss in Demo Reservations'
A Double-Booking Near-Miss in Demo Reservations
Chapter One: Where Is That Demo Unit Right Now?
"'Where is that demo unit right now?'—we get that question many times a day."
Kei Tsubakihara, Sales Planning Manager at PineTech, opened the spreadsheet. The demo-unit management table. "Model, who borrowed it, borrowed date, return date, current location—the fields are there, but updates can't keep up. The actual location of items lives in the head of the manager."
"How many demo units and how many sites?" Claude asked.
"Twenty model types, one to three units each, about forty-five units in total," Tsubakihara answered. "Eight sites nationally. Demos happen at customer sites, so units move between sites frequently. Last month, we had a double-booking near-miss. Two sales teams reserved the same demo unit for the same day. The manager noticed just in time and prevented it, but if they had been on leave, it would have broken down."
"What's the current management method?" I asked.
"A spreadsheet and Salesforce calendar," Tsubakihara answered. "The spreadsheet is the inventory list; the calendar is the reservation status. One manager runs operations by cross-referencing both. There's no backup when they're away."
"Is there a list of requests?" Gemini asked.
"There is," Tsubakihara answered. "Fifteen feature requests from the field. We can't prioritize them, and the systemization conversation is stalled. We can't decide what to build first."
"There's no decision axis for priorities," I replied. "Let's decompose with RICE."
Chapter Two: RICE Asks—Four Indicators to Pick Features
"This case calls for RICE."
Claude wrote four letters on the whiteboard. R, I, C, E.
"RICE is a framework that decides feature priority through four indicators—Reach, Impact, Confidence, and Effort," I explained. "It's widely used in product development, but it works for internal systems too. When requests are many, implementing all is impossible. Score each on Reach (scope of impact), Impact (size of effect), Confidence (likelihood of effect), and Effort (work required), and priority emerges mechanically."
"First, let's measure the current cost," Gemini said, opening ROI Polygraph. He input the data Tsubakihara provided.
"The monthly management cost has come out," Gemini read. "The manager's demo-unit management labor averages 140 hours per month at 3,800 yen per hour, or 532,000 yen monthly. Inquiry-response labor—confirmation calls to the manager—averages 60 hours per month, or 228,000 yen monthly. The expected value of double-booking near-miss risk averages 800,000 yen monthly—probability of error during manager absence times impact. Duplicate inter-site shipping cost from unknown demo-unit locations averages 300,000 yen monthly. Opportunity loss from inability to optimize demo-unit utilization averages 400,000 yen monthly—idle units we can't see, leading to unnecessary additional purchases. Total: 2.26 million yen monthly. Annualized: approximately 27.1 million yen."
Tsubakihara looked at the figures. "I'd been thinking about isolated incident prevention. Annual view changes the meaning."
"Now let's design with RICE," I continued.
[Score the Fifteen Requests on Four Indicators]
"Score the fifteen requests on four indicators," Claude said. "Reach is how many people will use the feature. Impact is the size of the operational improvement. Confidence is the likelihood that expected effect is achieved. Effort is the work to develop it. Score each from one to ten, then compute Reach × Impact × Confidence ÷ Effort to derive priority."
"Can these be quantified?" Tsubakihara confirmed.
"They can," I replied. "Subjectivity will enter, but using multiple evaluators and averaging scores reduces the variance."
[R—Reach: Scope of Impact]
"On Reach, measure how many people use the feature," Gemini continued. "A 'demo unit search and reservation' feature used daily by 150 sales staff has the maximum Reach. An 'annual utilization report' used once a year has small Reach. Higher Reach means higher priority."
[I—Impact: Size of Effect]
"On Impact, measure the size of operational improvement," I continued. "The lock feature to prevent double-booking has extremely high Impact. UI color changes have small Impact. We evaluate both incident-prevention and efficiency angles."
[C—Confidence: Likelihood of Effect]
"On Confidence, measure the likelihood that the expected effect materializes after implementation," Claude continued. "An integration with existing systems is technically verifiable, so confidence is high. A novel feature like AI demand prediction has lower confidence. Low-confidence items go later or get stage-gated validation."
[E—Effort: Work Required]
"On Effort, measure the development work," Gemini continued. "Effort is in the denominator, so lower means higher priority. Of the fifteen requests, three with extremely high Effort are excluded from this scope and parked for separate review. The remaining twelve are ranked."
[Scoring Results and Phased Deployment]
"Integrating the four indicators gives the priority ranking," I continued. "Top five: 'demo unit search and reservation,' 'automatic double-booking prevention,' 'real-time current-location display,' 'inter-site movement request workflow,' 'automatic usage history recording.' These are Phase 1. Middle four are Phase 2; lower three are Phase 3. Each phase has an independent investment decision."
[Estimating the Payback]
"Let's run it through ROI Proposal Generator," Gemini proposed.
- Initial cost: 5.2 million yen (Phase 1 development of top five features, Salesforce integration, data migration, training)
- Monthly cost: 160,000 yen (system operation and maintenance)
- Monthly savings: manager labor reduction = 370,000 yen (70% reduction assumed); inquiry-response reduction = 180,000 yen; double-booking risk reduction = 600,000 yen; duplicate shipping reduction = 210,000 yen; utilization optimization = 320,000 yen. Total: 1.68 million yen monthly
- Net monthly savings: 1.68 million − 160,000 = 1.52 million yen
- Payback period: 5.2 million yen ÷ 1.52 million yen ≈ 3.4 months
"Under four months," Gemini summarized. "Phase 1 alone covers most of the current cost. Phases 2 and 3 target additional improvement. Each phase is an independent decision."
Tsubakihara looked at the numbers. "I'd been thinking about deciding on all features as a single investment. Phasing makes the decision realistic."
"RICE is also a selection tool," I replied.
Chapter Three: A Phased Plan Along Four Indicators
"Here's the implementation plan," I said, standing at the whiteboard.
"Weeks 1–2: RICE-score the fifteen requests, review with the field. Week 3: finalize Phase 1 requirements, decide on vendor or in-house build. Weeks 4–10: Phase 1 development, data migration design. Week 11: pilot operation, field training. Week 12: production launch, phase out the spreadsheet workflow. Week 13 onward: three-month effect measurement. Phase 2 investment decision at month 4."
"How do we integrate with Salesforce?" Tsubakihara confirmed.
"The calendar function stays in Salesforce," Claude replied. "Reservation entry point is Salesforce; demo-unit inventory is the new system; the two integrate via API. Daily sales work completes in Salesforce. Floor process change is minimized."
Tsubakihara made a note. "Being able to mechanically derive priorities makes the discussion fast."
Chapter Four: The Day the Manager Could Take Time Off
Seven months later, a report arrived from Tsubakihara.
Three months after Phase 1 launch, demo-unit management inquiries fell 82% versus baseline. Sales could directly check inventory and reservations on the system, and confirmation calls to the manager nearly disappeared. "The manager used to be unable to take vacation. They can take vacation normally now," Tsubakihara wrote.
Double-booking became structurally impossible. Inventory locks at reservation time, and double bookings are simply not accepted. "What had relied on human attention shifted to a rule," the report said.
The most surprising change appeared in demo-unit utilization. Per-model usage frequency became visible in data, and surplus models versus undersupplied ones became clear. Surplus models were dropped from new purchases; undersupplied models got additional buys. "Utilization analysis adjusted annual additional investment by about 2 million yen," Tsubakihara wrote.
Phase 2 discussions began on schedule. With Phase 1 effects visible, Phase 2's four features became easier to approve. "It's easier to align on additional investment in a project where numbers are clear," the report said.
As a side effect, sales motion changed. Sales could pick demo dates from multiple options on the system, raising scheduling flexibility. "Used to be we couldn't move without checking with the manager. Now we move on our own timing," the field survey said.
Person-dependence dissolved. Knowledge that had been concentrated in one manager was replaced by rules and data in the system. "Even if the manager rotates, operations don't stop," Tsubakihara wrote.
The final line of the report read: "We were stalled for six months on what to build first among fifteen requests. With RICE four-indicator scoring, the ranking was set in two weeks. With a framework, priority decisions move fast."
The day the thrill of double-booking near-misses disappeared, the manager's PTO usage rose, the report said.
"When multiple feature requests exist, you stall on what to build first. Without a decision axis, the loudest voice wins—or trying to do everything stalls everything. RICE asks for mechanical ranking through Reach, Impact, Confidence, and Effort. Replace person-driven discussion with numbers. In a sales organization with a double-booking near-miss in demo reservations, the day four indicators narrowed the features, what had been stalled wasn't development but the very axis of decision."
Related Files
Tools Used
- ROI Polygraph — Visualizing management labor, double-booking risk, and utilization opportunity loss
- ROI Proposal Generator — Payback simulation for phased deployment
