Home About Experience Projects Case studies Resources Articles Briefs Playbook Tools FAQ How we start Security Get in touch

Case study 14

Procedures written while doing the work, and the case for automating it

Confidential engagement, described by its shape. Every image and file on this page is rebuilt with invented data.

All case studies · 14 of 15

Every queue got a written procedure, built while the work was being done. The day's record moved into a log that survives a reset. Then the manual work was mapped into a proposal: an estimated up to about 80% of manual processing time in scope for automation, conditional on vendor work.

There were no written procedures. Each queue was learned by watching the supervisor work it, and the documentation that existed did not always match what the supervisor actually did. My own record of the day sat in a working session that could be lost.

SOPs from live walkthroughs. Every queue got its own SOP, written during or straight after a walkthrough: scope, order of work, a decision table, field rules, templates, what to capture, and known gotchas. Walkthroughs were transcribed so steps could be checked against what was said. The triage SOP has six possible actions and a three-condition delete rule: same person, same date, a complete shift present. Anything else is a contact or an escalation.

A source order, written down. When sources disagree, a confirmed live instruction beats the documentation, and the documentation beats general practice. Anything I had not seen confirmed was tagged CONFIRM in the SOP until the person who owned the rule answered. When a rule was clarified, the SOP changed that day.

A log that survives. Every update goes into a dated log file as it lands: local time, client time, system, and a status in the operator's own words. The file is checkpointed at midday and at the end of the day. Counts are derived from log lines only. If a number cannot be traced to a line, the report says "not recorded".

An append-only handoff. At the end of each day the handoff gets new lines and never loses old ones. It closes with open items grouped by owner and the last copy of every queue, row by row, so the next session starts where this one stopped.

Then the case for automating. With every queue written down, I mapped each workflow as a lane, current state against proposed state, with estimated minutes per step. Every step got one label, keep manual, assist, or automate, and the condition that has to be true before it changes.

Automation flow map (demo): lane 1, daily exceptions

Current stepLabelNowThen
Export the morning queueAutomate~10~3
Compare with yesterday by eyeAutomate~25~7
Group by cause, route to ownerAssist~20~8
Type outreach emails one by oneAssist~35~12
Decide the edge casesKeep manual~15~15
Lane total, est. minutes per day~105~45
Lane = sum of step minutes   all five lanes: ~353 now, ~142 proposed   estimates, not measurements

SOP-OPS-01 Weekly Sales Report: document control

FieldValue
SOP IDSOP-OPS-01
Version1.1, draft for approval
OwnerMegan Fairhall
CadenceWeekly, every Monday, sent by 11:00
TriggerWeekly sales export lands in the Inbox folder (Monday, around 08:00)
Time neededAbout 45 minutes
ID = SOP-DEPT-NN, never reused   1.0 first written, 1.1 after the second real run   CONFIRM until the owner answers

The number, honestly. The map put up to about 80% of manual processing time in scope. That is an estimate, conditional on vendor work, to be refreshed after a timed week of real volumes. It is not a result, and the proposal says so.

Automation flow map: daily exceptions lane, current and proposed steps labelled automate, assist or keep manual with estimated minutes
Flow map: every step labelled, minutes estimated
SOP-OPS-01 Weekly Sales Report first page: document control block, purpose and numbered steps with exact locations
An SOP on the shared template, steps with real locations
SOP library readme: department folders, ID scheme, versioning rules and the source order when sources disagree
Library rules: IDs, versions, which source wins

Click any image to see it full size. Every file here is rebuilt with invented data.

The results, in bands. An SOP for every queue, kept current. No counts lost after the log moved into a file. A banded estimate with its conditions attached.

What went wrong
  1. A morning's counts were lost when a session reset, and the end-of-day report went out with gaps. The log moved into a file with midday checkpoints.
  2. Waiting-on-reply totals were first worked out by subtracting fixes from the previous day's number, and they drifted. Waiting lists are now rebuilt name by name from the latest queue.
  3. A written reimbursement rule and the operator's call differed on one hold. I followed the operator, logged it, and asked the rule owner whether it should become standing, instead of quietly picking one.

Case study 14

Procedures written while doing the work, and the case for automating it

WhereA back-office provider running time and spend administration for many small client accounts; details changed
RoleRemote operations assistant to the supervisor; owner of the procedure library and the daily record
ScaleSeveral daily queues across two timekeeping systems; one SOP per queue; one flow map across every workflow
StackSpreadsheets, scripts, a shared task tracker, email