What to Include in A Service Brief
What to Include in A Service Brief is best handled by mapping the repeat work, preparing the source inputs, deciding which items need human judgment, and then using a done-for-you service workflow to produce reviewed output instead of asking the owner to manage another tool.
This guide is for owners, operations leads, and project managers who routinely write service briefs — internal scoping documents, client-facing project briefs, vendor briefs, or proposal precursors — and want a working checklist of what each one needs. The same structure applies whether you write the brief yourself or delegate the drafting.
Direct answer - What to Include in A Service Brief
A service brief includes six core sections: background, scope, inputs and outputs, constraints, success criteria, and review and approval. Each section answers one question that the work cannot start without. A brief missing any of the six leaves the reader (or the AI-assisted drafter) to guess, and guessing is where briefs go wrong.
Section 1: Background
The background section answers “what is going on here?” in one short paragraph. It names the business, the situation that triggered the work, the relevant history, and any decisions already taken. Two or three sentences are enough. The background is not a sales pitch; it is the context the next reader needs.
Section 2: Scope
The scope section is the most important. It lists what is in and what is out, in concrete terms. “Build a customer onboarding flow” is not scope; “draft a 6-step onboarding email sequence for new accounts in the standard tier, in the existing brand voice, with no SMS component” is scope. Where the scope is ambiguous, name the ambiguity and say which side it falls on.
If the scope has more than one variant — a smaller and a larger version — write the variants out and mark which is the default.
Section 3: Inputs and outputs
Inputs are what the client provides; outputs are what the work produces. Be specific:
- Inputs: which files, which CRM exports, which contact lists, which access. Use the names that exist in the client’s environment.
- Outputs: format, file type, channel of delivery, and structure. “A spreadsheet” is not enough; “a Google Sheet with one row per record and these columns” is enough.
The input/output section is the part a done-for-you service uses as intake. If it is wrong here, every other step downstream inherits the error.
Section 4: Constraints
Constraints are the rules the work has to respect. Common categories:
- Time: deadlines, milestone dates, blackout windows.
- Budget: an explicit number or a band.
- Tooling: tools the client requires or forbids.
- Voice: the brand voice file, banned phrases, required phrases.
- Compliance: regulated topics (medical, legal, financial, regulated industries) and the wording rules that apply.
- Data: which data the work can use, which it cannot.
A constraint that is not written down is not a constraint. The brief lists every one explicitly.
Section 5: Success criteria
Success criteria are how the client decides the work is finished. They are checkable, not aspirational: “the email sequence has been reviewed by the owner and queued in the marketing tool” is checkable; “the email sequence performs well” is not. If a criterion is genuinely outcome-shaped — leads booked, deals closed — name it as a goal of the engagement, not as a success criterion of the brief.
A note on results: ElaborationAI does not promise revenue, ranking, advertising, legal, medical, or financial results, so those do not belong in success criteria. The brief can describe the deliverable; it does not promise downstream business outcomes.
Section 6: Review and approval
This section defines who reviews, what they review for, and how approval is recorded. It names:
- The reviewer (the owner, the operations lead, a domain expert).
- The review focus (tone, factual accuracy, brand voice, compliance, etc.).
- The approval channel (email, a shared document, the workspace order flow).
- The fallback if the reviewer is unavailable.
When the work is delegated to a done-for-you service, the review section is the explicit handoff: ElaborationAI ships the draft, the client reviews against the named focus, and the workflow either closes or returns to draft for one revision pass.
Service-brief checklist
Use this to audit a brief before sending it:
- Background: one paragraph, business and trigger named.
- Scope: in/out written concretely, ambiguities resolved.
- Inputs: every file and access named, in the client’s vocabulary.
- Outputs: format, file type, channel of delivery, structure.
- Constraints: time, budget, tooling, voice, compliance, data — each one explicit.
- Success criteria: checkable items only, no outcome promises.
- Review: reviewer, focus, channel, and fallback all named.
If any line is “no,” fix that line before the work starts.
Related services - What to Include in A Service Brief
These canonical service pages cover the workflow:
What ElaborationAI is and is not - What to Include in A Service Brief
ElaborationAI is a services company delivering done-for-you AI-backed business work with human review. We are not a SaaS product, not a self-serve subscription, not a payment processor, and not a marketplace for virtual assistants.
FAQ - What to Include in A Service Brief
What should this guide cover?
Intake, AI-assisted production, human review, and workspace delivery for the agreed guide scope.
What inputs should the reader prepare?
Past briefs, the project background, the scope variants, the constraints, the audience, and the delivery channel.
How is human review used?
A reviewer checks missing context, factual errors, risky wording, and obvious inconsistencies before delivery.
Is what to include in a service brief a self-serve tool?
No. ElaborationAI runs the workflow; the client provides inputs and decisions.
How does this connect to pricing?
Pricing is quote-based through the workspace order flow. The guide describes common pricing drivers but publishes no fixed prices.