CUST.4:4 - Solution

CUST.4:4.1 - Translate the customer situation into consequential choices

Recover the intended result, operating environment, timing, recipient capability and constraints. Separate requirements from preferences. An inaccessible environment can rule out an offering; a preferred report layout may be an optional adaptation.

Use the family’s variation rules to identify live choices. Explain each in the customer’s terms: what changes in result, effort, delay, support or responsibility. Do not expose every internal parameter as a customer decision. A default is useful when its assumptions are visible and it does not conceal a consequential trade-off.

Check understanding where a term can change selection. “Managed” might mean software hosting to the provider and complete operating responsibility to the customer. Resolve that difference before comparing prices or configurations.

CUST.4:4.2 - Help the customer navigate the solution space

Eliminate combinations that violate a necessary condition. Compare the remaining alternatives by the differences that matter for the intended use. Present a manageable subset with the reason for exclusion or preference; preserve access to a qualified exception when the subset does not fit.

A direct configurator suits choices whose consequences the recipient can understand and whose rules are sufficiently expressed. Assisted selection suits unfamiliar consequences, coupled options or incomplete information. A demonstrated example can expose meaning better than another field in a form. Obtain the customer’s missing input only when it can change the choice.

Use defaults and recommendations as explained assistance, not hidden commitments. When a choice transfers work to the recipient, show that work. For example, customer-hosted delivery may require local monitoring, updates and access arrangements that provider-hosted delivery supplies differently.

The result is a selected or short-listed combination with fit grounds and remaining conditions. If no combination fits, say what fails and return the substantive difference. Do not add an unqualified option merely to make the form submit.

CUST.4:4.3 - Place common work and customer-dependent work

For each consequential activity, ask what information or commitment must be known before it can be performed correctly. This identifies the point where customer-specific work begins, often called the customer order decoupling point in production settings.

Compare at least the feasible early and late arrangements. Common preparation might include a base assembly, a tested module, a training method or a reserved service slot. Customer-dependent work might include final assembly, calibration, semantic mapping, local training or permission-dependent configuration.

Do not assume later is always better. Late calibration can become the bottleneck. Early software preparation can avoid customer delay but require maintaining many variants. Physical stock and software configuration have different cost and failure models; carry only the relevant dependence idea between them.

CUST.4:4.4 - Construct the complete chosen route

Follow the selected member from preparation to acceptance. Name the customer-dependent input, its supplier and required arrival time. Join it to the operation that consumes it. Resolve what happens if it is late, ambiguous or unusable.

Obtain an operating-capacity result through OPS.10 — Qualify Operating Capacity Under Variability when variability or a shared resource can defeat the timing. Receive more than an average utilization figure: use the relevant demand mix, waiting, variability, resource availability and supported operating conditions. Revise the differentiation point or promise if they do not fit.

Use CUST.6 where the route itself needs a repeatable delivery method. Use CUST.7 for the complete resource comparison. A configuration with a shorter quoted installation can be worse when qualification, customer preparation or support is included.

CUST.4:4.5 - Reopen the form of provision when it changes the answer

Sometimes the live alternatives are not variants of the same service. Buying an engineered result, receiving a maintained service and contracting for a bounded outcome distribute work and responsibility differently.

Use SYSE.8 — Develop an Integrated Offering and Provider Concept for Using an Engineered Result for its full integrated offering and provider-concept method when that engineered-result question applies. Supply the needed use result and candidate arrangement. Receive the contributing systems and parties, required customer participation, operating concept, observation and acceptance, responsibilities and risk conditions. Then test whether this concept fits the family, delivery capacity, resource comparison and existing commitments.

Observation alone is not influence over an outcome. A provider need not control every causal factor, but the promise must be compatible with its actual means, the other parties’ contributions, disturbances and the agreed consequences of failure. If the concept cannot support the proposed outcome, choose a narrower contribution, obtain further subject-specific evidence or decline that promise. CUST does not turn an industrial service concept into a general guarantee of health, learning or employment.

CUST.4:4.6 - Make the selected configuration usable and revisable

Give the recipient and delivery participants the chosen result, variations, required contributions, timing, support and acceptance conditions. Where choices are reversible, preserve a cheap return; where changing them later creates rework or obligation, make that consequence visible before commitment.

Return recurring no-fit requests to CUST.3 as evidence about the solution-space boundary. Return an isolated unsupported difference to CUST.2 for local disposition. Preserve the selected configuration identity for later support and CUST.8 transitions.