1.2Statement of work
The essentials in 30 seconds
- SOW = the common reference: you price, compare and judge conformity on this basis.
- Functional by default (expected outcomes, open competition), technical only if justified.
- Acceptance written beforehand: checks, tolerances and tests set before purchase, not after dispute.
Running mini-case — Nadia and the packing SOW
Nadia must pack 5,000 date boxes a month in Algiers. Instead of copying a provider's datasheet, she writes a functional SOW: throughput, visual quality, lead time. Only casing dimensions compatible with her line are imposed, with written justification. Three providers reply with different but comparable solutions.
Sequel to case 1.1 — Nadia moves from challenged need to a SOW that prices right.
1. What a statement of work is for
The statement of work (SOW) is the common reference: suppliers price on this basis, offers are compared on this basis, conformity is judged on this basis in case of dispute.
Done well, it lets suppliers reply accurately, makes offers comparable and protects both parties. Vague, it produces incomparable offers, underestimated quotes that inflate ("it wasn't included") and dead-end disputes.
A well-built two-page SOW beats a copied tome: complete on essentials, precise on verifiable, silent on what can stay open.
2. Functional vs technical
The functional SOW describes expected results: "equipment must process X units/hour" without imposing the method. It lets suppliers propose their best solutions and keeps competition alive.
The technical SOW imposes the solution: dimensions, materials, standards, processes. It is required when compatibility, regulation or like-for-like replacement demands it.
Golden rule: specify the result as much as possible, the solution only when necessary. Each unnecessary technical requirement reduces competition and raises price.
3. Context, acceptance criteria and lock-in
Complete with contractual context: quantities and cadence, lead times and place, quality requirements, expected services (installation, training, warranty, after-sales) and inspection methods on receipt.
Write acceptance criteria before purchase: how conformity will be verified, by whom, with what tolerances. It's your main protection on delivery day.
Hunt supplier lock-in: a spec copied from a brand de facto bans competition. For each technical requirement, note the justification: what has no justification is a costly habit.
🔎 Concrete example — Mixed SOW for a packaging service
Need: pack 5,000 boxes/month. Functional SOW sets throughput, visual quality and lead time; only encasement dimensions compatible with the existing line are imposed technically, with attached justification.
Gain: three suppliers propose different solutions (manual, semi-auto, outsourced) all comparable on outcome.
Protection: acceptance criteria (sample, tolerance, receipt test) prevent disputes on finish.
Section vocabulary
- Statement of work (SOW)
- Reference document describing what is expected; basis for pricing, comparison and conformity judgement.
Simple example: Nadia's packing SOW makes three providers price on the same basis.
What it is not: a vague verbal message like “do your best”.
Reflex: no high-stake purchase without a written SOW.
- Functional SOW
- Describes need in results and functions without imposing solution; opens competition.
Simple example: process 5,000 boxes a month without imposing the machine.
What it is not: imposing the sealer brand by habit.
Reflex: phrase each requirement as measurable outcome first.
- Technical SOW
- Describes solution in precise characteristics (dimensions, materials, standards); needed for compatibility or regulation.
Simple example: casing dimensions imposed because the existing line requires it, justification attached.
What it is not: copying a brand's dimensions for no reason.
Reflex: each technical line = one written justification opposite.
- Acceptance criteria
- Verifiable conformity conditions on receipt (checks, tolerances, tests); to write before purchase.
Simple example: validated sample, sealing tolerance and receipt test written before tendering.
What it is not: debating conformity after delivery with no reference.
Reflex: write the receipt check before sending the SOW.
- Supplier lock-in
- Spec that de facto bans competition (imposed brand); to hunt in every SOW.
Simple example: Nadia spots a copied manufacturer reference and rephrases it as function.
What it is not: validating a SOW offered by a supplier.
Reflex: re-read each SOW hunting the hidden brand.
In practice — Write a simple, solid statement of work
- Pick a significant purchase and write the need as functions: what must the product enable with what measurable performance?
- Add technical only where justified (compatibility, standard, safety) — note justification opposite.
- Specify context: quantities, lead times, place, quality, expected services (warranty, installation, after-sales).
- Write acceptance criteria: how will you verify conformity on receipt, by whom and with what tolerances?
Ready-to-say script — demand technical justification (30 s)
“This technical requirement imposes a single solution: can you write in one sentence why it is essential — compatibility, standard, safety? Without justification, I rephrase it as expected outcome to keep competition alive.”
Say to the requestor or the supplier pushing their datasheet; log each justification in the SOW.
Copy-paste template — one-page SOW
EXPECTED OUTCOME (functions + measurable performance): _______________
IMPOSED TECHNICAL + JUSTIFICATION: _______________
QUANTITIES / LEAD TIMES / PLACE: _______________
SERVICES (installation, warranty, after-sales): _______________
ACCEPTANCE (checked by whom, tolerances, tests): _______________Small business / tight budget
One page is enough: expected outcome, lead time and receipt criterion written straight into the purchase order.
Algeria SME
Specify delivery place, manual language and locally available after-sales for any imported equipment.
Service contract
Describe the deliverable and its observable level rather than the provider's method.
Repeat purchase
Freeze a framework SOW once, then order by simple calls without rewriting it.
✓ Best practices
- Write acceptance criteria before tendering: they frame expected quality and ease receipt.
- Limit SOW to two useful pages: verifiable essentials beat generic tome.
- Have a non-expert proofread the SOW: if they understand it, suppliers will too.
✗ Common pitfalls
- Copy-pasting a SOW found online without adapting: it locks without reason and misses your true need.
- Forgetting acceptance criteria: without them, conformity is debated after the fact without reference.
- Multiplying unjustified technical requirements: each useless line reduces competition and raises price.
Key takeaways
- SOW is the common reference for pricing, comparison and conformity judgement.
- Functional by default (open competition), technical only if justified.
- A vague SOW creates incomparable offers and guaranteed overcosts.
- Acceptance criteria are written before purchase, not after dispute.
48h Challenge — apply tomorrow
Pull out 1 SOW or 1 high-stake order and add your acceptance criteria (who checks, how, with what tolerance). Have a non-expert re-read it: do they understand? 20 minutes is enough.
- I can tell functional from technical SOW.
- I can write a verifiable acceptance criterion.
- My SOW or order now carries a receipt check.
Frequently asked questions
Functional or technical: how to choose?
Specify as functional everything that can stay open (results, performance) and impose technical only for compatibility, standards or like-for-like replacement, with written justification. Result is a mixed SOW: functional core framed by minimum necessary technical.
Do we need a SOW for a small purchase?
No: proportionate. Routine purchases → reference and quantity suffice. Significant purchases → one-page statement. High-stake purchases → full SOW. A modest but critical or very recurring purchase deserves moving up a level.
Which SOW most favours competition?