Before launching a new service, your team should clarify the buyer, area, included work, pricing process, available capacity, first acquisition channel and enquiry handling. Those answers define the page and the launch. They also reveal decisions the business needs to make before development starts.
In our work, the useful conversation begins before “add one more page.” I ask what the visitor will be able to order and what happens when they ask for it. A developer can build a button without knowing that the office has no process behind it. That is why we bring the business question into the brief.
New service launch brief: define the buyer and scope
Who can buy the service, and where?
Describe the customer's situation, service area and important exclusions. “Everyone who needs installation” is not enough if only certain equipment, properties or locations can be served. State who confirms compatibility before a quote becomes a promise.
What is included in the offer?
Separate the service from optional work, materials and third-party requirements. Explain what information is needed to calculate a price. If a site visit is required, tell the visitor what the first appointment does and whether there is an agreed charge.
| Question from the team | Decision it changes |
|---|---|
| Does the customer supply the equipment? | Page wording, qualification and responsibility |
| Who confirms compatibility? | Form fields and technical follow-up |
| Which areas are covered? | Page scope and channel targeting |
| Who can accept the next appointment? | CTA wording and booking route |
| How is the result accepted? | Test case and launch approval |
Plan the first customer route before building the page
Choose a channel with a reason
Existing customers, related site pages, local search or a controlled ad test can be candidates. Name the route you intend to use and why it matches this buyer. Do not assume a new URL will attract relevant traffic just because the existing site has visitors.
For search-facing pages, use a distinct service purpose and useful contextual links. Our service page structure guide covers that organization. Use local SEO guidance where geography affects discovery.
Questions your launch brief still needs to answer
Build the unresolved part of your service brief
Check only the questions with an agreed answer. This tool does not score launch success or send your entries anywhere.
Questions and what each answer produces
Buyer and service area
Owner: business lead. Write who can buy, where the service is delivered and which requests are outside scope.
Included work and pricing process
Owner: service lead. Describe included work, exclusions and when the final price can be confirmed.
Capacity and booking route
Owner: operations. Name who confirms availability, receives enquiries and covers absence.
First acquisition channel
Owner: marketer. State the intended entry route, relevant message and budget or effort limit.
Launch acceptance
Owner: launch coordinator. Define one traceable test enquiry and who approves the result.
Agree the handoff from enquiry to service
Who receives and qualifies the request?
Name the recipient, response coverage and backup person. List the minimum details needed for the next step. A long form can collect information nobody uses; a short form can omit the location that determines whether the company can help. Choose fields from the actual decision.
Confirm what the CTA promises
“Request a quote,” “ask about compatibility” and “book a confirmed appointment” are different actions. Use the one your process supports. If the customer is only requesting a callback, the confirmation should not suggest that a technician has been reserved.
Define launch acceptance before paying for promotion
Run a labeled test from the intended entry point on a phone. Confirm the offer, submit once and locate the request with the responsible person. Ask the office to describe the next step. Record the result and the owner of anything unfinished.
The Atlassian launch checklist connects readiness with sales and marketing preparation. For a small service business, use that principle without copying a software-product launch plan. Your critical output is a service the customer can understand and the company can actually deliver.
What to give the team at the end of the brief
Provide approved conditions, the acquisition route, named operating contacts and acceptance criteria. Mark unanswered questions with an owner. Do not bury them in a design comment and hope development will decide.
At W-MAX, this is where recommendations can save work: the right question may change the form, the offer or the first channel before those parts are built. Start with these decisions, then use the service page elements checklist to turn the brief into a clear page.
Frequently asked questions
Do I need a large strategy document to add a service?
No. A short brief can be enough if the offer, buyer, operating route and acceptance criteria are clear. Unresolved decisions should have owners.
Can the developer decide what the service includes?
The developer can suggest implementation, but business scope, price and delivery capacity need approval from the responsible business person.
What if the first traffic channel is uncertain?
Record that uncertainty and define a limited test with a reason, resource limit and review criteria. Do not treat publication alone as a distribution plan.