It Depends Is Not an Answer

Ask someone to explain how they do their job, and they’ll give you the version that sounds reasonable. Ask them to write it down step by step, and the cracks show up almost immediately.

That gap is the whole reason “just automate it” is harder than it sounds. You can’t wire software to a process nobody has actually described. You can only wire it to the process someone finally sat down and wrote.

Why can’t you just watch me do it?

We hear this a lot, and it’s a fair question. Watching helps — it catches things people forget to mention. But watching one person do a task twenty times shows you their habits, not the rules underneath them.

An app needs the rules. It needs to know what to do the one time the invoice is missing a PO number, not just what happens on the nineteen times it isn’t. Watching shows you the pattern. Writing it down forces you to name the exception.

The process in your head is not the process on paper

Most business processes live as instinct. Someone glances at a request, feels whether it’s urgent, and acts. Ask them why, and they’ll say “you just get a sense for it” — true, and useless to a computer.

Writing the process down means translating that sense into something checkable: is the amount over a certain size, is the client on a list, did the request come in after hours. The instinct was never magic. It was five or six quiet rules running at once, and your job is to pull them apart.

Every “it depends” is a missing rule, not a dead end

People treat “it depends” as the end of the conversation. It’s actually the most useful sentence in the room, because it means there’s a decision point nobody has named yet.

Chase it one more level. It depends on what? The answer is usually short — the client’s size, the day of the week, whether a manager already looked at it. Write down what it depends on, and “it depends” turns into a rule an app can follow every time, not just when the right person happens to be watching.

The exceptions are the process

The happy path is the easy part to describe and the least valuable to automate — it was never costing anyone real time. The exceptions are where the hours go: the weird vendor, the customer who always calls instead of emailing, the order that shows up with two conflicting addresses.

A good process write-up spends most of its length on what happens when things go sideways, because that’s what the team is actually doing all day. If your document is all happy path, you’ve documented the part that didn’t need help.

Show us ten examples, not one description

Descriptions drift toward how a process is supposed to work. Examples show how it actually works, warts included. Before you try to summarize the task, pull ten real instances of it — ten emails, ten orders, ten tickets — and lay them side by side.

Patterns jump out that no one would have thought to mention on their own. A short checklist beats a paragraph of prose here, because it forces you to separate the input from the decision from the output instead of burying them in a story:

• What came in — the exact input, not a summary of it
• What someone checked or decided before acting
• What went out, and where it went

Do that ten times and the real rules surface on their own. You stop guessing at the process and start reading it straight off the examples.

This is the part we actually do with you

Most teams don’t need a consultant to hand them a template and walk away. They need someone across the table, asking the annoying follow-up questions, pushing until “it depends” turns into an actual rule.

That’s the first real week of any build at Command Module. We build custom AI apps wired into a business’s real data and workflow, while your people keep making the calls that matter. We’d rather spend that week getting the process right than spend the next one rebuilding an app that automated the wrong version of it.

FAQ

How detailed does my process documentation need to be before you can automate it?

Detailed enough that someone who has never done the job could follow it without calling you. If a step assumes judgment nobody has defined yet, that’s the part we need to dig into together before any code gets written.

What if my process changes depending on who’s doing it?

That’s normal, and it’s useful information rather than a problem. It usually means there are two or three valid versions of the process, and we write down each one as its own path instead of pretending there’s a single right way.

Do I need to write all of this out myself, or can you help me capture it?

You don’t need a finished document to start. Most of what we need comes out of watching real examples and asking questions as we go — you bring the knowledge, we do the writing down.