How to Productise a Service With AI: Scope, Pricing and Delivery

In this blog post, I'll explain how to productise a service with AI without promising work you can't deliver profitably. It's for freelancers, consultants and small service businesses that already sell useful work and want to package it more clearly. You'll learn how to choose a repeatable service, measure the complete delivery cost, define the scope, set a workable schedule and test the offer. I'll use a fully worked example, including the awkward requests that tend to appear after someone has agreed to buy.

A productised service has a defined scope, fee and delivery process. The customer understands what they receive and the conditions attached, while you have a repeatable way to produce it. People can still do substantial parts of the work. You don't need a portal, an app or a subscription model to make the service easier to buy and deliver.

AI changes what you can produce in the time available, but that only helps if you count the rest of the job. Drafting, checking, chasing missing information, applying corrections and explaining the final file all belong in the calculation. A ten-minute draft with three hours of repairs is an interesting typing demonstration. It isn't yet a better service.

Choose a service that repeats for the right reasons

Begin with work you've delivered several times. Look for the same kind of customer problem, broadly similar inputs and an output you can check. The repeatability should come from the job itself, not from your determination to force every customer through the same template.

For example, "advise on our business strategy" may require substantial investigation before you know what needs doing. A fixed package sold before that investigation could put you in charge of an unknown amount of work. "Prepare a booking FAQ pack from approved venue information and recent enquiry themes" has more visible boundaries. You can count the questions, define the source material and agree what a correct answer looks like.

Use your past project records to compare candidates. My workflow prompts for operations can help map the trigger, steps, handovers and stopping point. Don't start by asking AI what service you should sell. It can invent attractive packages all afternoon without having to deliver one of them.

For each candidate, examine where previous jobs varied. Did one customer have complete source files while another expected you to research everything? Did approvals take an hour or a week? Did the finished work keep generating support requests? A service with predictable production but unpredictable inputs may still be suitable, provided the input check happens before you accept it into the package.

The customer interview prompts help establish why customers bought the original work. Keep that purpose intact when you standardise it. An efficient package that removes the part people valued is a surprisingly thorough way to waste the efficiency.

The worked example: a booking FAQ service

Consider a fictional copywriter, Elise, who works with independent activity venues. She has written website information for craft workshops, guided walks and small visitor attractions. For this walkthrough, she wants to package one recurring job: helping a venue answer the questions people ask before booking. The business, numbers and trials below are illustrative, not client results or experiences I'm claiming as my own.

Elise's proposed service covers one venue, one language and up to 25 agreed booking questions. It produces a structured document for the website editor, a spreadsheet for the venue's records and a short guide explaining which answers need review when policies change. Publishing and a chatbot are outside this package.

That last boundary matters. A usable set of answers is one job. Connecting it to a live booking system or allowing software to respond to customers is another. My WordPress publishing experiment shows the extra process involved in getting content into a live system. You can't assume that producing the words also completes the upload, layout and final checks.

Elise's customer wants fewer repetitive questions and clearer information before booking. Those are the reasons to consider the work. Elise can commit to a checked FAQ pack. She cannot honestly guarantee fewer enquiries, because the result also depends on whether the venue publishes it, where it appears and whether visitors read it.

If the venue later wants automated replies, the customer support prompt pack covers a different set of decisions, including policy boundaries and escalation. Keep that as a separate discussion after the information is sound. Otherwise a writing package can acquire an unpaid software department before lunch.

Measure the complete job before choosing the package price

Take comparable past work and record the time spent in each stage. If the old records are too vague, run a documented internal trial using material you have permission to reuse. Record hands-on time separately from elapsed time. A job can require four hours of labour and still take ten days because it is waiting for information or approval.

For Elise, the following is an invented comparison between a manual approach and an AI-assisted trial for the same 25-question pack:

Drafting fell by 105 minutes, or 70%. The entire job fell by 120 minutes, from seven hours to five, which is about 29%. Both numbers describe this fictional example correctly. Only the second tells Elise much about how many packages she can deliver.

The longer checking stage is intentional. A draft can sound clear while changing "children under eight must be accompanied" into "activities are suitable for all ages". Those sentences create different expectations. Checking that the words are tidy is not enough; someone needs to verify that their meaning matches the venue's rules.

My AI audit experiment is useful background for designing that check. A second model may spot a problem, but the approved source decides whether the answer is correct. If the source is ambiguous, the right output is a question for the responsible person, not a more confident rewrite.

The AI Savings Calculator can help you explore broader time assumptions in your business. Treat its output as an estimate, then replace assumptions with your service records. For an automation build, the agent ROI worksheet also prompts you to include setup, running costs, maintenance and errors. Those costs can consume the apparent saving if the package only sells occasionally.

Define the inputs so you can keep the output consistent

Elise needs current booking rules, the venue's approved information, the questions being considered and one person who can settle contradictions. She gathers those through the existing site, agreed documents and an intake conversation. The service description says what the venue needs to confirm before the delivery clock begins, while Elise remains responsible for organising the pack and identifying the gaps.

A list of files is not the same as a usable brief. She records a source owner, a version or confirmation date and which document takes precedence if two sources disagree. If last year's leaflet says visitors can bring dogs and the current booking page says they cannot, neither AI nor the copywriter should choose the more appealing policy.

The client onboarding template gives you a place to capture contacts, scope and the material needed at the start. Add an explicit readiness decision: accepted into the standard package, clarification required, or a different scope needed. That prevents the first day of a five-day service becoming an expedition through someone's shared drive.

Elise also asks for enquiry themes rather than an unrestricted export of customer correspondence. Where examples are needed, personal details are removed and permission to use the material is checked. The aim is to answer booking questions, not accumulate information about everyone who has ever booked pottery for a birthday.

Make the quality standard visible before you write

For each answer, Elise keeps the question, draft response, supporting source, any unresolved issue and review status. That creates an audit trail she can use during checking and handover. A blank source field stops the answer from being marked complete.

Here's how one row might work in the illustrative pack:

This is deliberately a fictional policy example. The point is that the source, distinction and check remain visible. It would be dangerous to copy the answer into a real venue's website without checking its rules.

Elise tests the drafting step on one answer before asking for the whole set. She supplies the agreed question and the relevant source extract, asks for a plain-language answer and requires the model to list the source sentences it used. An instruction to use only those facts reduces the room for invention, but it does not remove the checking step.

For example, her working instruction could be: "Answer this booking question using only the source extract below. Keep every condition that changes who can attend or what they must do. Do not infer a policy. If the extract is incomplete or contradictory, return QUESTION FOR OWNER instead of an answer. After the draft, quote the source sentences supporting it. Question: [question]. Approved source: [extract]." She compares the draft with the extract, checks the conditions and only then repeats the process on the next group of questions.

This small test is useful because errors often repeat. If the first answer drops the distinction between two activities, a batch of 25 may drop it 25 times. Fix the instruction or the source structure before generating more material, and keep the final human check even after the first few answers look right.

For the package as a whole, Elise defines completion as the agreed questions answered, facts checked against the approved sources, unresolved issues removed or explicitly held back, agreed formats supplied and included edits applied. If an agreed question becomes unanswerable because a policy changes, she pauses that answer and agrees a replacement question or revised timing. She does not silently reduce the deliverable count. She checks links and reads the document in the form the customer will receive. Twenty-five answers in the wrong spreadsheet columns are twenty-five answers someone else still has to repair.

If an AI agent takes part in this workflow, the agent brief template helps specify the input, output and stopping conditions. The guardrails checklist belongs at the point where software gains access to live systems. The writing package does not need permission to publish or send anything just because an automation tool offers those buttons.

Give the deadline a start, an owner and an exception path

A delivery promise needs a clock the customer can understand. Elise could offer five business days from a confirmed start after the source pack is ready. Her written agreement identifies the working calendar, time zone and review window. She only sells that promise after checking it against her normal workload, rather than timing one unusually peaceful afternoon.

In the proposed schedule, she checks the sources and confirms the question list before day one. Days one and two cover drafting and source checks. The review copy arrives at the end of day two, with one agreed decision-maker returning a consolidated response by the end of day three. Days four and five cover edits, final checks and handover.

If the venue changes a policy during review, Elise records which answers it affects and confirms the revised plan. If feedback arrives late, she gives a new delivery date based on available capacity. She doesn't silently move the customer to the back of the queue or keep an impossible date on the invoice because changing it feels awkward.

This is where a written operating procedure earns its place. Record what starts each step, what it produces, who checks it and what happens when the required input is missing. A process that only describes the happy path will be very reassuring until a customer does something entirely normal, such as going on holiday.

Separate a correction from a change in the job

The first useful boundary is responsibility. If Elise miscopies an approved policy, she corrects it without consuming the customer's included review round. If the venue replaces the policy after approving the source pack, the change may require additional work. If someone wants answers for a second venue, it is a different scope even if the spreadsheet still has room.

Define the review round as one consolidated set of comments on the agreed questions. State how long the customer has to report errors after delivery and what the provider will do about them. For this example, Elise proposes ten business days for reporting factual or formatting errors against the approved pack. That is an operational example, not contract wording suitable for every business or a limit on rights that may otherwise apply.

A useful response to a new request explains the effect before anyone does more work. The scope-creep response examples can help you phrase that conversation. For Elise, the substance would be: adding the second venue means new source checks and a second answer set; she will confirm the additional scope, fee and delivery date before starting it. There is no need to make the customer feel unreasonable for asking. There is also no need to do the work for free because the request began with "while you're there".

If the same addition keeps appearing, investigate whether the package is too narrow. Repeated requests for an upload service may justify a separate implementation option. They don't justify absorbing uploads into every order and hoping the price still works.

Set a price from the complete economics and the buying context

A fixed fee moves some delivery risk to you. Before choosing it, calculate the expected labour, direct software or transaction costs, a realistic share of overhead, the acquisition work and an allowance for variation. Do this privately using your own numbers; another provider's public package price doesn't tell you what it costs them to deliver.

For a simple planning calculation, call the expected total cost per package C. If you want a margin of 40% over those included costs, the fee before any relevant tax would need to be C divided by 0.60. Multiplying C by 1.40 gives a 40% markup, which produces a margin of about 29%, not 40%. These are illustrative calculations to show the distinction, not a recommended margin or a suggested selling price.

Be precise about what C contains. If it excludes sales time, general overhead or ongoing maintenance, the amount left over is not net profit. Your own labour also has a cost even when no wage payment leaves the account each time you work on a pack. Otherwise the package can look profitable while buying you a second job.

The value-based pricing worksheet helps examine the customer outcome alongside your minimum floor. Keep the claimed value inside the evidence. Elise can discuss the time staff spend answering repeated questions, but she cannot promise to recover all of it simply because an FAQ exists. A cost floor tells her when an offer is uneconomic; buyer response helps establish whether anyone values it enough to pay.

Don't create three tiers because a pricing page looks unfinished with one. Start with a package you can deliver. If customers need materially different outcomes, the offer-tiering worksheet helps separate them by scope. An FAQ pack, an implemented FAQ page and an ongoing update service carry different responsibilities. More adjectives would not create the same distinction.

Check capacity before you invite more orders

Using the illustrative five-hour delivery time, twelve hours allocated each week would support two packs with two hours left for variation. Three packs would need fifteen hours before an overrun. The twelve-hour allocation must already sit alongside other clients, selling, administration and time off. It cannot be twelve hours you hope will appear once the orders arrive.

Now stress the assumption. If two packs both take six hours, the whole allocation is used. If one needs seven and the other six, you have exceeded it. Until you understand the range, book conservatively and keep the starting dates visible. An average tells you what happened across jobs; the customer waiting for the slow job is experiencing that job in full.

Separate setup from repeat delivery. If Elise spends eight hours creating formats and instructions, and later saves two hours per comparable pack, four packs recover that setup time in labour terms. That still doesn't establish financial payback: she must include software, selling and maintenance, and the four orders must exist. A beautifully automated service with no buyers has an excellent availability calendar.

Write an offer someone can understand without a sales presentation

With the scope and economics settled, Elise can write a complete offer. The example below intentionally leaves the fee and final delivery commitment for her real measurements and buyer conversations. It is a working service specification, not a published offer from an existing business.

Booking FAQ pack for one independent activity venue. The service turns confirmed venue information and agreed enquiry themes into up to 25 checked answers in one language. The customer receives a formatted document for their website editor, a spreadsheet containing the answer and source references, and a short update guide. Elise gathers and organises the agreed source material, flags contradictions and confirms the question list before the start.

What completion means. Every included answer matches the approved source pack; unresolved policies are excluded and listed for resolution; links and file formats are checked; and the agreed review edits have been applied. The service includes one consolidated review round on the agreed questions. Supplier errors against the approved pack are corrected separately from that round within the stated correction arrangements.

Timing and limits. The proposed schedule is five business days from a confirmed start, conditional on the agreed review window and complete inputs. A second venue, another language, policy creation, publishing, chatbot setup and ongoing updates are outside the package. Any change affecting scope, fee or timing is agreed before additional work begins. The fixed fee and payment terms are confirmed in writing before the order is accepted.

Handover. The pack identifies the source owner and what to review when the venue changes an activity or policy. The customer knows who to contact about an error and when the included support ends. There is no promise of a particular enquiry reduction or booking increase.

The sales page prompts can help turn that specification into readable page copy. Give the model the final boundaries as well as the benefit. Then use the landing page checklist to confirm that a reader can see what they receive, the relevant evidence and what happens after enquiring. Don't make them book a call to discover the exclusions.

Test the package on paid work and keep the inconvenient records

Use the package on a small number of suitable paid jobs, with the scope agreed clearly. Keep it stable enough to compare delivery, and record the reason for exceptions. The useful question is whether it serves the customer and the business repeatedly, including when the inputs are imperfect.

Elise could record these fields for each job: readiness date, confirmed start, delivery date, hands-on hours by stage, revision time, supplier corrections, requested additions and whether the customer could use the files. She also records the fee, included costs and acquisition time privately. That lets her distinguish a production saving from a profitable service.

Suppose three illustrative trials take 4.5, 5 and 7 hours. The average is 5.5 hours, already above the original five-hour estimate. The seven-hour job needs investigation: did a new request expand the scope, did the input check miss a contradiction, or does this customer type need more support? Excluding the difficult job to preserve the original estimate would make the spreadsheet prettier and the next delivery no easier.

My failed cold-email automation experiment is a useful companion when a smooth test starts tempting you into a much larger rollout. Test missing inputs and failure paths as well as successful output. The agent failure-mode guide helps identify cases such as stale information, missing escalation and incorrect output before an automated step becomes part of a paid commitment.

If delivery is dependable but nobody buys, investigate the need, the audience and the explanation. When delivery works but the reason to choose you is weak, my guide to business differentiation strategy shows how to find a difference buyers care about and prove it. If people buy but require extensive help after handover, include that help in the service economics or repair the handover. If the package only works when you personally rescue every step, finish the operating instructions before adding capacity.

Questions worth settling before you sell the package

Does productising a service mean abandoning hourly work?

No. Hourly work or a retainer can suit open-ended investigation and ongoing support. A fixed package is useful where the scope and completion checks are predictable enough to price. You can offer both, with clear boundaries, and existing agreements still need to be honoured.

Should the customer pay less because AI makes delivery faster?

There is no automatic answer. The fee needs to reflect the agreed service, your costs and what the customer values. Faster production may improve margin, allow better checking or support a different offer. Be honest about what you deliver and never charge invented hours under an hourly agreement.

Can you sell the package before building an automation?

Yes, if you can deliver the agreed service manually at the promised scope, quality and timing. A paid manual delivery can teach you which steps repeat and which exceptions matter. Don't sell an automated capability or delivery speed that exists only in the plan.

Check your service specification against the evidence

Copy this prompt

The companion worksheet gives you a place to keep the decisions. The article gives you the reasoning to make them. Once you've completed both, you should be able to explain what the customer buys, show how you will deliver it and recognise the requests that change the job.

That is the point at which faster AI work becomes useful to the business. You know what you're selling, the customer knows what arrives, and neither of you discovers the missing half of the agreement during the final invoice.