Here's something you won't often hear from someone who sells systems work: in the early days of a business, a bit of chaos is the right call.
When a business is young, the one job that matters is working out how it makes money. Which customers pay, what they pay for, and what it takes to deliver. That knowledge changes week to week. If you lock your processes down too early, with detailed SOPs, rigid policies and a carefully configured tool for every step, you pour concrete around a shape you haven't finished discovering. Then you spend the next year working around it.
So be scrappy. Do things by hand. Change your mind. It's cheaper than getting it wrong in writing.
The bill comes later
The trouble is that scrappy has a long-term cost, and it arrives quietly.
It shows up as the process that only one person really understands. The question every new starter asks, because the answer isn't written down anywhere. The two staff members who handle the same situation in two different ways, both of which are "how we do it here." The customer who gets a great experience on Tuesday and a confused one on Thursday.
None of that is a crisis on its own. Added up, it's a business that can't grow without adding people at the same rate as the work, because the work lives in people's heads and not in the way the business runs.
You can't automate what doesn't exist
This is where it matters most for anyone thinking about automation or AI.
Automation needs a real, working workflow to automate. Not "roughly how we usually do it," but a defined sequence: what triggers it, who does what, where the information comes from, what "done" looks like, and what happens when something goes wrong.
If that workflow doesn't exist yet, automating it doesn't create one. You get a machine faithfully running a process nobody has agreed on. I wrote about the invoicing version of this in Why automation makes a broken process worse. The pattern is the same whatever the process.
So the first job is getting sorted: working out the actual workflow, writing it down, and agreeing on it. SOPs, policies and best practices aren't bureaucracy for its own sake. They're the specification any future automation gets built from.
Design first, then automate
That's why it's normal for a consultant to design the workflow before building anything, and why you should be a little wary of anyone who quotes you an automation before they've mapped how the work actually happens.
I'm living this one right now. This week I presented a Workflow Health Check report to a client whose business has grown from ad hoc to half a dozen software platforms, and whose staff are carrying the gaps between those platforms by hand. (I wrote about where they sit in Integrate or consolidate? The IT crossroads.) The recommendation isn't "let's automate everything." It's two phases:
- Design. Map the workflows as they really run, fix the handoffs, decide which system owns which information, and document the result so it holds up without any one person in the room.
- Automate. Build automation on top of the workflow they now actually have, where it will save hours instead of multiplying mistakes.
Phase one is less exciting to pitch. It's also the part that decides whether phase two pays off.
Knowing when to switch
There's no fixed point where scrappy should end, but the signals are fairly consistent:
- You're hiring, and training someone takes weeks because nothing is written down.
- The same mistake keeps happening, and the fix is always "be more careful."
- You're opening a second site, a second service line, or a second anything, and the first one runs on one person's memory.
- You've started thinking "we should automate this."
That last one is the clearest. Wanting to automate something is a sign the process is repetitive enough to be worth it. Make sure it's also defined enough to be possible.
If you're not sure which side of that line you're on, a Systems Health Check will tell you, and it starts with the design, not the tools.