Writing · Operations
I sell automation work, so read this as a statement against interest: automation is the right answer less often than it is sold. Every diagnostic I run produces a register with three columns, and the automate column is rarely the longest.
An automation vendor produces a list of things to automate. An honest operating read produces a register: what to automate, what to eliminate entirely, and what to leave alone. The difference between those two documents is usually six figures.
Elimination beats automation whenever it applies. An automated version of a pointless process is a pointless process with a maintenance bill. The first question is never "can a system do this?" It is "why does this exist?"
If two people run the same process differently and neither can say which version is correct, automation freezes the confusion into software. Clarify first. The clarification is often the whole fix.
ClarityA system without an owner degrades from the day it ships. If no one inside the company will own the automated process, the automation is a liability being installed, not a capability.
OwnershipA task done twice a month does not repay a build, no matter how annoying it feels. Effort estimates belong next to every register line. Feelings about tedium are not a business case.
EconomicsIf the company's real problem is an unclear offer or a broken sales motion, operational automation is expensive procrastination. Faster execution of the wrong plan is not progress.
ConstraintSome steps look like process but are actually judgment: the partner's read of a case, the underwriter's exception. Automate the paperwork around them, never the judgment itself.
BoundaryMost companies do not have an AI problem. They have an unclear process, an unclear owner, an unclear offer, or a delivery model that breaks under pressure. AI helps only after the real constraint is named. That naming is diagnostic work, not procurement work, and it is why the two-week operating diagnostic precedes every build I take on.
Sometimes the finding is "do not spend on this at all." I deliver that finding anyway. It costs the client a diagnostic fee and saves them a failed project, which is the correct trade even though it costs me a build. What the opposite decision looks like when it goes right is documented in the case studies, including a law firm result in AI automation for law firms. The reasoning behind why so many builds start wrong is in why AI projects fail before the first workflow is mapped.
Describe the process you are thinking of automating. A free 30-minute conversation is usually enough to tell whether it belongs in build, kill, or ignore.
Book the conversation →