Standardisation and customisation: decide where flexibility belongs
What should be repeatable—and where does the customer genuinely need a different response? Use this page to shape an offer that meets real needs without creating unmanaged delivery and support demands.
Standardisation is not a reason to ignore differences. Customisation is not automatically a problem. The question is whether the benefit justifies the full cost, risk and continuing obligation.
Look beyond the sale
A one-off request may bring useful revenue—and create work long after delivery. Check scoping, specialist time, testing, maintenance, upgrades and customer support before promising it.
A possible trap is: more variants → more support and expert dependence → less time to improve the common offer → continued dependence on bespoke work. Investigate whether this happens here; do not assume every variant has the same cost.
Compare genuine customer benefit and the cost of serving different needs. Check what is limiting reliable delivery and whether the right skills and response capacity are available.
Meet both needs through separation
“Customers need flexibility; delivery needs repeatability” need not mean choosing one and sacrificing the other. TRIZ separation offers four useful prompts:
- Time: agree customer-specific choices before routine delivery begins.
- Space: provide a defined specialist route without exposing every delivery task to interruptions.
- Condition: use a routine route for familiar needs and an exception route when clear criteria apply.
- Whole and parts: keep a common core with supported configurable options.
These are ideas to test, not guaranteed solutions. Check whether both needs are met and whether new handovers, delays or support burdens are created.
Agree what you will accept
- Define the offer. State the intended customer need, included service, supported options and limits.
- Set an exception process. Who checks benefit, cost, capacity, risk and ongoing support—and who can authorise a commitment?
- Make the trade-off explicit. If bespoke work is accepted, agree what changes elsewhere. Check cash needs, existing contracts and safety before declining or withdrawing work.
- Offer a useful alternative. A supported option, partner referral or separately scoped engagement may fit. Do not promise a future feature without authority and capacity.
Manage the resulting commitments with Focus and prioritisation; compare competing improvement ideas with PICK.
Optional: learn from customers before defining a standard
Look at customers achieving useful results with manageable delivery and support effort. Ask what helps them—and whose needs the proposed standard would exclude. A successful workaround is a hypothesis to investigate, not automatically a feature everyone needs.
Try a repeatable offer with an appropriate customer group before committing widely. Neither unusual users nor a few easy implementations establish a mainstream market. Check demand, willingness to pay, accessibility and the capability to deliver.
Test the whole result
Agree expected benefits and a review date. Check delivery time, quality, customer outcomes, support effort and financial viability—not just the number of variants removed.
A chart or Bootstrap CUSUM analysis may help identify a performance change; it does not prove the new offer caused it. No detected change is not automatically proof of no benefit. Keep legitimate exceptions and possible harm visible.
Choose useful measures →What’s your next useful question?
Which part of the work needs flexibility—and could the rest become more reliable and repeatable?
Explore conflicting needs through separation →Return to Where might the difficulty lie? →