A list of steps can describe activity without explaining what successful work looks like. For a consultant mapping an organisation, that leaves important questions unanswered: who owns the result, what makes it acceptable and what happens when the usual sequence breaks?
A useful SOP supports both execution and discovery. Test it with a concrete workflow, such as preparing a marketing agency’s monthly client performance report. The example below is illustrative; the client’s reporting commitments and approval process must determine the final procedure.
Make the starting point explicit
Replace “prepare the report” with a defined trigger: the reporting period has closed and the required source data is available. Identify the role preparing the report, the person approving it and the systems supplying the data.
In discovery, ask whether those conditions actually hold. A scheduled reporting date does not prove that the source data is complete. If the team routinely starts with missing information, capture that dependency rather than leaving it outside the SOP.
Describe the finished work
State the outcome before refining the steps. In this example, it could be an approved client report containing the agreed measures, an explanation of material changes and named next actions. The procedure should show how someone checks that result.
A finished-work example might include a reporting period, data source, commentary, action owner and review status. Label it as an example, then ask the client which fields are required and what would make the report unacceptable. This turns a vague quality standard into something the team can discuss.
Explain why each control exists
Consider the business, customer and employee separately. A review may protect the agency from sending unsupported claims, help the client understand what needs a decision and reduce the analyst’s avoidable rework.
Ask what evidence supports those reasons. If nobody can explain a repeated approval step, investigate it. If a step protects an important commitment, preserve that purpose when considering automation. A faster procedure that removes a necessary check is not automatically an improvement.
Write the exception route
Suppose a source system is unavailable or two reports disagree. The SOP should identify what the preparer can resolve, what must wait and which role decides whether to issue the report with a stated limitation. The correct response belongs to the client’s operating rules; a generic reference cannot authorise it.
For an AI-assisted reporting proposal, also specify which parts may be drafted, what evidence must support the commentary and who reviews the final output. Put those decisions into the proposed workflow, separately from the current-state SOP.
A five-question review
- Can someone identify the trigger and accountable owner?
- Are required inputs and systems named?
- Is completion demonstrated by a clear output or example?
- Are the reasons for key checks understood?
- Can someone follow an exception to a named decision-maker?
If an answer is missing, turn it into a discovery question and assign it to the workflow owner. Finish the review with a dated version, the unresolved questions and the person who can approve the client-specific procedure.
Start with a consistent SOP structure
Operating Library’s editable PDFs include an overview, roles, typical software, triggers, steps, outcomes, finished-work examples, reasons for the workflow, and judgement and exception guidance. They give consultants a prepared structure to validate with each client.
Find your industry’s SOP library and choose a licence for your business or consulting work.
