Productized services: turning custom work into a fixed offer
How to productize a service in five steps: choosing the service, scope, exclusions, pricing without timesheet history and a three-client test, with an example.
How do you turn a custom service into a fixed-price package? In five steps. Pick a service you’ve already delivered several times with a similar scope. Write down its fixed scope, outcome and timeline. Decide what stays custom and how you price it separately, and write that down as a list of exclusions. Calculate the price from the time your recent projects took, or, if you don’t have reliable hours, from the scope broken into steps plus a buffer. Finally, test the package with your next three clients, and only after them adjust the scope and price. You calculate the price after the scope and exclusions because with a fixed price a scoping mistake costs you, not the client.
In this post I’ll show these steps, an example of a package built from an audit that used to be custom work, and the situations where a package doesn’t make sense.
What productized services are
A productized service is a service you used to price separately for each client, turned into a package with a fixed scope, outcome, timeline and price, all set before you talk to the client. The next client gets the same package. What changes is the input, meaning their company and their materials, not the list of work or the price.
With a fixed price, you carry the risk of getting the scope wrong
Promethean Research, a research firm that surveys digital agencies (mostly in North America), describes the fixed fee in its 2025 report as a model where the agency estimates the cost of a project and adds a margin. The client gets a reliable number to budget against, and an efficient agency can earn more than it would charging by the hour. Most of the risk, however, sits with the agency, because scoping inaccuracies can easily erode margins. That’s why the report’s authors say this model fits best when the scope is predictable and well defined. Hourly billing is the opposite: the client bears most of the risk, and the model fits scopes that can’t be predicted (report, p. 34).
David Maister wrote in 2002 that many clients want fixed fees because they’re concerned about the productivity of the firms they hire and need budgetary control (“Responding to Fee Pressure”). In my view, Promethean’s description implies an order of work: the service that fits a package is one whose scope you already know from several projects.
Five steps from custom service to package
- Pick the service. Input: a list of projects from the last 12–24 months. Output: one service and a list of the projects where you delivered it. A good candidate has at least three projects with a similar scope, steps you can write down before you start, clients who ask the same things at the beginning, and an outcome the client can check.
- Write down the scope, outcome and timeline. Input: the projects from step 1. Output: a list of work, the outcome and the timeline. The scope includes only work that was part of every project. Work that came up only for some clients goes to step 3. I covered how to write the scope so that your whole team describes the service the same way in how to write a service description.
- Decide what stays custom. Input: the work set aside in step 2. Output: a list of exclusions and how you price each one: a separate service, an add-on fee, or declining and referring someone else. You write exclusions in the client’s words, next to the things they’ll ask about: not “integrations out of scope” but “connecting the store to the warehouse system is quoted separately”. Maister wrote that with fixed-fee pricing the firm must state very precisely what is and what is not included in the job.
- Calculate the price. Input: the scope from step 2, the exclusions from step 3 and the time your recent projects took. Output: the price and the condition for changing it. If you have hours from your projects, you take the time the in-scope work took in recent projects (without the work on the exclusion list from step 3), multiply it by your team’s hourly cost (salaries plus overhead, not your billing rate) and add a margin, as in Promethean’s description of the fixed fee, plus a buffer for what you didn’t foresee. If you don’t have hours, or they’re incomplete, break the scope into steps, estimate each one with the person who did it, and add a buffer the same way. How much margin and buffer depends on your firm. You reduce the buffer once the notes from step 5 show how long the work really takes. Before the first sale, also write down what will change the price after the test in step 5, with a threshold, for example: “if at least half of the conversations about the package during the test end in a no where the client pointed to the price, not the scope, we lower the price”. A no because of the scope means changing the package, not the price.
- Test the package with three clients. Input: the package from steps 2–4. Output: revised scope, price and exclusions. For the first three projects, you note how long each one took, what the client wanted to add and what you did outside the scope. For every conversation about the package during that time, you note whether it ended in a sale and, if not, whether the client pointed to the price or the scope. You can show the package on your website as a new service during the test. You change the scope, exclusions and price (according to the condition from step 4) after the third client, based on these notes. If the third client doesn’t come, decide in advance after how many conversations about the package you evaluate the condition from step 4 without waiting for the third sale. Three clients is, in my view, the minimum: one may be an exception, and with ten a small firm would wait many months.
Maister also advised studying carefully how the firm does its projects and looking for ways to lower their cost: in staffing, training, methodologies and tools. With a fixed price, an hour saved on repeatable work stays in the margin, so the notes from step 5 serve this purpose too.
Example: an application performance audit as a package
This is an illustration, not a real firm: take a software house that has done a web application performance audit at least three times in the last two years. Each time it priced the audit by the hour. Some of the work repeated in every audit, and some came up only for certain clients.
| Field | Custom (so far) | Package (illustration) |
|---|---|---|
| Scope | agreed in conversation, a little different each time | speed measurement of up to five screens chosen by the client, a review of database queries and server configuration, a report, one meeting with the client’s team |
| Outcome | a report in varying forms | a prioritized list of fixes, with an effort estimate for the client’s team |
| Timeline | “depends on the scope” | two weeks from receiving access |
| Price | hours times rate, known after the project | fixed: average time of the in-scope work in recent audits times the team’s hourly cost, plus margin and buffer |
| Condition for changing the price | none | after the test: at least half of the conversations about the package ended in a no because of the price, not the scope |
| Exclusions | no list | “implementing the fixes in the code is quoted separately after the audit”, “rebuilding the application’s architecture is a separate custom project”, “we don’t audit iOS and Android apps; we refer you to a firm that does” |
The software house runs its first three audits in the package with notes on time and client requests, and records the reasons for each no in conversations about the package. If each of the three clients also asks for the fixes to be implemented, the firm will consider adding the most common fixes to the scope at a new price.
When a package doesn’t make sense
A package won’t help when:
- the scope can’t be predicted, for example when developing a client’s product without a specification; according to Promethean, hourly billing fits such work, with the client bearing most of the risk,
- you don’t have three similar projects, so you don’t know which work repeats,
- you want to turn your whole offer into packages at once.
In Promethean’s study published in 2025, most agencies combined pricing models. The most common combination was time and materials, fixed bid and retainer (28% of agencies). Only 4% of agencies relied solely on a fixed price, another 4% solely on retainers, and 5% solely on hourly billing (report, p. 35). In my view, a package is therefore one model alongside hourly billing and retainers, not their replacement.
Frequently asked questions
How is a package different from a retainer?
A package has a fixed scope, an outcome and an end. A retainer is a fixed monthly fee for work or availability that continues until the client cancels it. When a package ends, you can offer a retainer for further work.
Should I show the package price on my website?
In my view, yes, even during the test: a reliable number to budget against is one of the reasons clients choose a fixed price, and a price on the website lets the client assess the package before the first conversation. After the test, you update it together with the scope.
What do I do when a client wants “a little more”?
Show them the exclusion list and price the extra separately, as you decided in step 3. If the same “a little more” keeps coming up with other clients, consider adding it to the scope when you revise the package in step 5.
Summary
If you write every proposal from scratch, I recommend starting with a list of projects from the last 12–24 months and choosing one service with at least three similar projects. Write down its scope with exclusions, calculate the price and test the package with your next three clients. We ourselves replaced a broad implementation with a small, repeatable Claude Code package (Claude Code Team Start), and we price what didn’t fit into it separately as a custom implementation. The package is new, so as in step 5 we show it on our website right away and will revise the scope and price after the first projects.
Every method on this blog also runs as a skill in the open-source B2BForce repo. About the repo