ROI Case File No.446 'The 30,000-Call Wall and the Invisible Ocean'
![]()
The 30,000-Call Wall and the Invisible Ocean
Chapter 1: A Pitch That Never Lands for Small Stores
"When we approach bicycle shops or dollar store chains, they always say 'too expensive.' But they're exactly the customers who need this system the most."
Ayaka Hashimoto, Product Manager at Globex Corporation, spread out a customer list as she spoke. The company offers a facility repair request management system for supermarkets — when in-store equipment breaks down, staff take a photo with their smartphone and send it, automatically dispatching the repair vendor.
"Our current customers are primarily large general merchandise chains and grocery supermarkets. They can afford the system costs. But the market we really want to expand into is small-format chains with high store counts. A dollar store chain with a thousand locations nationwide generates a proportionally high volume of repair requests. The need is clearly there."
"Why doesn't the pricing work?" I asked.
"The current system is built on a customized version of an app from a startup. The cost structure stacks up initial fees plus a monthly subscription — that's manageable for large chains but heavy for small operators. And —" Hashimoto frowned. "The API call limit is 30,000 per month. With a thousand locations, that's only thirty calls per store."
"The push notification issue too?" Gemini confirmed.
"Yes. Implementing emergency notifications to repair vendors requires plugin development, which triggers additional costs. The current structure fits our existing customer scale but wasn't designed with growth in mind."
"So," Claude summarized, "entering the small-format market with the current system runs into three walls: cost, API limits, and missing features. Yet small-format chains could be the next growth engine."
Hashimoto nodded. "Our competitors are fighting over large chains right now. As long as we stay in that market, competition will only intensify."
Chapter 2: A Map Out of the Red Ocean
"This case calls for Blue Ocean Strategy."
Gemini drew two oceans on the whiteboard. The red ocean: the existing large supermarket market. The blue ocean: the untapped small-format chain market.
"The essence of Blue Ocean Strategy," I began, "is not fighting in a competitive existing market, but creating a new market with no competition. That said, simply moving to a new market isn't enough. You need to simultaneously redesign the cost structure and the value proposition to enter it."
"What's blocking the entrance to the blue ocean here," Claude continued, "is a technology problem. The current system wasn't designed for the small-format market. So the first step in Blue Ocean Strategy is changing the choice of technical foundation."
[Redesigning value with four ERRC actions]
"We'll use the ERRC framework from Blue Ocean Strategy," Gemini said, drawing four boxes on the whiteboard: Eliminate, Reduce, Raise, Create.
"Eliminate: Remove the high upfront costs and complex customization structure of the current system. Strip away features small-format chains don't need and convert to a zero-upfront subscription model."
"Reduce: Reduce API dependency," Claude explained. "The monthly 30,000-call limit comes from an architecture built for high-volume data processing. By migrating to no-code/low-code tools, the API call structure itself can be redesigned, eliminating this constraint."
"Raise: Increase deployment speed," I continued. "The current system takes an average of six weeks to onboard a new customer. With no-code/low-code and standardized templates, new chain deployments could be completed within a week. A thousand-location chain suddenly becomes viable."
"Create — and this is the most important," Gemini emphasized. "Build a usage-based pricing model for small-format chains. Locations with few repair requests pay less; those with more pay more. Contracting at the chain level gives Globex stable recurring revenue and gives customers fair cost allocation."
"Consider exploring the tools available on 321 Platform," Claude added. "Integrating low-cost AI tools for automatic repair request classification could further increase the automation rate from intake to vendor assignment. An add-on value that even small-format chains can operate without adding headcount."
Chapter 3: Where the Color of the Ocean Changes
Hashimoto photographed the four ERRC boxes, eyes lighting up.
"I'd been only thinking about how to reduce costs within the current system. But what really needed to change wasn't the system — it was the business model."
"What Blue Ocean Strategy asks," I replied, "is whether you can stop fighting on the same battleground as your competitors and create something customers genuinely want but no one is providing. Small-format chains have always been there. We just couldn't reach them with the existing system."
"For the no-code/low-code tool selection," Gemini proposed, "make three conditions mandatory. First, API call limits are effectively unlimited or the cost is usage-based. Second, push notifications are available as a native feature. Third, production launch is possible within one week from a standard template. Narrow down to two vendors meeting those three criteria and run parallel testing with one pilot customer."
"For pilot customer selection," Claude added, "choose the business category with the highest repair request frequency among small-format chains. The higher the repair volume, the more visible the ROI of the usage-based model becomes. That number becomes your next sales weapon."
Hashimoto stood up. "Next week, I'll show this ERRC to the internal development team and start the no-code/low-code candidate shortlist."
Chapter 4: Toward the Ocean Where a Thousand Stores Wait
After she left, Gemini murmured: "The small-format chain market was always there. It just wasn't visible."
"Blue Oceans aren't somewhere far away," I answered. "They appear when you shift your perspective just slightly from existing competition. In Hashimoto's case, the wall wasn't the API limit, or the price, or even the features — it was the design philosophy of the technical foundation itself. Change that one thing, and the road to a thousand stores opens up."
Outside, the evening city was lighting up, small store by small store.
Six months later, a report arrived from Hashimoto.
Migration to the no-code platform was complete. Rollout to two hundred eighty stores of a dollar store chain had begun. Average deployment time: nine days per chain. The usage-based pricing model was well received by customers, with zero churn in the first month.
The API constraint was fully resolved. Push notifications were implemented as a native feature, and emergency vendor response time dropped sixty percent compared to the previous system.
Hashimoto's report read: "Studying Blue Ocean Strategy made me realize we hadn't been fighting competitors — we'd been fighting our own system. The day we changed the technical foundation, the sales conversation changed. Instead of price negotiations, we started talking about deployment plans."
The 30,000-call wall was no longer there.
"Blue Ocean is not about finding a market with no competitors. It's about meeting the needs customers had given up on, with a new cost structure and value proposition. Technical foundation choices define the limits of the business. What the ERRC framework asks is: what do we eliminate, and what do we create? Every constraint eliminated reveals a market that couldn't be seen before."
Related Files
Tools Used
- 321 Platform — Integration of low-cost AI tools for automatic repair request classification