CUST.1 - Manage Client Variation and Develop Repeatable Offerings

Type: Method pattern Status: Stable

CUST.1:1 - Problem frame

Use this method when a customer difference affects both a particular result and the offering you expect to provide again. Typical signs are a successful workaround with an unclear support future, an integration sold before anyone has accepted its maintenance, or repeated services that still depend on their original author.

The first move is to place the actual supported offering beside the intended customer result and explain what must change. This exposes a choice richer than “standard product or bespoke project”: a common component, a repeatable assisted service and a local adaptation may belong in one feasible answer.

If the current offering already fits and can be provided under its ordinary conditions, use it. If only one bounded difficulty remains, enter the relevant smaller method. The full composition is useful when local and shared choices constrain one another.

CUST.1:2 - Problem

Local urgency tends to make the next delivery decisive. Shared development tends to treat local work as a source of product requests. Neither view alone settles who may promise what, which work is funded, whether another performer can repeat it or what happens to existing customers. The missing result is a jointly supportable continuation, not another list of improvement ideas.

CUST.1:3 - Forces

CUST.1:4 - Solution

CUST.1:4.1 - Recover the two receiving results

Describe what the customer needs to be able to do, with whom, under which conditions and by when. Identify the evidence of an adequate result and the parties whose acceptance matters. Then recover the provider’s present offering: supported inputs, configurations, delivery work, assistance, exclusions and continuing obligations. Use the actual agreement and operating practice, not only the sales description.

Ask separately what the present case needs and what a later customer or performer might receive. The second result might be a reusable component, an extension, a delivery method, a training contribution or no common change. Treat it as a candidate until its scope and provision are supported. A local success does not select its shared form.

Keep any sufficient result already available. An earlier qualified configuration can settle a technical choice while leaving a new response-time promise unresolved. Carry that remaining difference into the work; do not reopen the settled configuration merely to make every case follow the same sequence.

CUST.1:4.2 - Turn the differences into compatible alternatives

Work backward from the missing customer result, then forward through the proposed delivery. Compare inputs, meanings, operations, decisions, access, help, acceptance and support with the supported basis. The constructive method in CUST.2 explains this recovery. Its result must tell the receiving decision what differs and why it matters, rather than merely naming a route.

Develop at least the materially different feasible continuations. These can include the supported offering unchanged, an allowed configuration, a bounded local adaptation, a shared component or family extension, a repeatable service, a partner contribution, a narrower promise and refusal. Combine them when their conditions fit. A partner can perform a repeatable service built around a common component while one report remains local.

For each serious alternative, trace the customer’s complete result. A technical adapter is incomplete if nobody can operate it. A paid exception is incomplete if the fee does not obtain the needed specialist. An outcome promise is incomplete if the provider arrangement and evidence cannot support its stated responsibility. Use the corresponding full professional method to obtain that missing result, then bring its conditions back into the alternative.

CUST.1:4.3 - Make the consequential decisions governable

Before an irreversible promise, identify who can contribute and decide the following matters in this case. These are decision-bearing contributions, not a mandatory headcount or organization chart.

Name the person or group with actual authority for each live decision, the inputs they need, the next decision time and the conditions they may not waive alone. The person making the customer promise needs the joined answer, even when another party supplied each contribution. A roadmap intention is not that answer.

One competent person may supply several contributions. Keep the distinctions visible in the decision itself: “I can implement this locally; I have not committed the product team to support it.” Seek independent judgement when incentives, uncertainty or consequences make self-approval unreliable, or when applicable professional conditions require it. The independence may concern one consequential evidence claim rather than every small change. Reconsider bundled responsibilities when workload, value at risk or disagreement makes the arrangement ineffective.

When actual positions, assignments or enabling relations must change, use OCE.5 — Define Organization Positions and OCE.6 — Establish Holder Assignments and Enabling Relations for Organization Change. Receive an arrangement with real decision rights, capability, time and access, then use it here. Naming six roles does not supply any of those conditions. If a required authority or resource is absent, narrow or defer the dependent promise while preserving independent permitted work.

CUST.1:4.4 - Obtain the missing contribution without losing the whole

Choose the next action by the uncertainty that can change the alternative. A known local modification needs implementation, not a research programme. A disputed meaning needs semantic work. Uncertain transfer may need a field inquiry. A capacity conflict needs an operating answer.

For customer inquiry, MKT.12 — Investigate a Customer or Market Question for a Decision supplies the question, discriminating evidence and permitted information use. For implementation difficulty, IS.1 — Agree a Useful Implementation-Support Undertaking and IS.2 — Find the Implementation Difficulty and Obtain the Next Useful Contribution establish the undertaking and the next useful contribution; IS.3 — Construct and Adapt a Support Strategy with Its Recipients constructs support with its recipients. Receive their bounded result, not just a completed activity. For example, “the team has attended training” does not yet settle whether the deployment is obtainable.

Use CUST.5 when field work must answer both the local question and a shared-development question. Preserve stopped, inconclusive and local-only outcomes. Protect current service while the question is open. If a result changes the interpretation of the customer’s need or the supported basis, return to those affected choices before continuing.

CUST.1:4.5 - Construct the common continuation and its delivery

When sharing could help, build the family through CUST.3: common result and conditions, invariants, allowed variations, forbidden combinations and the local residue. The same artifact can belong in one family and be unusable in another because support, permission or customer work differs.

Make a customer choice through CUST.4. Join that choice to the actual delivery method through CUST.6. The resulting package of explanation, tools, preparation and support must obtain the intended result for another prepared performer; it need not eliminate all assistance.

A technical platform decision remains with its engineering method. Obtain the architecture, interface or supported-use result and use it to define the family and delivery conditions. If it supports only a narrower class, narrow the offering rather than treating technical approval as permission for every customer promise.

CUST.1:4.6 - Join economics, responsibility and present customers

Compare the complete alternatives on the same result, period and customer set. CUST.7 includes common preparation, local execution, qualification, specialist help, support, migration and retirement. Distinguish an investment from an ordinary delivery charge and from an existing obligation. Confirm that funding and capacity exist when needed.

For a changed engineering offering or outcome arrangement, obtain the complete concept through SYSE.8 — Develop an Integrated Offering and Provider Concept for Using an Engineered Result. Bring back the participating systems and parties, contributions, responsibility, operating conditions, observation and acceptance, and the risks retained by each party. Use that result to revise the family, resource comparison and customer agreement. No method here guarantees a social or clinical outcome merely because a technical deployment works.

Use CUST.8 before a common change affects existing customers. Reconcile their configurations, results, support and promises with the proposed release. A technically compatible interface can still change an agreed operating burden.

The joint decision must hold together: the customer can obtain the result; the selected local and common forms are permitted and supported; the required work fits actual means; existing obligations have a feasible continuation. Failure of one condition reopens the dependent choice. It does not erase every useful result already obtained.

CUST.1:4.7 - Close a bounded result and retain its return

Finish with an executable local continuation and a distinct shared-development disposition. Examples are “deliver the existing configuration,” “provide the local service with funded specialist help; investigate a common adapter separately,” or “decline the unsupported outcome promise while offering a bounded contribution.”

Leave the receiving participants able to recognize what was decided, what remains uncertain, who supplies the next contribution and what change reopens the decision. A short agreed explanation can suffice.

Return recurring practice results to the general knowledge they test. If every transferred deployment needs its author, distinguish a defect in this family from a wider mistaken claim about what makes delivery repeatable. Revise that claim only on appropriate grounds; local exceptions must not indefinitely protect an unsupported general rule.

CUST.1:5 - Archetypal Grounding

A provider offers an analytical service from a standard batch file. A new customer requests private hosting, SSO, a different meaning of “active account,” a local report and urgent support. The service lead begins with the customer’s decision use: a monthly eligibility decision, not merely a dashboard installation.

CUST.2 separates the five differences and their dependencies. The identity provider already fits a supported interface. “Active” requires a semantic answer before the computation can be accepted. Private hosting needs a bounded field attempt. The report can remain a local service. Urgent support competes for an existing specialist.

The lead and field engineer are the same person, but that person cannot commit the product maintainer’s future support. The customer accepts the eligibility meaning; the engineer proposes the deployment; the product maintainer decides the common interface; the delivery lead supplies a repeatable run; the capacity holder commits support; an appropriate independent specialist checks the consequential security claim. Several contributions can be supplied by the same people, but no disagreement is silently converted into a promise.

A successful private-hosting attempt yields a family candidate with two supported environments and an explicit exclusion for disconnected operation. The delivery team receives a rehearsed setup method with scheduled specialist assistance. The report remains local. A wider rollout waits because the support resource cannot yet cover both existing customers and the new response time.

Change the condition: materials obtained for the first customer cannot be shared with a partner. Local provision may continue. The family and delivery work must obtain permitted alternative material or stop that transfer. A technically successful package is not the whole answer.

In a public library service, the same composition can connect local language and accessibility needs with reusable teaching materials and supported facilitators. Funding and workload replace customer margin as the relevant resource questions. Educational effectiveness still requires educational grounds; the framework supplies no guarantee of employment from attendance.

CUST.1:6 - Bias-Annotation

The method makes coordination visible and can encourage over-organization. Use the smallest actual arrangement capable of the decisions. A small team can retain one customer contact and combine compatible contributions. Cases with infrequent customization may be better served by a known local method than a maintained family.

The examples emphasize observable delivery. Less tangible service results require appropriate subject expertise rather than a convenient proxy such as document completion.

CUST.1:7 - Conformance Checklist

• Can the participants distinguish the customer’s result from the proposed common result?
• Are consequential differences recovered from real work, including assistance and continuing support?
• Do the people making promises have the required contributions and authority?
• Does the selected combination have compatible conditions, resources and evidence?
• Are local-only, unchanged, stopped and inconclusive outcomes allowed?
• Can existing customers continue under supported obligations?
• Can the next recipient act without reconstructing the missing joins privately?

CUST.1:8 - Common Anti-Patterns and How to Avoid Them

One person decides everything implicitly. Keep the live decisions distinct and obtain a qualified counterview where the consequence warrants it; do not solve the problem by inventing job titles.

A route replaces construction. “Send to product” says who might receive a question, not what family should be built. Develop the result and its receiving conditions.

The customer paid, so the exception scales. Payment can fund work. Determine whether the scarce work actually changes at the intended volume.

Every case must become common. Preserve a useful bounded local result when its transfer is unsupported or uneconomic.

CUST.1:9 - Consequences

The method can make local service and shared development mutually intelligible, with less hidden commitment. It also exposes work that was previously unpaid or unowned. That may produce a smaller promise, additional investment or refusal rather than a larger common product.

Its additional coordination is worthwhile only where the connected decisions matter. Sufficient smaller methods remain available directly.

CUST.1:10 - Architectural Rationale

The whole method is organized around two receiving results and their shared constraints. Its smaller methods can be used independently, but their availability does not itself provide the joining decisions for a customer case.

A fixed sequence would reopen settled questions and delay urgent responses. Pure local discretion would hide common obligations. The conditional composition retains enough structure to coordinate both while allowing justified short paths.

CUST.1:11 - SoTA-Echoing

The useful source line combines service productization, bounded solution spaces and continuing field/product learning. Compared with “standardize everything” or “let field teams solve each case,” it preserves explicit variation, assistance and a path back to common development.

Wirtz and colleagues’ conceptual account of service productization supports defining and systematizing an offering; Salvador, de Holan and Piller’s mass-customization account adds solution-space development, robust processes and choice navigation. Neither supplies this entire commitment-level composition. CUST adapts those contributions and combines them with the full Management, Engineering and Implementation Facilitation methods named above.

Official FDE role descriptions and the practitioner account discussed in CUST.Reference:10 support continuing interaction between local delivery and product development. They do not establish that one staffing model causes better results. Reconsider the composition when another available treatment provides the same connected use more adequately or when its own coordination cost exceeds the benefit.

CUST.1:12 - Relations

CUST.2 through CUST.8 supply conditional constituent methods of CUST.1. Their outputs are joined by the customer result, permission, resource and continuing-obligation conditions in this Solution. Their publication order is not a work schedule.

MKT.11 — Align Promises, Partners and Execution supplies promise/execution alignment; MKT.13 — Test Commercial Model Repeatability and Deployment Limits supplies commercial repeatability and deployment-limit inquiry; MKT.14 — Develop and Change a Programme for Selected Customer Organisations supplies the customer-organization programme. Use their complete methods when those questions arise and return their qualified results to the selected alternative.

CUST.Reference:2 explains the field boundary; CUST.Reference:3 distinguishes composition, supplied results and a repertoire.

CUST.1:End