Solution as Four Relational Processes
When you need this method
You sell something you call a solution, but only the build is owned and measured: configure, integrate, ship. What comes before it, the joint clarification of what is actually to be solved, and what comes after it, dependable support in daily operation, has no owner, no schedule and no metric. The customer, however, judges the whole chain, and judges it hardest on the stretches you do not run.
Approach
- 1Name the four processes as separate parts of what you deliver: requirements definition, customisation and integration, deployment, post-deployment support. Each gets an owner, a schedule and its own sign-off.
- 2Run requirements definition as joint work rather than as collecting a list. Talk to several places inside the customer organisation, including those that do not place the order, and ask explicitly about needs the customer has not yet put into words.
- 3Describe post-deployment support before the signature, with response times, named contacts and recurring meetings. It is the process customers most often count as part of the solution.
- 4Give technical leadership of an engagement to the unit with the deepest knowledge of the customer's problem, even when that inverts the usual reporting line for the duration of the engagement.
- 5Keep the people who face the customer stable across process boundaries instead of swapping them after the close or after each project phase.
- 6Tie sales targets and compensation to what processes two through four can actually deliver, so that a close never promises what delivery cannot carry.
- 7Test the preconditions on the customer side openly and state them in the proposal: willingness to adapt internal routines, access to decision makers, guidance on the internal landscape.
Typical application
A typical B2B SaaS in maintenance planning sells a complete solution but internally runs only one project, from configuration to go-live. Requirements arrive as a list from procurement, and support afterwards runs through a ticket queue with no named contact. Renewal rates in year two slip even though the software runs without faults. The team splits the offering into the four processes, allots two weeks of requirements work with the workshop, scheduling and controlling, names one person for ongoing operation, and lets sales make commitments only with a counter-signature from delivery. Project duration goes up at first, follow-up demands after go-live drop sharply, and renewal conversations are no longer about disappointments from the first quarter.
Limits and counter-indications
The basis is a qualitative field study with 104 managers interviewed and two focus groups, collected around 2007 in mostly North American industrial and IT settings. It describes how customers see solutions and states the supplier and customer factors as propositions, not as measured effects. Reading a causal claim into it overstretches the source. Second, the model fits poorly where the problem is well structured and can be solved algorithmically: Nordin and Kowalkowski consider the close collaborative mode expensive rather than necessary in that case, and note that in practice the four stretches often run iteratively instead of cleanly in sequence. Third, solution business is no reliable path to better numbers. Worm and colleagues find the profit contribution weaker in technology-intensive industries and stronger where sales capability is high. Fourth, the rebuild costs something: shifting lines of authority, stable contacts and documentation duties tie up people. With very small annual contract values or in self-service products, processes one and three shrink so far that the effort is not covered.
How to measure impact
Measure each of the four processes on its own: duration and number of internal customer functions involved in requirements definition, gap between promised and achieved deployment date, tenure of your contacts on a given account, and the share of support contacts you initiate rather than the customer. Alongside that, gross revenue retention in the second contract year as the outcome measure.
Related methods
Tools for this
Sources
- 1.Tuli, Kohli, Bharadwaj: Rethinking Customer Solutions. From Product Bundles to Relational Processes, Journal of Marketing 71(3), 2007, 1-17 (opens in a new tab) · American Marketing Association / Journal of Marketing (Volltext über Athens University of Economics and Business, eClass) · 2007 · academic and scholarly literature · describes the methodCarries the procedure: from depth interviews with 49 managers in 25 customer firms and 55 in 29 supplier firms plus two focus groups with 21 participants, the paper derives that customers describe a solution as four joint processes. Customers name them at 76 percent (requirements definition), 86 percent (customisation and integration), 86 percent (deployment) and 92 percent (post-deployment support); suppliers name requirements definition at 7 percent, deployment at 4 percent and post-deployment support at 4 percent. The paper also describes five supplier and three customer factors. Limit: a qualitative, hypothesis-generating field study on a purposively selected sample; the factors are stated as propositions and are not tested in the paper, and there is no effect or causal measurement.
- 2.Worm, Bharadwaj, Ulaga, Reinartz: When and why do customer solutions pay off in business markets?, Journal of the Academy of Marketing Science 45(4), 2017, 490-512 (opens in a new tab) · Springer / Journal of the Academy of Marketing Science (Nachweis über RePEc IDEAS) · 2017 · academic and scholarly literature · evidence of effectivenessCarries the effectiveness question, though at the level of offering type rather than the four processes. On primary and secondary data from 175 manufacturers and correcting for endogeneity, solution offerings are associated with higher return on sales, estimated at roughly 2.45 percentage points. The association is stronger where sales capability is high and where buyer power is strong, and weaker in technology-intensive industries. The authors state that solutions are not a universal route to advantage. Limit: cross-sectional manufacturing data, no test of the process split by Tuli and colleagues, and no statement about individual process steps.
- 3.Nordin, Kowalkowski: Solutions offerings. A critical review and reconceptualisation, Journal of Service Management 21(4), 2010, 441-459 (Postprint der Universität Linköping) (opens in a new tab) · Emerald / Journal of Service Management (Postprint über Linköping University Electronic Press, DiVA) · 2010 · academic and scholarly literature · limits the methodCarries the counter-position and the boundary of application. The critical review of 28 subject-specific contributions concludes that there is no unanimous and rigorous definition of a solution and that part of the literature is normative and oriented towards success stories. On the process view of Tuli and colleagues it holds that the close collaborative mode is mainly warranted for ill-structured problems, and that with heuristic problem solving the stretches are run iteratively rather than in sequence. Limit: a conceptual paper with no data collection of its own, and by the authors' own account the selection of contributions may have been too narrow.
Origin: Tuli / Kohli / Bharadwaj