One of the questions I get asked early in almost every engagement is some version of: what can we automate? It is a reasonable thing to want to know. Automation reduces effort. Reduced effort is appealing.
The reframe I almost always need to make is this: the question is not what can we automate. The question is what should this step actually be. Some steps should be automated. Some should be redesigned. Some should be handled by a different tool. And some (and this is the part people do not expect) should be protected as intentionally manual.
What intentionally manual means
Intentionally manual is not the same as accidentally manual. Accidentally manual is a step that requires human intervention because nobody got around to automating it yet. Intentionally manual is a step that requires human intervention because the judgment involved cannot be encoded without losing something important.
The most obvious category is relationship touchpoints. A founder who sends a personal check-in to every client at the midpoint of a project is doing something that appears automatable (it is a recurring task with a predictable trigger), but the value of the check-in is precisely that it is personal. An automated version that sends itself is not a relationship gesture. It is a notification.
Automating it does not save effort in any meaningful sense. It removes the thing the step was designed to do.
The categories worth protecting
- Judgment calls that are genuinely contextual, decisions that depend on reading a situation that changes with each instance. If the right answer varies significantly based on who the client is, what the project context is, or what the relationship dynamic is, the decision belongs to the founder.
- Relationship touchpoints where the human quality is the point, check-ins, thank-yous, acknowledgments, moments of care that a client would recognize immediately as automated if they were automated.
- Exception handling that requires discretion, the edge cases, the situations that fall outside the standard process, the moments where doing the right thing requires understanding something a rule cannot capture.
- Creative work that benefits from unstructured attention, the thinking, the synthesis, the decisions that come from sitting with a problem rather than executing a process.
“Not everything that can be automated should be. The question is what each step is actually for.”
Why this matters for how systems get built
When a system is built without this distinction, it tends to over-automate (removing human judgment from steps that benefit from it), and under-structure in other areas, leaving manual effort in places where a system could handle it without loss of quality.
The Business Systems Diagnosis is designed to make this distinction. For each relevant area, it asks: should this be kept, connected, replaced, protected, simplified, automated, or built? Protected and kept are real categories, not placeholders for work that was too difficult to address.
Custom does not mean maximum automation. It means the right structure for the work, which is a different and more interesting question.