Package a freelance service by connecting a specific client need to a bounded set of deliverables, clear responsibilities, and an assessable result. Explain the change the work is intended to support without guaranteeing outcomes you cannot control.
“Five pages of copy” describes an output. “Double your sales” makes a business promise that may not be supportable. A useful offer connects purpose and work: clarify the service proposition and rewrite five agreed pages so prospective clients can understand their options and inquiry route.
If the request is still based on an untested explanation, diagnose the client problem before packaging implementation.
Start with a supported client need
Define the audience, situation, and desired change. Avoid designing a package around a fashionable service label and then searching for a problem it might solve.
Ask:
- Which client situation is this offer for?
- What problem has been established?
- What useful change can this engagement support?
- Why is this service a reasonable way to make that change?
An onboarding automation package for a team with repeated manual handoffs has a clearer rationale than “AI transformation for every business.” The more specific offer is also easier to scope.
If the problem is not yet understood, sell an assessment with a clear assessment output. Do not package an implementation as though the diagnosis were complete.
Translate the work into its practical purpose
Use the following fictional examples to separate the deliverable from its intended contribution.
| Deliverable | Practical outcome it can support | Business result to avoid guaranteeing |
|---|---|---|
| Five service-page rewrites | Visitors can understand the services and the next action | A fixed increase in sales |
| A documented inquiry handoff and configured reminders | The team can see who owns each follow-up | A guaranteed close rate |
| An onboarding guide and welcome sequence | New clients receive consistent instructions and know what to supply | Guaranteed retention or zero support requests |
The business result may still be a client objective. Keep it visible as an objective, then explain the other factors it depends on.
This distinction prevents an outcome-led offer from becoming an unsupported performance promise.

Read the decision map as text
- Deliverable: Document the handoff and configure the agreed reminders. Define the bounded work.
- Practical contribution: Make the owner and next action visible for agreed inquiry types. Explain how the work helps.
- Business objective: The client wants more consistent follow-up and better sales outcomes. Keep the objective visible.
- Claim boundary: Lead volume and close rate depend on factors beyond this work. Do not guarantee a commercial result.
Fictional example: an inquiry-handoff service. Agree acceptance criteria and client responsibilities before committing.
Define what you control, influence, and depend on
An offer should make responsibilities understandable.
You control the agreed work, its quality, and the commitments you can fulfill. You may influence understanding, usability, or adoption. You depend on client inputs, timely reviews, distribution, and other conditions outside your direct control.
For a lead-intake improvement:
| Element | How to state it |
|---|---|
| Provider commitment | Map the agreed intake routes, configure the specified reminders, and test the agreed scenarios |
| Client contribution | Provide authorized access and nominate the person who owns each route |
| Intended improvement | Make the next action and owner visible for the agreed inquiry types |
| Uncontrolled result | The number of leads received and the proportion that ultimately buy |
Do not use this distinction to avoid responsibility for poor work. If the configuration fails an agreed test, fixing that defect is part of delivering the commitment.
Make acceptance observable
“Professional,” “premium,” and “easy to use” can mean different things to different people. Convert them into criteria relevant to the project.
For an inquiry workflow, you could agree that a sample submission creates the correct record, reaches the nominated owner, and shows the next action. For a content project, agree the page list, required claims, voice references, review process, and handoff format.
These are example criteria, not a universal checklist. Choose ones that allow the client to evaluate the promised work without pretending to measure every business outcome.
Package a useful first step
An offer can be project-based, ongoing, or diagnostic. Melisa Liberman's consulting-packaging guide discusses several such forms. Choose the structure that fits the work rather than offering a retainer simply because recurring revenue is attractive to you.
A diagnostic phase makes sense when uncertainty must be resolved before implementation. A fixed project fits bounded work. Ongoing support fits a genuine recurring need with defined capacity and responsibilities.
If you offer tiers, make each one usable for its intended client. Do not deliberately remove an essential part so the cheaper tier cannot deliver its stated purpose.
Choose a package structure that matches the uncertainty
| Client situation | Suitable starting structure | Boundary to define |
|---|---|---|
| The problem is clear and the required work is repeatable | A fixed project package | Deliverable units, inputs, revisions, and acceptance |
| The problem is plausible but the implementation is unknown | A diagnostic engagement | The decision it will support and the evidence it will examine |
| The client has a recurring operational need | An ongoing service | Included capacity, response arrangements, and work that needs separate approval |
These are choices to assess, not rules that one pricing model always wins.
A fixed package needs room for normal variation without becoming an unlimited promise. An ongoing package needs a real ongoing task; access to you alone may be too vague for the buyer to evaluate. A diagnostic package must have a useful output even if the client does not buy implementation afterward.
Before creating three tiers, define one coherent offer. Add a tier only when a different scope or service level meets a different need. Extra features should have a reason to exist beyond making the middle price look attractive.
Write the offer in plain language
Two hypothetical offers for small consultancies. The fixed project establishes a handoff; the retainer maintains an existing one. Neither promises a lead volume or close rate. Use the recurring option only when the client has an actual continuing need.
Fixed project: inquiry handoff cleanup
Suitable client: a team with two known intake routes in an existing supported system, but unclear follow-up ownership. Feasibility and authorized access must be established first.
- Outputs: review the two named routes; document ownership; configure agreed reminders; deliver one short operating guide and a 45-minute review session.
- Acceptance: labeled sample inquiries create the specified records, reach the nominated owners and show the agreed next actions on both routes. Record the test conditions and confirm receipt; a submission-success screen alone is insufficient.
- Inputs: client-approved access, a named owner for each route, existing workflow information and one reviewer who consolidates feedback.
- Capacity and revisions: plan 12 delivery hours, including preparation, configuration, tests, coordination, handoff and one consolidated review round against the agreed workflow. Corrections needed to pass the agreed tests remain the provider’s responsibility.
- Exclusions: new intake routes, a new CRM, website redesign, data migration and running the client’s sales conversations. A changed workflow is assessed before additional work begins.
Monthly retainer: maintain the agreed handoff
Suitable client: a consultancy whose configured routes are already working and need recurring checks and small authorized adjustments.
- Outputs: one monthly test of each named route, a short exceptions/action log, one 30-minute review and agreed small changes to existing reminders within eight reserved delivery hours per month.
- Acceptance: the monthly record identifies each tested route, conditions, receipt result, any unresolved issue and its next action/owner. A failed route is reported for resolution; a clean report must not conceal an untested route.
- Inputs: continuing authorized access, a client contact to confirm receipt and one prioritized request list. The client still owns inquiry handling.
- Capacity and reviews: the eight hours cover checks, coordination, the review and authorized changes. The example reserves capacity for that month with no rollover; agree this explicitly. One consolidated comment round on the monthly record is included, as are corrections to inaccurate reporting.
- Exclusions and extra requests: new integrations, migrations, additional routes, incident response outside agreed hours and unlimited support. Review work against remaining capacity before accepting it; quote an extension or schedule a later period when needed. This example offers no emergency or immediate-response commitment.
For a specific engagement, scope and estimate the project before treating either offer as a final commitment.
Check the economics before announcing the package
Teaching assumptions, all USD before applicable tax; these are not market prices. The internal labor cost is USD 65/hour and excludes allocated overhead. It is a planning cost, not the client’s hourly billing rate. The delivery-hour estimates already include the reviews and coordination described above.
| Item | Fixed project | One retainer month |
|---|---|---|
| Labor | 12 × 65 = 780 | 8 × 65 = 520 |
| Direct tool cost | 60 | 40 |
| Allocated overhead | 120 | 80 |
| Total assigned cost | 780 + 60 + 120 = 960 | 520 + 40 + 80 = 640 |
| Illustrative fee | 1,200 | 800 |
| Fee less assigned cost | 240; 240 / 1,200 = 20% | 160; 160 / 800 = 20% |
This remainder is contribution after the defined assigned costs, not net profit or the standard variable-cost contribution margin. If your labor rate already includes overhead, remove the separate overhead allocation. Likewise, do not add a tool subscription again if it is already included in the allocation. Record your costing basis consistently.
Capacity decision: suppose 40 delivery hours remain in a month after administration and business development. One fixed project plus four retainers requires 12 + (4 × 8) = 44 hours and does not fit. One project plus three retainers requires 36 hours, leaving four delivery hours for variation. That buffer is an illustration, not a universal safe utilization target. Check actual deadlines and competing commitments before accepting the mix.
If normal variation repeatedly consumes the remainder or exceeds available hours, revise the scope, estimate, fee or client fit before promoting the package. A more attractive outcome claim cannot repair an uneconomic commitment. Use the bounded offer to write a client-specific proposal.
Before you turn the offer into a proposal
Check whether a buyer can answer:
- Is this designed for my situation?
- What change is it intended to support?
- What exactly will I receive?
- How will we evaluate the delivered work?
- What do I need to provide?
- What is excluded, and what happens if the work changes?
If those answers are clear, the offer is ready to become a project-specific proposal. If they are not, more persuasive copy is unlikely to resolve the underlying uncertainty.

