Start with the customer’s need and the service outcome
A service description should answer a simple question: what will the customer receive, and what problem is the service meant to address? Begin with the customer’s situation rather than a list of your skills. For example, “I organize an existing set of product pages so customers can find key information more easily” is more specific than “I provide website consulting.” It identifies both the work and its intended purpose without promising a particular sales result.
Next, name the final deliverable in terms a customer can recognize. A freelancer might provide a written page plan, three revised page drafts and a short handoff call. A small team might deliver a configured booking process and instructions for using it. Distinguish these outputs from hoped-for outcomes. You can explain that the work is designed to support clearer communication, but you should not imply that every customer will see the same business result.
Draw a visible boundary around the work
List the main activities included in the service and give them sensible limits. “Review up to five existing pages, propose a revised structure and rewrite three pages” gives a customer more to work with than “improve your website.” Where relevant, specify the format of the deliverable, the number of items covered and whether meetings, implementation or training are included. Use everyday language; customers should not need to decode your internal process.
State important exclusions close to the inclusions. If the service includes page copy but not design, photography or publishing, say so. Exclusions are not an attempt to avoid helping; they make it easier to discuss additional work before either side assumes it is part of the original service. If customers commonly ask for a related task, explain whether it can be quoted separately rather than leaving the question unanswered.
Explain what you need from the customer
Service delivery usually depends on information, access or decisions from the customer. Describe these inputs plainly: an existing draft, access to a shared folder, brand guidelines, a single point of contact or approval from the person responsible for the project. This helps the customer judge whether they are ready to begin and reduces delays caused by missing materials.
Be equally clear about the process. A simple sequence might be intake, review, first draft, feedback and final handoff. Explain when the customer is expected to respond and what happens if they need more time. If your timeline depends on receiving materials or approvals, describe it as conditional: “The first draft is planned for one week after I receive the completed intake materials.” This is more useful than a deadline that silently assumes everything will arrive on time.
Define feedback, revisions and completion
Customers may interpret “revisions included” in very different ways. Say how many feedback rounds are included, what kind of changes they cover and how feedback should be submitted. For instance, one consolidated round may cover changes to wording and organization within an agreed page plan. A request to add several new pages would be a change in scope, even if it arrives during the feedback stage.
Describe what counts as complete. Completion could mean delivery of editable files in an agreed format, a walkthrough and a final opportunity to report missing items from the agreed scope. If ongoing support is available, distinguish it from the initial service. Clear completion criteria make handoff less awkward and give both sides a shared reference if a question comes up later.
Test the description before publishing it
Read your draft as someone who has never worked with you. Can that person identify the deliverable, what is excluded, what they must provide, how feedback works and when the work ends? Look for broad phrases such as “full support” or “everything you need.” Replace them with concrete descriptions, or explain the conditions that limit them. A short, specific description is usually easier to discuss than a long list of impressive but undefined benefits.
Finally, check that the description matches how you actually work. If every project starts with a discovery conversation before the scope is settled, say that rather than presenting a fixed package as suitable for everyone. Keep a reusable core description, then confirm project-specific details with each customer before work begins. That approach gives customers a clear starting point while leaving room for services that genuinely need to be tailored.
