Writing the Workflow Down (One Page)

Tuesday, Noor's second day on the desk at Redbrook Engineering. The instruction from the desk lead on the way to a meeting was "just follow the workflow". Noor looks for the workflow. There is a forty-page manual for the ticketing tool, which explains what every button does and nothing about when to press it. There is a wiki page called "Ticket Process" that was last edited by someone who no longer works there. It describes a status called Triaged that the drop-down does not contain. There are three technicians, and Noor asks each of them what to do with a ticket that is waiting for a part. One says On Hold. One says Awaiting Reply, "because we are awaiting something". One says "I just leave it In Progress and put a note". Noor picks On Hold, writes a note, and spends the rest of the morning wondering which of the three was right.

A workflow page is the single sheet that answers Noor's question for every state and every move. It says what the statuses mean, which moves are allowed, who may make them, and what travels with each. It also says what to do in the three or four situations that come up every day. It is one page because a trainee has to be able to read all of it on their second morning. They have to find the relevant line in ten seconds on their third. This article is part of our Ticket Workflow & Status Design series. It is the last one, because the page is where the other five end up.

It covers why the document must be one page and what that rules out, then what goes on it, section by section. Next comes how to write it from the tickets rather than from a meeting. Then come the states section, the moves section and the examples section in turn, followed by the who column and how it maps to the tool's permissions. Next are the twenty-minute training that goes with the page and the ten-ticket exercise that follows it. How to keep the page current without a committee, and the page itself, as a template, come at the end. The thinking behind each section lives in the earlier articles. The whose-move question is in What a Status Is For. The one-sentence definitions are in Statuses That Mean Something. The waiting rules are in Pending User vs Pending Vendor vs On Hold. The diagram is in Workflow Simplicity. The end states are in Resolved vs Closed. This article compresses all of it onto a sheet of paper.

Why One Page

The workflow document is one page because any longer document is not read, and a workflow that is not read is three private workflows wearing a cover sheet. A page is read on the second morning in fifteen minutes. A page is pinned beside a monitor and consulted with a glance. A page is handed to the person covering for a week and actually followed. A twelve-page process document is opened once, on the day it is announced, by the person who wrote it, to check the formatting.

One page also forces the choices that make the workflow good. You cannot fit twelve states on a page with a sentence each and a move table, so you choose six. You cannot fit every exception, so you write the rule and the three exceptions that happen weekly and leave the one that happened once to a note. You cannot write a paragraph per move, so you write the who, the why and the what-next and discover that most moves need nothing more. The page is a constraint that does your editing for you, and it is a better editor than most committees.

The test of the page is Noor on the second day. Hand it to a new technician with no other briefing, give them ten real tickets, and ask them to set the status on each and say what happens next. If they get eight or more right, the page works. If they get five, the page has a gap, and the five they got wrong will tell you where. A page that passes the second-day test will also pass the covering-for-a-fortnight test and the manager-asking-what-the-process-is test, and those are the only three tests that matter.

Keep the manual and the long wiki page if you like; they are reference, and reference has its place. The workflow page is not reference. It is the thing a technician reads before touching the queue and glances at while touching it. It earns its single sheet by being the only document on the desk that everyone has read all of. (Most desks have none of those. One is a good number.)

What Goes on the Page

Seven sections fit on the page, in a fixed order. First come the states, the moves, the never list, and the waiting rules. Then come the window and reopen rules, three examples, and the who and changes lines at the bottom. The states section is six lines, one per status, with the tool's label, a one-sentence meaning and whose move it is. The moves section is a line per allowed transition with the who, the why and the what-next. The never list is the four or five moves and habits the page forbids, because a workflow is defined as much by what it rules out as by what it allows.

The waiting rules are the nudge cadence, the vendor chase rule and the hold ceiling, each in one line with blanks for the numbers. The window and reopen rules are the window length, the reminder day, whether the close is automatic or swept, and what happens to a reply on a closed ticket. The examples are three real ticket numbers, one line each. They show the path a simple fix, a wait on the requester and a vendor wait with a reopen took through the states. The who line says which roles may change a status, transfer a ticket and run the sweep. The changes line is a date, a version and one sentence saying what changed, so that the page carries its own history.

What stays off the page is everything that belongs to a different document. The full status definition cards, with entry and exit conditions and the "never used for" clause, are a separate page per status and the workflow page points at them. The resolving reply template belongs to the closing pillar's pages. The priority grid belongs to the SLA document. The escalation path belongs to the escalation page. The workflow page names those documents in one line at the bottom and otherwise stays out of their business. One page, one job: where a ticket can be, how it moves, and who moves it.

Writing It from the Tickets, Not from the Meeting

Write the page from twenty real tickets in one afternoon, and hold the meeting afterwards, to approve what the tickets said. The usual order is backwards: a working group meets and designs a workflow from first principles. Then it discovers that the desk already had one, unwritten. That workflow differs from the design in the five places the design will now be ignored. A page written from the tickets describes the workflow the desk actually runs, which is the only one it will follow. The meeting's job is to agree the three or four places where the actual workflow should change.

The method is to pull twenty closed tickets from the last month, chosen at random. For each one, write the sequence of statuses it passed through and what happened at each change. Twenty tickets produce a list of perhaps eight distinct paths. The three most common paths become the examples. The states that appear become the states section; the states in the drop-down that never appeared become the "not used" line. The moves that happened become the moves section, and the moves that happened but should not have become the never list. By the end of the afternoon the page has written itself. The author has read twenty tickets more carefully than anyone on the desk has read them in a year, which is a useful side effect.

The author is one person, not a group. A desk lead, or on a very small desk the senior technician, writes the draft alone in the afternoon. They circulate it the next morning with one question: "What would you do differently from what this says?" Every answer is either a correction to the page, which goes in, or a correction to someone's habit, which goes in the training. The group's involvement is an hour of reading and a few replies, which is the amount of group involvement that produces a document rather than a compromise.

I wrote my first workflow page from a meeting, with four people and a whiteboard. It had nine states and a swim-lane diagram and was adopted by nobody, including me. The second one I wrote from twenty tickets on a Thursday afternoon, alone. It had six states and fit on a page, and the desk used it for three years with eleven small changes. The difference was not that I had learned to write. It was that the second page described something that already existed.

The States Section

The states section is six lines, and each line has exactly three parts: the tool's label, the meaning in one sentence, and whose move it is. "ON HOLD: we are waiting on a supplier, another team or a date, named in the latest note with a date we will chase; an outside party's move." That is the entire line. The one-sentence meaning is the same sentence as the top of the status definition card, so that the page and the cards never disagree. Whose move is one of four words: the desk, the requester, outside, nobody.

Below the six lines is one more: the labels in the drop-down that the desk does not use, each with the state to use instead. "Not used: Pending (use On Hold or Awaiting Reply), Assigned (use In Progress)." This line exists because a trainee will see the unused labels in the drop-down on their first morning and will, reasonably, assume they are meant to be used. The line says no before the question is asked. In a tool whose status list can be edited, the line can be short, because the unused labels have been removed. In a tool with a fixed list, the line is doing real work and should be kept current.

The states section is also where the page says which labels in your tool carry which meaning, when the tool's words differ from the ones in this series. If your tool calls the requester's-move state Pending Customer and the outside-party state Waiting on Third Party, those are the words on the page, with the meaning beside them. The page uses the drop-down's spelling, exactly, because the trainee will be matching the page against the drop-down. A page that says Awaiting Reply when the screen says Pending Customer costs a question every time.

The Moves Section

The moves section is one line per allowed transition, nine to eleven lines. Each has the from-state, the to-state, who makes it, the single event that triggers it, and what happens next. The format is a compressed version of the transition table from the simplicity article: "IN PROGRESS to AWAITING REPLY: the owner / sends a reply asking a question / ticket joins the nudge filter, requester has been told what we need." Writing each move on one line is a discipline, because a move that needs two lines is usually two moves, or a move with an exception that belongs on the never list.

Order the lines in the order a ticket meets them. New to In Progress first; then the two waiting moves and their returns; then the resolving move; then the close; then the reopens; then the transfer. A trainee reading top to bottom follows one ticket through its life, and a technician scanning for a specific move finds it by where in the life it happens. Alphabetical order, or the order the tool lists the statuses, destroys that and gains nothing.

The what-next part of each line is where the page does most of its teaching, because it is the part the tool does not show. The tool shows that a ticket moved to Awaiting Reply. The page says that this means the ticket now appears on the nudge filter and leaves the desk's working list, and that the requester must have been told. The tool shows a move to Resolved. The page says that the window has started, the resolving reply carried the closing date, and the sweep will close it on that date unless the requester replies. A trainee who has read the what-next column understands the workflow; one who has only read the states knows the vocabulary.

The Examples Section

Three real tickets, one line each, teach the page faster than any amount of explanation. They should be real, with their numbers, so that a trainee can open them and read the history. The first is a simple fix: "#4120: password reset. NEW to IN PROGRESS (claimed 09:02) to RESOLVED (reply 09:06) to CLOSED (confirmed 09:40)." The second is a wait on the requester: "#4133: laptop slow. NEW to IN PROGRESS to AWAITING REPLY (asked for the model, day 0) to IN PROGRESS (reply day 2) to RESOLVED (day 2) to CLOSED (window ended, day 5)." The third is a vendor wait with a reopen, and it is the one that earns its place on the page.

Here is the third, written out, because it is the path that teaches the most. Ticket 4151 was raised on a Monday by Fatima in the drawing office at Redbrook Engineering: her second screen had died. Dev claimed it at 09:30, confirmed the screen was dead and not the cable, and found no spare. The ticket went to On Hold at 10:15 with a note reading "VENDOR: Northgate Supplies, ref 2290, promised Thursday". A reply to Fatima said a replacement was ordered for Thursday. On Thursday the sweep showed the hold date passed. The screen had arrived, so the ticket went to In Progress. Dev fitted it at 11:00, and the resolving reply went out at 11:20: fitted and tested, reply if anything is wrong, otherwise closing Tuesday. On Friday Fatima replied that the new screen flickered when the laptop was docked. The ticket reopened to In Progress with a reply from Dev within the hour saying he had it. The dock firmware was the culprit. A second resolving reply went out on Monday, a new window started, and the ticket closed the following Thursday on Fatima's "all good now".

On the page, that ticket is one line: "#4151: dead screen. NEW to IN PROGRESS to ON HOLD (vendor, Thursday) to IN PROGRESS to RESOLVED to IN PROGRESS (reopened, flicker) to RESOLVED to CLOSED (confirmed)." There are eight moves, every one of them on the moves section. A trainee who opens the ticket and reads its history sees every rule on the page applied to a real screen for a real person, with timestamps. Pick your three examples from the twenty tickets you wrote the page from, and change them once a year so they stay recognisable.

The Who Column and Permissions

The who column on each move names a role, and the roles on the page should match the roles the tool enforces wherever it enforces any. Tools differ widely here. Some have per-agent permissions in which a trainee can reply and write notes but not change a status. In those tools, a junior can claim, set priority and escalate. Only a more senior role can move tickets between states or to another department. Some have two roles, agent and administrator. Some have one. The page writes the who column against whatever the tool has. Where the tool has nothing, the page is the only thing that says who may do what. The quarterly ten-ticket test checks whether it was followed.

Write the roles in the tool's own words, as with the status labels. If the tool calls them Trainee, Agent and Lead, the page says Trainee, Agent and Lead. A page that says "junior" when the tool says "Agent" invites a question. The who line at the bottom of the page summarises the three permissions a trainee most needs to know about themselves. These are whether they may change a status, whether they may transfer a ticket, and whether they may run the close sweep. If the answer to the first is no, the page says what the trainee does instead, which is usually "tell your buddy, who moves it, and in a month it will be you".

Restricting the status change to trained people is a gift to the page, because it means the workflow is followed by the tool's enforcement rather than by everyone's memory. The cost is a bottleneck if the restriction outlasts the training. The rules sheet should say when the permission is promoted: when the trainee passes the ten-ticket exercise twice, say, or after a month. A permission that is never promoted produces a technician who has worked the desk for a year and still asks someone else to mark a ticket resolved, which is nobody's idea of a workflow.

Training on the Page

The training is twenty minutes on the second morning, with the page in hand and the queue on the screen. It has three parts: the walk, the ten tickets, and the three questions. The walk is the trainer reading the page aloud, top to bottom, with the queue filtered to each state as its line is read. The trainee sees twelve real Awaiting Reply tickets when the Awaiting Reply line is read and can see the nudge dates in the notes. It takes ten minutes and it is the only time the page will ever be read aloud, which is fine.

The ten tickets are the exercise. The trainer picks ten open tickets of mixed states and blanks nothing. For each one, the trainee is asked to say whether it is in the right state, whose move it is, and what the next action is. The trainee is right about seven or eight on the second day and about ten on the tenth. The ones they get wrong on the second day are usually the ones the desk also gets wrong. That is a finding about the page rather than the trainee. Repeat the ten-ticket exercise at the end of week one and week four, and promote the status-change permission on the second clean pass.

The three questions are the ones the trainee will be asked at 16:55 on a Friday with nobody else around, and the page should let them answer each without help. "The requester replied to a ticket we closed last month; what do I do?" The reopen line. "A supplier says the part is delayed a week; what do I do?" The vendor chase line and a new note with a new date. "I fixed it but I am not sure it will stay fixed; do I resolve it?" The resolving reply line, which says yes, with the three sentences, because the window exists for exactly that doubt. If the page answers all three, the trainee will be fine on Friday. If it does not, add the line.

Training the page is also how the page gets tested, and the trainer should keep a note of every question the trainee asked that the page did not answer. Three such questions in one training session are three missing lines, or one missing section, and the page is revised before the next trainee rather than after. The desk at Redbrook found, after training three people, that every one of them had asked what to do with a ticket raised by a technician about their own equipment. A one-line answer went on the page: "Technician's own ticket: treat yourself as the requester; someone else owns it."

Keeping the Page Current

The page has one owner, a version line at the bottom, and a quarterly review tied to the ten-ticket test, and that is the whole maintenance plan. The owner is whoever runs the desk. The version line is a date, a number and one sentence saying what changed. That lets the page carry its own changelog, and nobody has to ask whether the copy on the wall is the current one. The quarterly review is twenty tickets, pulled at random, checked against the page, with the two or three disagreements decided: page or habit, which one changes.

Where the page lives matters as much as what is on it. The first home is wherever the technicians already look. Use an agents-only article in the knowledge base, if the tool has one, because it is searchable from the queue screen and invisible to requesters. Use a pinned document in the team's shared space if it has not. The second home is a printed copy beside each monitor, because a page is faster than a search when a requester is on the phone. The two copies must match, which is what the version line is for. The printed one is reprinted on every change, which on a healthy desk is three or four times a year. Documentation as Your Second Person makes the wider case for this kind of page on a desk with nobody to ask. The workflow page is the first one to write.

Three events trigger a revision outside the quarterly review: a state is retired or added, the window length or a cadence changes, or the tool changes the labels or the roles. Each produces a one-line change, a new version number and a reprint. What does not trigger a revision is a single awkward ticket. One ticket that the page handled badly is a note for the next review, two are a pattern, and three are a new line. A page revised for every exception grows to the twelve pages it replaced, one reasonable addition at a time.

The page also outlives the people who wrote it, which is the point. When the desk lead moves on, the page is the workflow. The new lead reads it on their first day and changes it on their first quarterly review, with a version line saying why. The wiki page that Noor found on day two, describing a status the drop-down did not contain, was somebody's workflow page once. It died because it had no owner, no version line and no review, and the drop-down changed without it. Give the page those three things and it will still be true in three years. Give it none and it will be a historical document by spring.

A Short War Story: The Second Day at Ashgrove Housing

Ashgrove Housing, a housing association with a three-person IT desk, hired Tomasz as a trainee and gave him the tool's manual and a login. On his second week he set forty-one tickets to On Hold to mean "I will get to this". That was what he had seen a colleague do with one ticket on his first day. One of the forty-one was a housing officer's handheld inspection device that would not sync. It sat On Hold for nineteen days with the note "will look at", while the officer, Grace, recorded sixty-three property inspections on paper. A colleague re-keyed every one of them into the system at the end of the month. That was two days of work that the housing director asked about by name. The desk lead, Amara, wrote the workflow page from twenty tickets that Thursday afternoon. Its never list began with "On Hold without a party and a date in the note". Amara trained Tomasz on it the next morning with ten real tickets. He got six right on the Friday and ten right a fortnight later, and the forty-one were sorted into their real states over one afternoon. The lesson Amara put on the version line of the first page was that a trainee who sets statuses wrong has not been given a page, and that the page took three hours to write and the nineteen days did not.

The Workflow Page

The template below is the whole page, with blanks where your desk's numbers, labels and ticket numbers go. Fill it in from twenty real tickets in one afternoon, replace the state names with your tool's spelling, and put real ticket numbers in the examples. Print it, pin it, and put the same text in an agents-only knowledge article. It should fit on one side of a sheet at a readable size. If it does not, something on it belongs on another page, and the section "what stays off the page" above says which.

WORKFLOW PAGE — ________________ DESK
Owner: ______________   Version: ____   Date: ______________   Cards: see "Status definition cards"

STATES  (tool's label: meaning; whose move)
  NEW ............. arrived, nobody has read it or taken it; the desk
  IN PROGRESS ..... a named technician owns the next action; the desk
  AWAITING REPLY .. we asked the requester a question and told them we wait; the requester
  ON HOLD ......... waiting on a supplier, team or date, named in the note with a chase date; outside
  RESOLVED ........ fixed and told, in a reply that names the closing date; the requester
  CLOSED .......... confirmed, or window ended; nobody
  Not used: ______________ (use ______________)   ______________ (use ______________)

MOVES  (from -> to: who / the event / what next)
  NEW -> IN PROGRESS:            anyone who can see it / claims it / first reply within ____
  IN PROGRESS -> AWAITING REPLY: owner / reply asking a question / joins nudge filter
  AWAITING REPLY -> IN PROGRESS: tool, or whoever sees it / requester replied / read same day
  IN PROGRESS -> ON HOLD:        owner / note with party and date, reply to requester / joins chase filter
  ON HOLD -> IN PROGRESS:        owner / thing arrived or date passed / work it, or re-hold with new date
  IN PROGRESS -> RESOLVED:       owner / resolving reply, three sentences / window starts
  RESOLVED -> CLOSED:            owner, or the sweep / confirmed, or window ended / done
  RESOLVED or CLOSED -> IN PROGRESS: requester, by replying / says not fixed / reply same day, flagged
  Any open state -> other department: ______ / belongs elsewhere / arrives NEW there, requester told

NEVER
  NEW -> CLOSED without a reply.      A waiting state -> RESOLVED or CLOSED directly.
  CLOSED -> anything except IN PROGRESS by a requester reply.
  On Hold or Awaiting Reply without a party and a date in the note.
  A status change with no reply when the turn moves to the requester.

WAITING RULES
  Requester: nudge day ____ and day ____, closing warning day ____, resolve day ____.
  Vendor: note carries vendor, reference, promised date; chase ON the date; new promise = new note.
  Hold ceiling ____ days; at the ceiling: resolve, split, or escalate.

WINDOW AND REOPEN
  Window ____ working days from the resolving reply; reminder on day ____.
  Close: [ ] automatic after ____ working days   [ ] sweep every day at ____:____
  Reply to a closed ticket: [ ] reopens it   [ ] new ticket, first line "reopen of #____", linked.
  After ____ days from close: new ticket, linked to the old one.

EXAMPLES  (open them; read the history)
  #______ simple fix:   NEW -> IN PROGRESS -> RESOLVED -> CLOSED (confirmed)
  #______ needed info:  NEW -> IN PROGRESS -> AWAITING REPLY -> IN PROGRESS -> RESOLVED -> CLOSED (silent)
  #______ vendor+reopen: NEW -> IN PROGRESS -> ON HOLD -> IN PROGRESS -> RESOLVED -> IN PROGRESS -> RESOLVED -> CLOSED

WHO MAY   change a status: ______________   transfer a ticket: ______________   run the sweep: ______________
          Trainees: ask your buddy to move the ticket; permission promoted after two clean ten-ticket passes.
CHANGES   Date ______ v____: ______________________________________________________________

Noor, at Redbrook, got the page on the Wednesday, a day late, and read it in the time it took the kettle to boil. The ticket waiting for a part went to On Hold with the supplier, the reference and Thursday in the note, which was the answer. The two colleagues who had said otherwise read the page too and said "fair enough". Ten tickets on Thursday, eight right. Ten more at the end of the month, ten right, and the status-change permission arrived that afternoon. The forty-page manual is still on the shared drive, and it is still a very good description of the buttons.

Frequently Asked Questions