Follow the actual workflow
Not the documented one. We watch how the work really moves, including the workarounds people stopped mentioning.
guest@make-directory:~$ cat ./solutions/automate-simplify.md
make-directory:~/solutions/automate-simplify
Stop paying people to move data between systems.
Repetitive work and operational friction removed. Spreadsheets, re-keyed data, email approvals, and reports that someone rebuilds by hand every month, replaced with systems that do it themselves.
guest@make-directory:~$ cat ./sound-familiar.md
the situation
Work moves by hand. Someone exports a file, reformats it, and uploads it somewhere else. An approval lives in an email thread. A report gets rebuilt every month from the same four sources. Everyone knows it is wasteful, and everyone is too busy doing it to stop.
A spreadsheet has quietly become a system of record
The same data is typed into more than one system
Reports are assembled by hand on a schedule
Approvals and handoffs happen in email, with no record of state
Onboarding a new person means teaching them a manual workaround
Nobody can answer an operational question without building a spreadsheet first
guest@make-directory:~$ cat ./what-changes.md
the outcome
Less manual work, fewer errors, and visibility into what is actually happening.
- The repetitive steps run without anyone remembering to do them
- Data arrives where it is needed instead of being carried there
- Handoffs have a state you can look up rather than an inbox to search
- Reporting is a view, not a monthly rebuild
- The people doing the work get their hours back
guest@make-directory:~$ cat ./how-we-approach-it.md
how we approach it
What the work actually looks like.
Find the expensive steps
Volume times effort times error rate. Some manual steps are not worth automating, and we will say which.
Automate the boring parts
Integrations, scheduled jobs, and validation — with the judgment calls left to people, where they belong.
Make it observable
An automation nobody can see is a liability. You get visibility into what ran, what failed, and what needs attention.
guest@make-directory:~$ ls ./what-it-might-be
what this could become
What it turns out to be depends on what we find.
Here is what this work has become for other people, so you can get a feel for the range. Which one fits your situation is something we work out together, once we understand it.
- Integrations between systems that were bought separately
- A small internal tool replacing a shared spreadsheet
- Scheduled jobs that produce the report nobody wants to build
- A dashboard, when the problem is actually visibility
- AI where it genuinely removes effort — document handling, classification, extraction
- Sometimes: a change to the process, and no software at all
guest@make-directory:~$ cat ./where-this-goes.md
where it usually goes
Usually Growth or Partner.
Automation work is rarely one-and-done. The second workflow is always easier than the first, and there is always a second — so most of these settle into Growth.
guest@make-directory:~$ ls ./related-reading
related reading
How we think about this.
Small Business Automation: Where to Start Without Overcomplicating It
A grounded guide to finding the first useful automation opportunities in a small business without turning the project into a science experiment.
When a Spreadsheet Should Become a DashboardHow to tell when a business spreadsheet has outgrown itself and should become a dashboard, internal tool, or automated reporting workflow.
Before You Build an Internal Tool, Map the Workflow FirstInternal tools work best when they are designed around the real workflow, not just the screens a team thinks it needs.
guest@make-directory:~$ cat ./faq.md
questions
Frequently asked questions
Will this replace people?
In our experience it replaces the part of the job people like least, and the headcount stays. The usual result is that the same team handles more volume without the error rate climbing.
We already pay for tools that should do this.
Often true — and often they cannot talk to each other, which is why the spreadsheet in the middle exists. Connecting what you already own is usually cheaper than buying another system.
Do we need AI for this?
Frequently not. Most manual work is repetitive rather than judgment-heavy, and deterministic automation is cheaper to run and easier to trust. We use AI where the task genuinely needs it — reading unstructured documents, classification, extraction.
What if the process changes?
Then the automation has to change too, which is why we build them to be readable and document what they assume. An automation nobody can modify becomes the next inherited system.
guest@make-directory:~$ mkdir ./what-needs-to-change
next step
Tell us what is not working.
A few sentences about your situation is plenty to start with. We will come back with what we think it takes, and say so if we are the wrong people for it.
Not sure this is the right one?
These four overlap, and most real situations are a mix of them. An assessment sorts out which parts matter and in what order, and you keep the write-up either way.
Start an Assessment