Case 01
The shared software core concealed four different service undertakings
In 2023 we reviewed twelve customer programmes that used a shared software core. The commercial proposal treated that reuse as evidence for one standard service proposition. It was an appealing account: the provider had already developed relevant material, and the customer programmes appeared to demonstrate demand. The service-design review found a more qualified pattern. Eight programmes could fit the proposed standard undertaking, while four required materially different operating workflows. A common component did not make the customer's full requirement common.
The sales team wanted all twelve retained in the market story. It argued that excluding four would understate the provider's experience and make the standard proposition look narrower than the work already delivered. Minzhuo Qian, our fictional service-design director, objected to the implication that the same introduction and support model would serve every programme. I supported keeping both perspectives visible: the twelve demonstrated relevant experience, but only eight supported the particular claim of repeatability being proposed.
I recommended a standard proposition for eight and bespoke treatment for the other four. The response carried CNY 8.4 million in proposition and service-design expense. Engineering colleagues retained responsibility for technical suitability, while commercial and contractual owners examined what could actually be offered. I did not treat existing code as proof that reuse rights, permissions or support responsibilities were already settled. My contribution concerned the business description and the choice it asked the provider to make.
The decision gave up a broader standard-service claim and retained the work required to handle four programmes differently. That made the proposition less simple to market. It also prevented the full customer undertaking from being represented by the most reusable part of it. The four bespoke programmes did not become failures or inferior customers because they sat outside the standard offer. Their requirements remained legitimate; the question was whether they belonged inside the same commercial promise.
I use this case to explain why a service strategy needs evidence about the customer's operating problem as well as the provider's assets. Technical reuse can support a repeatable business, but it cannot establish the whole business case on its own. The useful outcome was an offer with a clearer boundary and a disclosed development cost. I do not claim a measured margin improvement or a universal eight-to-four rule from this fictional decision.