← Back to list

Summary card

EN 2026-08-02 23:00
BOMSales Forecasting AINew Store Openings

TechNova's new-store sales forecasting AI consultation. How BOM decoded the bias of grading a location in one lump, and a design that breaks revenue into parts and builds it back up.

ROI Case File No.584: They Judged the Location as a Whole and Never Broke It into Parts

EN 2026-08-02 23:00

ICATCH

They Judged the Location as a Whole and Never Broke It into Parts


Chapter 1: The Forecasts Miss, and No One Can Say Why

"We want to forecast new-store revenue accurately using AI."

Tsumu Kumita of TechNova's marketing department said this as he laid out the situation. "Right now we forecast from past experience and map-based statistics. Population, age composition, that sort of thing—and someone assembles it by hand. The problem is, it misses."

"How does it miss?" Claude asked.

"Two locations with roughly the same population and age composition can end up with nearly double the difference in actual revenue," Kumita answered. "We can't explain why. We're short-staffed and the schedules are tight, so the data preparation gets sloppy. And we use that for store-opening decisions, which frightens me."

"When it misses, can you tell which part missed?" I confirmed.

"...We can't," Kumita answered. "We've been judging the location as a whole, good or bad. What elements the revenue is made of, and which of them we misread. We've never broken it into parts."

"Judged as a whole, you can't locate where it went wrong," I replied. "Let's break this down with BOM."

Chapter 2: BOM Asks—Split Revenue into Parts and Build It Back Up

"This case calls for BOM."

Claude wrote "Decompose / Scale / Build Up" on the whiteboard.

"BOM—the bill of materials—is a framework for splitting a finished product down to its component parts, giving each part a quantity and a specification, and building it back up," I explained. "The essence is not handling the result as a lump. Revenue works the same way: it splits into foot traffic, entry rate, average spend, and visit frequency. Put a scale on the vague words. Once each part carries a number, you can build up a forecast—and when it misses, trace it to which part was wrong."

"First, let's measure the current cost," Gemini said, opening ROI Polygraph. The data Kumita provided went in.

"The monthly costs are out," Gemini read off. "Manual data preparation and forecast creation averages 155 hours per month; at ¥4,000 per hour, that's ¥620,000 per month. The risk of wrong store-opening decisions from insufficient forecast accuracy averages ¥460,000 per month. Quality degradation from thin staffing and tight schedules averages ¥320,000 per month. Analysis gaps that overlook factors beyond population and age average ¥340,000 per month. Lost opening opportunities from delayed decisions average ¥340,000 per month. The total is ¥2,080,000 per month. Annualized, roughly ¥24,960,000."

Kumita stared at the figures. "I was only looking at the effort of producing forecasts. Once you add the risk of a wrong decision and the properties we lost by being late, it comes to this much."

"Then let's design with BOM," I continued.


[Decompose—Split revenue into its component parts]

"First, decomposition," Claude said. "Split revenue into foot traffic, entry rate, average spend, and visit frequency. Then split foot traffic further by time of day and weekday versus weekend. Population and age composition are materials for estimating those parts—they are not the revenue itself."


[Scale—Put a measure on the vague words]

"Next, scale," Gemini continued. "Bustle, approachability, visibility. The words your staff have been using carry no numbers. Pedestrian counts, frontage width, distance to the signage, position of the traffic light. Put a scale on them and the difference between two locations lines up in figures."


[Build Up—Assemble the parts and produce the revenue]

"After scale, the build-up," I continued. "Multiply the part values together and stack them into a revenue figure. Train the coefficients per part on the results of existing stores. Because it's a build-up of parts rather than a lump forecast, you can show your grounds and explain them."


[Variance—Name the part that missed and fix it]

"Last, variance," Claude continued. "Compare post-opening results against the forecast part by part. Was it only the entry rate that came in low, or was average spend the misread? Because you know which part missed, the next forecast reliably improves."


[Calculating the payback]

"Let's run the numbers with ROI Proposal Generator," Gemini proposed.

  • Initial cost: Revenue part-decomposition design, scaling of the indicators, existing-store data preparation, forecasting AI model build, and result-matching mechanism — ¥4,900,000 total
  • Monthly cost: AI platform usage fees plus ongoing model maintenance — ¥220,000 per month
  • Monthly savings: Automation of forecast production = ¥480,000 per month (assuming a 70% reduction), avoidance of wrong opening decisions through improved accuracy = ¥360,000 per month, elimination of analysis gaps = ¥280,000 per month, elimination of quality degradation from schedule pressure = ¥260,000 per month — ¥1,380,000 per month in total
  • Net monthly savings: ¥1,380,000 − ¥220,000 = ¥1,160,000 per month
  • Payback period: ¥4,900,000 ÷ ¥1,160,000 = approximately 4.2 months

"A payback of just over four months," Gemini summarized. "What makes it work is not scoring the location as a lump, but splitting it into parts and building it up. As a lump, you never learn why it missed, and accuracy never improves while you rebuild from scratch every time. With parts, you fix only the place that missed. The investment doesn't swing at air."

Kumita looked over the figures. "I thought a good AI would hit the mark. Without splitting what we're forecasting into parts, the AI has nothing to learn from either."

"BOM is a tool for splitting the result into parts and building it back up," I replied.

Chapter 3: An Implementation Plan That Splits into Parts

"Let me lay out how to proceed," I said, standing at the whiteboard.

"Month one—decompose revenue into parts and inventory existing-store data. Month two—scale the vague indicators and standardize measurement methods. Months three and four—build the forecasting AI model and validate on existing stores. Month five—trial forecasts on candidate sites and transition staff to the new process. Month six—match against opening results and adjust the coefficients. Month seven onward—continuous review of parts and coefficients, and expansion to more store formats."

"If we just let the AI learn all our past revenue, accuracy would come out, wouldn't it?" Kumita asked.

"Learn it as a lump and even a hit tells you nothing about why," Claude replied. "A forecast you can't explain can't be used for an opening decision. Split into parts and build up, and you can explain why the number is what it is, then fix only the part that missed. Deciding what the parts are comes before making it learn."

Kumita took notes. "Before building a forecasting model, split revenue into parts. I can see the order now."

Chapter 4: The Day They Split It into Parts and the Forecast Landed

Ten months later, a report arrived from Kumita.

Forecast accuracy rose sharply after the decomposition. "We can now explain the phenomenon of identical population and age composition producing different revenue. The hourly distribution of foot traffic and the entry rate were completely different," Kumita wrote.

The effort of producing forecasts dropped too. A mechanism that stacks up once the part values are entered erased the manual work. "The sight of staff wrestling with spreadsheets at midnight is gone. No more getting sloppy under schedule pressure," the report said.

The largest change showed up in how misses were handled. From grading the whole as good or bad, they moved to reading the variance part by part. "A miss used to end with 'our instincts were off.' Now we get which part was off by what percentage, and we can fix it next time," Kumita wrote.

Opening decisions got faster as well. Because the grounds could be shown as parts, approvals stopped stalling. "We can explain why this number. Decisions sped up, and we stopped losing good properties," the report said.

As a secondary effect, their handling of language changed. Putting a scale on vague descriptions took root. "We stopped reporting 'there's a lot of bustle.' Now we write how many of what, and how many meters," Kumita wrote.

At the end of Kumita's report, he had written: "I thought the forecasting problem was that our method was outdated. But the real problem was that we judged the location as a whole and never broke it into parts. The moment BOM split revenue into parts, both the reasons we hit and the reasons we missed became visible. Before building the model, breaking it into parts came first."

The day a company that had judged locations as a whole became a company that splits into parts and builds up, new-store revenue forecasting had changed from applying instinct and statistics into a design that decomposes revenue into parts and stacks them, the report noted.

"Sales-forecasting consultations almost always arrive in the form of 'we want an accurate AI.' But before you build the model, there is something to ask. What is that revenue made of? What BOM asks about is decomposition into parts, the scale, and the build-up. Split it into parts and you can name both the grounds for a hit and the location of a miss. The day a company that had judged the location as a whole managed to break it into parts, what changed was not the novelty of the forecasting method but the very perspective of splitting the result into parts and building it back up."


bom

Tools Used

  • ROI Polygraph — Visualizing forecast-production hours, decision-error risk, and opportunity loss from analysis gaps
  • ROI Proposal Generator — Investment-recovery simulation for new-store sales forecasting AI driven by decomposing and stacking revenue parts

Describe Your Case