How to write a service description your whole team can sell
How to write a service description for a B2B service firm: eight fields, scope and exclusions, proof without case studies and one source for the team.
How do you describe a service so that everyone in the firm says the same thing about it? Write it down in one document with eight fields: the client’s problem, the outcome, who it’s for, scope, what the service doesn’t include, timeline, pricing model and proof. You copy from that document into proposals, the website and decks, and regularly, say once a quarter, you check that it still matches what you sell.
In this post I’ll show a template for those eight fields, a filled-in example, how to describe scope, and what to put down as proof when you don’t have case studies yet.
What a service description is
A service description is one document that says what the firm sells, to whom, in what scope and on what terms. It isn’t a contract or a proposal for a specific client. It’s the source that proposals, the service page and sales emails are built from, so you keep a B2B service description in one place.
Buyers form an opinion before they talk to your team
In 6sense’s 2025 study (nearly 4,000 B2B buyers, with services the largest share of purchases described, 41%), buyers first contacted a vendor on average when they were 61% of the way through the buying process. In 79% of cases it was the buyer who started the conversation, not the seller. The vendor the buyer favored before first contact won roughly 80% of the time. According to the same report, buyers, although nearly all of them now use AI tools, still rely on vendor content and third-party experts. In my view, in services that content is mostly the website, proposals circulating inside the client’s company and what referrers say about the service, in other words descriptions your team has already given someone. If everyone described the service differently, the buyer arrives with a picture nobody at your firm planned.
“We do SEO” or “we implement systems” is not enough. That’s the name of a category: it doesn’t say what problem you solve, what the client gets and what they don’t. When there’s no written description, everyone who sells fills those gaps their own way. The owner talks about the full scope, the account manager promises a quick result, and last month’s proposal has yet another list of work.
In 2002 David Maister described this as a common source of fee resistance: the firm is trying to sell the “thorough” version of the project, while the client is trying to buy the “quick impact” or “lowest up-front cost” version (“Responding to Fee Pressure”). A written service description shows the buyer which version you sell before the price comes up.
How to write a service description: eight fields
Here are the fields I recommend in every description. Each one answers one question the buyer asks before getting in touch.
| Field | What you write | The buyer’s question |
|---|---|---|
| Problem | what the client wants to solve, in their words (from emails and sales call notes) | “Is this about my problem?” |
| Outcome | what the client has when you’re done; something that can be checked | “What will I have at the end?” |
| Who it’s for | the type of client and situations where the service doesn’t fit | “Is this for a firm like mine?” |
| Scope | what you do, and what the client has to do or provide | “What exactly do I get, and how much work is it for me?” |
| What it doesn’t include | things close to the scope that you don’t do, and what you do with such a request | “Is X included too?” |
| Timeline | how long it takes and what that depends on | “When will it be ready?” |
| Pricing model | fixed price, retainer or hourly; an amount or range if you publish one | “How much does it cost and what am I paying for?” |
| Proof | a project, a result or a reference; without them: what replaces proof | “How do I know it will work?” |
The “who it’s for” field is easiest to fill in once you have an ideal client profile. I covered that in How to create an ICP for a B2B service firm. If you’re unsure which services to sell as separate items, the post on agency specialization will help.
Write the scope and what you don’t do most precisely
Maister wrote that with fixed-fee pricing the firm must make sure the contract states very precisely what is and what is not included in the job. In my view this applies to every pricing model, because a scope dispute usually starts with a sentence each side reads differently.
In the “scope” field, list specific work and deliverables, and next to them what you need from the client: access, people, approval deadlines. In the “what it doesn’t include” field, list things close to the scope that the client is likely to ask about. For a website audit, that might be implementing the fixes or writing content. Also add what you do with such a request: quote it separately, refer someone, or decline.
When you have no proof, say what replaces it
Maister observed that most fee resistance comes from skepticism about the value that will be received, and that you need to demonstrate, not just assert, your capabilities. That’s why the “proof” field belongs in the description even if you’re just starting to sell the service.
The best proof is a project with a result or a client who agreed to be a reference. When you don’t have them, you can’t demonstrate value, but you can reduce the buyer’s risk so they can check it themselves without risking the full amount. Write down what makes that possible: a pilot, a small starting scope or a money-back guarantee. Don’t list results you can’t show, and don’t name clients without their permission.
Example: a service description filled in completely
This is an illustration, not a real firm: take an agency that does technical SEO audits for online stores.
| Field | Example (illustration) |
|---|---|
| Problem | the store loses Google traffic after changing platform or theme and doesn’t know why |
| Outcome | a list of technical errors with priorities and fix instructions for the store’s developer |
| Who it’s for | online stores with an in-house or external developer; not for stores with nobody to implement the fixes |
| Scope | site analysis with crawling tools, a review of Google Search Console data, a report and one call with the developer; the client provides Search Console access and names the developer |
| What it doesn’t include | implementing the fixes (quoted separately after the audit), writing content and ad campaigns (we don’t do these and refer an agency that specializes in them) |
| Timeline | 4 weeks from receiving access, 6 weeks for stores with more than 10,000 products |
| Pricing model | a fixed price for the audit, given in the proposal after a short call about the store’s size |
| Proof | two earlier store audits describing the errors found, with the clients’ permission; without them: an audit of one product category as a pilot |
The “what it doesn’t include” field lists the things a store client will ask about first, and says right away what you do with them.
One description instead of ten versions in decks
A description does its job when the firm has one version of it. Keep it in one place (a document on the company drive or a file in a repository), name one person who changes it, and copy from it into proposals and the website instead of writing the scope from scratch. You can call it a service sheet.
When you change the service, don’t delete the old version without a trace. Mark it as superseded, with a date and a link to the new one, so nobody sends a client the old scope or the old price. I recommend reviewing it every quarter and after every lost proposal where the client asked about scope or price.
We write one service description in this format together with the client at the start of a Claude Code setup in their firm; details are on the Claude Code Team Start page.
Frequently asked questions
How is a service description different from a contract or an SOW?
A service description is shared across all clients and says what you sell. A proposal and an SOW (statement of work for a specific project) take the scope and exclusions from it and add the details of one client. You prepare the contract with a lawyer; the service description doesn’t replace it.
How many services should I describe?
Every service you sell as a separate item gets its own description with all eight fields.
Who should own the description?
One person who sells or runs the service and has the authority to change the scope. Everyone else sends them corrections instead of changing the description in their own proposals.
Summary
Buyers form an opinion about a service before they talk to your team, so what they read should match what they hear from everyone who sells it. If your service has several versions in proposals and decks today, start with the one you sell most often. Fill in the eight fields, have two people who sell it check the description, and put the first review date in your calendar.
Every method on this blog also runs as a skill in the open-source B2BForce repo. About the repo