Offering Services as Products: Packages With Fixed Scope and Price

Why every quote starts from scratch

In many service businesses, sales follow a familiar pattern. A customer inquires, the owner holds a conversation, estimates the effort, writes a quote, and explains what they will do. With the next customer everything repeats, even though the work is largely the same. The customer, in turn, finds it hard to compare and asks about hours, because they do not know what they will get in the end.

This guide answers one question: How does a service provider turn its work into a package with fixed scope and price, and for which services is that not worthwhile? To answer it, we first clarify the term, introduce modularization as the mental model, examine what a case study shows about its limits, weigh package against custom work, and then go through the steps with a worked example.

A customer would rather buy an outcome they understand than hours they cannot assess.

What productizing means

Productizing means analyzing and describing a service so that it becomes repeatable and understandable to the customer. Härkönen, Tolonen, and Haapasalo (2018) describe it as a process in which customer needs are examined and the offering is defined commercially and technically so that it can be sold, delivered, and invoiced. The result is a package: a service with fixed scope, fixed process, and fixed price.

A package is not the same as a flat fee for a single job. The flat fee is estimated anew for each job; the package is developed once and then sold many times. The difference lies in the description. It consists of seven parts.

The mental model: modularization

The objection is obvious: my customers are all different. The answer is modularization. Pekkarinen and Ulkuniemi described a modular service platform on which Nätti, Ulkuniemi, and Pekkarinen (2017) build. It has four dimensions: the service itself, the process, the organization, and the customer interface. A module, in this view, is the smallest building block from which services are assembled. A customized offering is then a bundle of modules.

For a small business, this means: not the entire service has to be the same, but its building blocks. A base package covers the core that almost every customer needs. Add-on modules cover frequent extensions, each with its own description and price. Whatever is neither core nor module is offered as a special service on a time basis or declined.

An everyday analogy shows the principle. A kitchen from a cabinetmaker is custom work, but the cabinetmaker builds it from carcasses in fixed widths, fronts in fixed finishes, and handles from a list. Only the countertop is truly made to measure. The customer gets an individual kitchen; the cabinetmaker calculates with known parts.

What a case study shows about the limits

Nätti, Ulkuniemi, and Pekkarinen (2017) examined how modularization can be implemented in knowledge-intensive services. They conducted semi-structured interviews in two companies: a provider of training and consulting and a provider of engineering and construction management services. Their starting point is a tension. Modularization can help share knowledge and make processes more cost-effective. Professional services, however, often rest on the experiential knowledge of individual experts, which is hard to write down and pass on.

The most important finding for practice concerns the kind of knowledge. In a technical environment, knowledge tends to be observable and not tied only to individual experts. In consulting, it rests more on intangible knowledge bound to people. The authors stress that even with modularization, a remainder of this experiential knowledge always stays in the encounter with the customer. How far a service can be modularized therefore depends on how much of it can be captured in building blocks.

The study is based on two cases and is exploratory; its findings are indications, not laws. But it supports an idea that matters for the decision: a consulting business does not have to productize its entire service. It can turn the describable part into a package, such as an assessment, and offer the part that requires judgment as an accompanying service.

Package or custom work? Two perspectives

The first perspective sees the package as the route to a scalable business. Sales become simpler because the customer understands what they are buying. Quotes become faster because they are not rewritten. Employees can deliver the service without the owner being present every time. The article scaling or just growing? puts this into one question: what does the tenth customer cost compared with the first? It also states that the path begins with a fixed package, a described process, and leaving out special requests.

The second perspective warns of the risk. A fixed price shifts risk to the provider. The comparison pricing models compared notes: with an hourly rate the customer bears the volume risk, with a flat fee the provider. If you do not know your effort or have customers with very different needs, you lose on every package that turns out bigger than expected. In addition, some customers value custom work in particular and experience a package as being processed.

I consider the package the better choice when two conditions are met: the effort is known from earlier jobs, and the most frequent deviations can be named as exclusions or add-on modules. If either is missing, the business should collect data first rather than guess a price. The four risk questions from the pricing model comparison, namely predictability, influence on the outcome, recurrence of need, and measurability, help with this check.

The package price: calculate from real data

The most common mistake in productizing is a price based on the average or on the best project. A package has to absorb the typical variation in effort. For that you need the hours from as many comparable jobs as possible, ten rather than five.

In the example, six of seven jobs lie between 18 and 26 hours. The outlier had a clear reason. The business therefore calculates the package at 26 hours, excludes the funding application review, and offers it as a module with its own price. That way the package price covers most cases, and the rare large case is not built into every price. Whether the price pays off in the end is shown by the contribution margin per job, not by revenue.

From service to package in six steps

1. Select candidates

   Choose a service you delivered at least eight times last year. How to tell which services pay off at all is shown in the guide cleaning up the service portfolio.

2. Evaluate effort

   Collect the actual hours and costs of the latest jobs and note the reasons for outliers.

3. Separate core and modules

   Determine what almost every customer needs and bundle frequent extensions into add-on modules.

4. Write the description

   Fill in the seven parts: name, outcome, scope, exclusions, process, prerequisites, price. Start with the outcome from the customer’s point of view.

5. Test with pilot customers

   Offer the package to three to five customers and measure effort and feedback. How to do that without major risk is described in the guide testing a new service.

6. Publish and maintain

   Put the package with its description on the website and review price and scope twice a year against actual effort.

If you later want to offer the package in tiers, the guide good, better, best is the next step. It describes fence features: service components that keep existing customers from switching to the cheaper tier. What a page that sells such a package looks like is shown in the guide the service page.

Conclusion: when a package pays off

To the guiding question: a service provider turns its work into a package by carefully describing outcome, scope, exclusions, process, prerequisites, and price once and deriving the price from the actual effort of earlier jobs. Modularization allows adaptation without starting from scratch each time: the core is fixed, the add-on modules are described, and everything else is a special service.

A package does not pay off when effort is unknown or varies strongly and when the service rests mainly on the judgment and experience of individuals. The case study by Nätti and colleagues shows that this experiential knowledge limits modularization. Then part of the service can often be productized, such as the assessment, while the rest remains accompaniment. For this week, one step is enough: find the service you offer most often and collect the hours of the last eight jobs.

The sober observation is this: a package does not take quality away from the service; it takes uncertainty away from the sale.