The short answer
Define inputs, deliverables, exclusions, review criteria and dependencies before committing to a small creator service. Make changes and handoff explicit. A scoped draft is a proposal to discuss; it is not a signed contract, customer acceptance, delivered result or payment.
What you’ll take away
- Scope a concrete output and the evidence needed to review it.
- Keep dependencies and exclusions visible instead of promising outcomes you cannot control.
- Preserve actual agreement, changes, delivery and payment as separate states.
Name the task and what would count as done
Start with the appropriate request, not a generic package size. “Review the definitions of current followers and period gains in worksheet v1” names work that can be bounded. “Improve LinkedIn performance” leaves the deliverable and authority unclear. State who needs the output, what they will do with it and which observable review could establish that the agreed work was supplied.
GOV.UK’s user-story guidance links actor, task and goal to acceptance criteria and supporting evidence. It concerns service development, not contract law or customer acceptance of freelance work. Our proposal adapts the idea of an inspectable completion criterion. Its illustrative criteria are not a guarantee that the client’s business result will follow.
State inputs, outputs and exclusions together
List the exact source/version, permitted access and person responsible for supplying it. Define file format, language, number and content of deliverables. Separate a review note from implementation, native publication, legal/accessibility certification, private data recovery and a recurring support commitment. An omitted exclusion can change what the requester reasonably expects even if your hours estimate stays the same.
Add dependencies and provisional timing: work starts only after the agreed source and authority are available; a review date depends on the actual response window and your capacity. Price, tax, payment and cancellation terms require the appropriate actual agreement for the parties and jurisdiction. Do not publish invented universal legal terms or treat a worksheet as consent to charge.
Read a complete two-field proposal
Constructed working proposal SP1: input is permitted worksheet v1 with fields F1 current followers and F2 period gains. Output is one English Markdown review containing a definition for each field, the reported unit/window, source reference, unresolved evidence and suggested wording. A German edition, editing the live worksheet and publishing a LinkedIn post are excluded. Proposed effort is two hours, subject to actual feasibility; no price, date or contract has been accepted.
Review criteria: both F1/F2 appear once in the field table; stock and period flow are distinguished; every factual source is identified or marked unknown; missing losses and starting stock are not invented; unresolved questions and exclusions are present; the actual saved file opens in the agreed format. These checks establish the specified artifact’s contents, not platform accuracy, independent validation, adoption or a sales increase.
| Field | Review output | Not established |
|---|---|---|
| F1 | Current stock definition | starting stock |
| F2 | Period gains definition | losses or net growth |
Resolve three scope changes
SP-A — Constructed language expansion: after the English draft, a German version is requested. Decision: record the new deliverable, translation/review effort and effect on timing before agreement; do not quietly include or reject it on an assumed prior promise. Outcome: an explicit proposed change, not an accepted upsell.
SP-B — Constructed missing input: v1 lacks dates and no authorized source can establish them. Decision: report the unknown or pause the dependent work rather than fill it from a similar public example. Outcome: bounded output and a disclosed dependency, no recovered private data.
SP-C — Constructed outcome substitution: the requester wants a guarantee of ten customers instead of the review note. Decision: explain that the defined deliverable does not establish that business result and decline an unsupported guarantee. Outcome: scope clarity, not a forecast or actual ten-customer claim.
Keep change, delivery and review traceable
Version the proposal and retain the actual decision made by the authorized parties. When a change arrives, describe its effect on input, deliverable, review criteria, effort, timing and terms; keep the old version as relevant history. A casual discussion or draft file is not an agreed change. Do not infer acceptance from a read receipt or an automatic download.
At handoff, identify the actual file/version, included source references, remaining unknowns, intended use and any agreed support boundary. Let the appropriate reviewer inspect it against the agreed criteria. Delivered, reviewed, accepted and paid need their own actual evidence. Archive only what is necessary and appropriately protected; do not turn the private engagement into a public case study without permission.
Use the proposal as a decision document
The packet provides the complete SP1 proposal, its criteria and a blank private scope/change record. Keep purpose, authority, exact input, outputs, exclusions, dependencies, provisional estimate, real agreement state, changes, actual handoff and review result. The local checker verifies the two declared field IDs and state boundaries, not a contract, customer acceptance, invoice or payment.
The primary service-design guidance was read on 1 November 2026; it is historical official guidance, not a new experiment or legal source. All proposal details and SP-cases are constructed. No client was contacted, no proposal accepted and no work billed. The service-listing guide and inbound-review guide cover the preceding distinct decisions.
- Record the task, scope and actual authority.
- Inspect inputs and evidence state at the actual source.
- Work through the full proposal with dependencies and unknowns.
- Record the decision, owner and next permitted step.
- Verify actual results separately from plans and constructed examples.
Sources & product references
Product details reflect the publication date. External features and interfaces may change.
