Process First, Tool Second: Documenting a Workflow Before You Build It

You’ve had the demo. The new platform looked clean, the salesperson was charming, and someone in leadership said “great, let’s just move the onboarding sheet into that.” Three months later, the new tool has a column called “Notes (old)”, two status fields that disagree with each other, and a side spreadsheet that people use “just for now.”

That’s what happens when you migrate a spreadsheet instead of a process. The tool is new. The confusion is vintage.

The spreadsheet is not the process

A spreadsheet is a record of what people did, not a description of what they’re supposed to do. The real process lives in people’s heads, in a few email threads, and in habits like “Priya always checks the contract before marking it green.”

If you copy the columns into a new tool, you copy the symptoms. You get the same 34 fields, half of which nobody fills in, and none of the rules that made the sheet sort of work. The tool can’t enforce a rule nobody wrote down.

So before you evaluate anything, write the process down. Not a 40-page procedure manual. One or two pages that a new hire could follow and a tool could be configured from.

The five things you need to capture

Every workflow, from purchase requests to client onboarding, comes down to the same handful of questions.

1. Trigger. What starts this? A signed contract, a form submission, the first business day of the month, a customer email. If you can’t name the trigger, you can’t automate the start.
2. Steps. What happens, in order? Keep each step to one verb and one object: “check credit limit”, “create account”, “send welcome pack.”
3. Owners. Who does each step? Use roles, not names. “Finance analyst”, not “Dave.” Dave will go on holiday, and then you’ll find out how much of the process was actually Dave.
4. Handoffs. Where does work pass from one person or team to another? This is where things get lost, so mark every one.
5. Done. What does finished look like, and who decides? “Account is live and the client has logged in once” is a definition. “Sorted” is not.

A worked example: client onboarding at a small agency

Say a 20-person marketing agency tracks new clients in a shared sheet. It has 28 columns and a colour-coding system known only to the operations manager. Here’s what the process looks like once it’s written down.

Done: kickoff held and first deliverable scoped with a due date.

Writing this down took about an hour, and it surfaced three things the sheet had been hiding. Step 2 regularly stalled because nobody told finance the contract was signed; they found out by noticing a new row. Step 3 had no owner at all when the ops coordinator was out. And 9 of the 28 columns weren’t used by any step.

That’s the value. Not the table itself, but the arguments it starts.

Capture the exceptions, but don’t let them run the show

Every process has edge cases. The client who pays upfront. The rush job that skips kickoff. The account that’s actually a subsidiary of an existing client.

List them, but separately. For each one, note how often it happens and what changes. If an exception happens twice a year, it probably doesn’t need its own branch in the tool; a human handling it with a note is fine. If it happens weekly, it’s not an exception, it’s a second path, and it deserves its own steps.

A good rule of thumb: design for the path that covers most of the work, then add branches only for exceptions that are frequent or expensive to get wrong.

How to actually gather this

You won’t get an accurate process by writing it alone at your desk. You’ll get the process as you imagine it, which is usually tidier than reality.

• Walk through a real recent case. Pick a client from last month and trace what actually happened, step by step, with the people involved. Real cases expose the workarounds.
• Ask “what do you do when…?” People describe the happy path by default. The interesting parts come out when you ask about the delays, the missing information and the angry emails.
• Look at the sheet’s history. Columns added recently often mark a step someone bolted on after something went wrong. Ask why it’s there.
• Time-box it. Two or three 45-minute sessions is plenty for most workflows. You’re after a usable draft, not a dissertation.

If you’ve already done an inventory, as described in “Who Owns This Sheet? Mapping the Shadow Processes in Your Company”, start with the sheets that scored highest on risk.

What the document gives you later

A written process is the brief for everything that follows. When you think about structure, as covered in “From Rows to Records: How to Think About Your Data Like an Application”, the steps tell you which fields matter. When you weigh options in “Buy, Configure, or Build? A Decision Framework for Internal Tooling”, the handoffs and exceptions tell you how much flexibility you need.

It also gives you a test. When a vendor shows you their platform, hand them your five steps and ask them to show you each one. Ten minutes of that tells you more than an hour of their standard demo.

And it gives you a baseline. If you noted that step 2 typically waits two days, you’ll know whether the new tool actually helped.

Where to start this week

• Pick one workflow that currently lives in a spreadsheet and causes regular friction.
• Book a 45-minute session with the two or three people who touch it most, and trace one real case from last month.
• Fill in the five-column table: step, owner, handoff, typical wait, and a one-line definition of done.
• Mark every column in the existing sheet that no step uses. Those are your first candidates to leave behind.