Updated
A fixed fee does not make an undefined service repeatable. If the promised outcome is still broad, the delivery team will carry the ambiguity.
The better decision is to package the part that can be bounded and completed. Custom does not have to mean undefined.
Illustrative starting situation: an unlimited promise
This is an illustrative example, not a client case study or a result from my businesses.
A consultancy wants to make its operations work easier to explain, price and deliver consistently. Its current offer promises to “fix operations” for a single fee.
That promise hides several decisions. It does not name the workflow under review, the information the customer must supply, the output the consultancy will produce or the point at which the work is complete. It may also leave implementation, additional teams and ongoing support open to interpretation.
The first action is not to write a more polished proposal. It is to compare completed jobs of the same kind and identify the buyer’s recurring starting situation, the output and the delivery steps that genuinely repeat. The evidence should come from actual delivery work, not only from previous proposal wording.
The decision: package a defined process review
In this example, the consultancy decides not to package the unlimited outcome. It defines a process review around a named workflow, specified source material and a documented recommendation.
The distinction matters. A review can have a clear scope and acceptance point. “Fix operations” can include diagnosis, implementation, work across additional teams and continuing support unless each boundary is made explicit.
Implementation, additional teams and ongoing support therefore remain separate decisions where they are not part of the standard core. The consultancy also states the inputs the customer must provide and when the review is complete.
What would change in another business
The repeatable unit will not always be a process review. Another business might find that the buyer’s starting situation, required evidence or delivery pattern varies too much for a fixed delivery package.
If every job requires a different diagnosis, a defined discovery service may be the better first product. If the core repeats but certain requests recur, those requests might belong in the standard package, become priced options or show that the offer is aimed at the wrong starting situation.
Expert judgement can remain part of the work. Productisation should clarify where judgement is used rather than pretending that every decision follows a fixed script.
Working step 1: choose one service
Select one service with a recurring problem, outcome and delivery pattern. Trying to standardise the whole service business at once makes it harder to see where genuine repetition ends and variation begins.
- Compare several completed jobs of the same kind.
- Record the buyer’s common starting situation.
- Identify the output each suitable engagement produced.
- List the delivery steps that genuinely repeated.
- Note where expert judgement or customer-specific work was still necessary.
For the illustrative consultancy, the candidate service is the review of one named workflow. The broad transformation work is not selected because its boundaries cannot yet be defined sensibly.
Working step 2: separate the four types of work
Mark each element of delivery as always included, optional, custom or excluded. This prevents useful expertise from being stripped out merely to make the package look simple.
- Always included: the repeatable work required to produce the stated output.
- Optional: defined additions that can be chosen and priced separately.
- Custom: work requiring further judgement or scoping.
- Excluded: work the package does not provide.
In the example, the named workflow, specified source material and documented recommendation form the core. Implementation, reviews of additional teams and ongoing support are separate unless deliberately added to the package.
Working step 3: write the package boundaries
Write down the buyer, outcome, scope, deliverables, turnaround, responsibilities, exclusions, support, price and next step. The aim is not attractive wording. It is agreement about what will happen.
Pay particular attention to customer inputs and acceptance. A customer who does not know what source material to provide can delay or alter delivery. A package without a completion point can still become unlimited work, however clear the deliverables first appear.
Working step 4: check economics separately
A simpler offer is not automatically a cheaper one. Check delivery cost, gross margin, monthly capacity, overhead break-even volume and the price needed for the target margin rather than treating standardisation as a reason to reduce the price.
This calculation may expose a mismatch between the package and the work required. It does not prove that the package will sell or produce a commercial result.
Working step 5: test the next suitable proposal
Use the next suitable proposal as a pilot rather than standardising every service immediately. Record objections, requested exceptions and actual delivery effort.
When an exception appears, make an explicit choice: add it to the core, turn it into a priced option, keep it as bespoke work or recognise that the prospect does not match the intended starting situation. Do not quietly absorb it.
The check: can someone else describe the offer?
Give the offer to another person and ask them to describe what the customer would receive. Any disagreement reveals a weak boundary.
- Can they name the workflow being reviewed?
- Can they identify the source material the customer must provide?
- Can they state the documented output?
- Can they explain when the work is complete?
- Can they distinguish the package from implementation, additional teams and ongoing support?
- Can they identify when the standard package is unsuitable?
After the pilot, compare the package decision with delivery evidence. Keep it, refine it or abandon it. The purpose of the test is to learn whether the proposed core is genuinely repeatable, not to defend the first version.
Mistakes that make a package look clearer than it is
- Packaging an unlimited outcome instead of a bounded piece of work.
- Using old proposal language as evidence without checking actual delivery.
- Removing necessary judgement to make the service appear standard.
- Leaving customer responsibilities or the acceptance point unstated.
- Including recurring exceptions without changing the core, options or target customer.
- Assuming simpler wording means the service should cost less.
- Standardising every service before testing one suitable proposal.
- Selling the package where the customer’s starting situation makes it unsuitable.
Where the working files help
A business can follow this method without buying anything: choose one service, inspect completed work, separate the core from options and exclusions, write the boundaries, check the economics and test the next suitable proposal.
I create and sell Productise Your Service Business as a one-off digital toolkit. No software or consultancy is included. The selected files support distinct parts of the job rather than replacing the decisions.
- The Service productisation starting guide helps choose a service whose repeatable core can be defined without removing the expertise customers need.
- The Productisation readiness scorecard helps assess repetition, customer similarity, definable scope, cost and customisation needs before deciding what can sensibly be standardised.
- The Service design decisions worksheet records the evidence and choices behind the standard core, customer outcome, package and economics so the same decisions are not repeatedly reopened.
- The Service package definition provides a structure for the buyer, outcome, scope, deliverables, turnaround, responsibilities, exclusions, support, price and next step.
- The Service package economics calculator models delivery cost, gross margin, monthly capacity, overhead break-even volume and the price needed for the target margin.
- The Package implementation review checks the first package decision against delivery evidence before it is kept, refined or abandoned.
These are selected files and not necessarily the full pack inventory. They provide a working structure, but they cannot determine whether your evidence is sound, whether the package is commercially suitable or whether customers will buy it.
The current product page has the latest purchasing information: https://chrisgjones.co.uk/business-fix/productise-your-service
The next action
Choose one service and review several completed jobs of that kind. If you cannot identify a recurring starting situation, output and delivery pattern, do not force it into a fixed package. Define a discovery service instead, or leave the work bespoke until the evidence supports a repeatable core.