Ways of working

A short operations handbook for a small service business

Here is one way an operations manual can fail: someone sets out to write the whole business down, gives up halfway, and the document is never opened again.

Start smaller. Capture the next recurring job that someone else needs to do without asking the founder at every step. Write it down well enough for an authorised colleague to follow, test it, and give it an owner. Then do the next one.

This guide gives you a minimum handbook structure, a task card you can copy, a completed example and a simple cover test. Together they show whether someone else can actually use what you wrote.

1. Know what kind of document you are writing

These three terms are easy to mix up:

  • Operations handbook (or operations manual): the home for how your day-to-day service work is done. It holds an index and links to individual procedures.
  • Procedure (sometimes called an SOP, standard operating procedure): step-by-step instructions for one task, such as checking a new job before work starts.
  • Employee handbook: your employment policies, such as leave, conduct and grievance. That is a different document with different responsibilities.

This guide covers the first two. Keep employment, health and safety, data protection and any sector-specific policies in their own documents, and link to them from your handbook. A template does not satisfy any of those legal duties for you, so do not copy policy wording into an operations page and assume it covers them.

2. Choose your first three procedures

Do not try to document everything. Pick three tasks using three questions:

  • How often does it happen? A written instruction for recurring work gets used again and again.
  • What goes wrong if the usual person is away? Start where an absence causes real problems.
  • Where does work get stuck between people? Handoffs can cause chasing and rework.

For a service business, three possible starting points are responding to enquiries, handing accepted work to delivery and running delivery checks. Write one in full, test it, and only then start the second.

3. Set up the handbook structure

You only need four parts to begin. Keep them in a tool you already use, such as a shared drive, a wiki or a shared notebook. What matters is that there is one current location, the right people can view it, only the right people can edit it, and everyone knows where it is.

Handbook home card

Field Your handbook
Purpose and scope
Current home (where it lives)
Handbook owner and backup
How to find a task
How to suggest a correction
Links to separate specialist policies
Version and last review

Procedure index

Procedure When to use it Accountable role and backup Where the current instruction is Last checked Next review trigger

Change log

Date Page and version What changed and why Reviewer Check completed

The fourth part is the task card itself, below.

4. Write one task card while you do the task

Write the card while you, or the person who usually does it, are actually doing the task. Working from memory can skip steps that have become automatic, and those may be the ones a new person needs most.

A good card is more than a description of a role. It tells someone:

  • what they need before they start, including how to get access
  • what to do, in order, and what they should see after each step
  • how to tell the task is finished
  • when to stop and who to ask

Task card (blank)

Field Your task
Title
Purpose
Trigger (when to do it)
Scope and exclusions
Owner and backup (roles)
Inputs needed
Tools and how to request access
Done when
Exceptions and who to escalate to
Where the record is kept
Version
Reviewer
Last tested
Next review trigger

Steps

Step What to do Expected result
1
2
3
4
5

Write the access route, never the password. A line such as "ask the operations lead to add you to the job system" is useful. A shared password pasted into the handbook is not, and anyone who can read the page could use it. Grant access through your normal process, even if a shortcut would be quicker.

Leave out personal and client details too. Use roles rather than names, and invented examples rather than real customers. The UK regulator's guidance on data minimisation says personal data should be adequate, relevant and limited to what is necessary for your purpose. An instruction page can be written without any.

5. Example: a completed task card

This is an illustrative example, not a ScalePass client's procedure. It covers the check a delivery lead makes after a customer accepts a quote.

Field Example
Title Delivery handoff check after quote acceptance
Purpose Make sure the delivery lead has everything needed to plan the work before taking it on
Trigger A customer accepts a quote
Scope and exclusions Covers checking and accepting the brief. Does not cover invoicing or changing the agreed scope
Owner and backup Delivery lead; backup is the operations lead
Inputs needed Accepted quote, agreed scope, customer contact route, site or access notes, any agreed constraints
Tools and how to request access Job system and shared calendar; ask the operations lead for access
Done when The delivery lead has recorded acceptance of the brief and the first scheduled action on the job
Exceptions and who to escalate to Missing information goes back to the quote owner. Unclear scope stops the check and goes to the operations lead
Where the record is kept The job record in the job system
Version 1.0
Reviewer Operations lead
Last tested Record the date of the cover test
Next review trigger A change to the quoting process, the job system or the people in either role

Steps

Step What to do Expected result
1 Open the job and confirm the accepted quote is the latest agreed version The scope you are checking matches what the customer accepted
2 Check the required customer information is present: contact route, location or access notes, agreed constraints Every required item is present, or you have a list of what is missing
3 If anything is missing, send the job back to the quote owner with the list, and stop here The quote owner has the job back and knows what to supply
4 If the scope is unclear or does not match the quote, stop and escalate to the operations lead Nobody starts work on an unclear scope
5 Confirm you are the delivery owner for this job and record your acceptance of the brief The job shows you as owner, with acceptance recorded
6 Record the first scheduled action and its date on the job Anyone opening the job can see what happens next and when

This card covers one handoff. If you want to map the whole route from enquiry to delivery first, do that separately; the card is the instruction for one step within it. For the full process of handling new enquiries, see our guide to managing customer enquiries.

6. Test it with someone else

A procedure is only proven when someone other than the writer can follow it. Ask an authorised colleague to complete the task using an invented test job and only the card. The writer should watch and take notes, but not fill in gaps along the way.

Cover test checklist

  • They found the current page without help.
  • They already had, or could request through the normal route, the access they needed.
  • The inputs listed were enough to start.
  • They could carry out every step as written.
  • They could tell when the task was done.
  • They knew what to do when something went wrong, and who to ask.
  • Every problem was written down.
  • The owner updated the page and the test was repeated.

If access was the problem, fix it through your normal process. Do not bypass it to make the test pass.

7. Keep it current

A handbook goes out of date quietly. Give every page:

  • An owner: the role responsible for keeping it accurate.
  • A last-checked date: when someone last confirmed it matches reality.
  • A reason for each change: recorded in the change log.
  • An approval step: someone other than the editor checks significant changes.
  • Review triggers: a change of tool, process or person in the role should prompt a review, whatever the date.

How often you review should depend on the risk. A page for a rarely used, high-stakes task may need checking more often than one for a simple daily job. There is no single schedule that suits every page.

8. Start with one useful page today

Pick the task that would cause most trouble if its usual person were away tomorrow. Write its card while doing it, test it with a colleague and add it to the index. That single page is worth more than a full manual that nobody uses.

Common questions

How long should an operations handbook be?

As short as possible while still being usable. Start with the home card, an index and one tested procedure. Add pages as you need them, not to fill a template.

Where should it live?

Somewhere your team already works, with one current version, sensible view and edit permissions, and an index people can find. Avoid copies scattered across desktops and inboxes.

Is this an employee handbook?

No. This is about how the work gets done. Keep employment policies in a separate employee handbook and link to it.

Who updates it?

Each page has an owner role, and the handbook as a whole has an owner and backup. Anyone can suggest a correction; the page owner makes and records the change.

What if the owner is the whole team?

Then name one role as the default owner anyway, and a backup. "Everyone" can easily mean nobody checks.

What should never go in it?

Passwords and other credentials, unnecessary personal or client details, and copied legal policy text presented as if it were your own policy. Link to the proper source instead.

ScalePass helps service businesses connect the tools and steps they already use, one agreed and scoped improvement at a time. If writing your handbook shows a step that needs connecting, Explore connected systems.

Back to the blog