The short answer
Give each package a specific buyer, a defined first-release outcome, and a visible boundary. Standardize repeated work; price uncertainty separately.
- A good fit
- Agencies seeing the same client problem and delivery pattern across several projects.
- Pause if
- Every prospect needs a different application, integration, or content operation. Sell discovery before standardizing the build.
1. Find the repeatable problem before naming the package
Look at the work clients actually asked you to do. Group it by their situation: launching a new service, replacing an outdated site, or connecting the website to an existing business process. A package should answer ‘is this for me?’ before it answers ‘how many pages?’
Write a one-sentence offer with an input and an output. For example: ‘For a service business with approved copy and photos, we build a small enquiry website with one contact path and a handoff session.’ If the input condition is false, the scope must change. Do not absorb missing content into an apparently identical package.
Buyer and situation: What the first release enables: Required client inputs and due date: Included page types and functions: Revision rounds and named approver: Acceptance tests: Excluded work and optional additions: Delivery schedule starts when: One-time fee / recurring fees: Ownership, handoff, and support boundary:
2. A launch package: one offer, one reliable next step
Consider a hypothetical independent consultant with approved service copy, a biography, and a contact inbox. A launch package could cover a home page, one offer page, an about section, and a contact page. Its job is to explain the offer and help the visitor enquire—not to establish a content publishing operation.
Specify one enquiry destination, one content approval round, and a handoff recording. Exclude a CRM migration, a membership area, copywriting from interviews, and ongoing updates unless separately scoped. The acceptance test is concrete: a visitor can understand the service on mobile, submit valid details, see a confirmation, and reach the intended recipient.
Avoid adding a blog merely to make the package look larger. A blog without an owner or publishing plan creates a maintenance obligation the client may not want.
3. A service-growth package: deeper explanation, not promised leads
A business with several services may need distinct service pages, project examples, an FAQ, and help turning interviews into usable content. This is more than multiplying the launch package by five pages. The additional responsibility is research, writing, evidence collection, and review.
For a hypothetical landscape studio, separate garden design from ongoing grounds care because the buyer’s questions, proof, and next step differ. Use a shared page template but require approved project photos and service-specific details. Price the content interviews and revision work explicitly.
Do not bundle ‘SEO’ as an undefined result. State deliverables such as page titles, descriptive headings, internal links, and a checked sitemap. Search performance is an outcome to observe, not an acceptance guarantee for the package.
| Responsibility | Launch | Service-growth |
|---|---|---|
| Copy | Edit approved client text | Interview, draft, and obtain approval |
| Page structure | One main offer | Distinct service intents on shared layouts |
| Proof | Supplied credentials | Approved project case studies |
| Measurement | Test the contact path | Define service-level enquiry reporting |
4. An integration package starts with a feasibility decision
An external booking tool, location-based form routing, or catalog sync can change the whole risk profile. Do not put ‘custom integrations’ in the top tier and discover the limitations after purchase. Offer a validation phase with a test environment, sample data, and a written go/no-go outcome.
The discovery output should identify the systems involved, their account owners, the supported connection method, the failure behavior, and a runnable acceptance test. If a dependency cannot be supported, recommend a simpler path or a different stack. A premium label does not create missing platform capabilities.
5. Keep ongoing care separate from build scope
A website launch ends a project; care starts a service. Show whether the monthly plan pays for platform access, checks, content edits, reporting, or a combination. Name the support channel, working hours, request allowance, and cancellation handoff.
A reasonable editing boundary might be ‘one consolidated monthly request within the stated time allowance, using supplied text and images.’ A new page layout or a campaign strategy is a different job. If unused time does not roll over, say so before purchase. If it does, account for the future capacity you owe.
6. Present a recommendation, then test the package against delivery
Show the prospect the option that fits their situation, explain why, and show what changes in the alternatives. A comparison table should compare the same dimensions: inputs, outputs, support, exclusions, and total ongoing cost. Avoid a decoy tier that exists only to make another option look cheap.
After a project, record where the package broke: missing inputs, unexpected stakeholders, repeated change requests, or work clients did not use. Tighten the definition or split a recurring exception into a paid add-on. A package becomes repeatable through evidence from delivery, not through giving it a name.
I recommend the launch scope because you have one offer and approved content. The service-growth scope adds interviews and separate service pages, which you do not need yet. Booking integration is excluded until we test your provider. Here are the handoff tests and ongoing costs for the recommended option.
Take it into the project
Service-package specification
Copy this into your project brief, assign an owner to each item, and attach evidence before marking it complete. No email required.
- Each package names a buyer and a first-release outcome.
- Required client inputs are visible before purchase.
- Content, revisions, integrations, and acceptance tests have boundaries.
- Discovery is separate when feasibility is unknown.
- One-time and recurring costs are shown separately.
- A delivery review will record recurring exceptions.
Includes a buyer brief, scope comparison, acceptance tests, exclusions, and a post-project exception log.
Common questions
Do I need three tiers?
No. One well-defined offer plus scoped additions can be clearer than three overlapping tiers. Add an option when a different buyer situation justifies it.
Should hosting be included?
It can be, but distinguish the platform charge from your work. Explain renewals, ownership, service limits, and what happens if the client leaves.
Can I offer unlimited revisions?
Only if you have a credible operational and pricing model for that obligation. For a small agency, defined rounds with consolidated feedback are usually easier to explain and deliver consistently.
