Every quarter, in most mid-market companies, someone proposes buying process documentation software. The pitch is reasonable: the processes are undocumented, the documentation that exists is in six formats across four drives, a proper tool would give it one home, version control, ownership and a search box. The tool is bought. Six months later the documentation is still unwritten, now in a nicer place.
We see this often enough to say it plainly: the tool is almost never the missing piece. Three other things are, none of them is for sale, and a company that supplies them can document its processes in a shared document folder. This post is about the three, about the narrow case where software genuinely helps, and about how to tell which case you are in before the purchase order goes out.
The reason documentation efforts stall is not that writing is hard. It is that "document our processes" has no edge. Hundreds of routines, no order, no stopping rule, and the people asked to do it correctly conclude that the job is infinite and do something else.
The decision that fixes this is a short list: the six to ten processes that carry money or stock, ordered by how much pain they cause, and a depth rule, the decision, not the click. With that list, documentation is a bounded project of weeks. Without it, no tool makes it finite, and most tools make it feel more infinite by offering a template for everything. We have written about documenting for automation, and the first step there is the same: choose.
A process document is a statement of how the company has decided something is done. Somebody has to have the authority to make that statement, and in most mid-market companies nobody does. The order-to-invoice process spans sales, operations and finance; each owns a piece; none owns the whole; and the document, if it gets written, is three departments' descriptions of their own part with the handoffs left blank, because the handoffs are the part nobody is allowed to decide.
Software does not confer authority. A named owner does: one person per process, accountable for the document being true and able to settle the handoffs. Where the company has no one senior enough to hold that across departments, it is the seat a fractional technology executive fills, and it is why we treat documentation as an accountability problem before a writing one.
Documentation that nothing depends on decays. It is written for an audit or an onboarding, read once, and wrong within a quarter, because there is no consequence to its being wrong. Tools try to solve this with review reminders, which are ignored for the same reason.
The thing that keeps a document true is a system that runs from it. A blueprint in the CRM that enforces the stages and the exceptions; an automation that encodes the rules; an AI agent that reads the exception table to know which decisions are its own. When the document is the specification for something running, a wrong document produces a wrong outcome that somebody notices, and the document gets fixed. This is the argument for writing the exceptions rather than the happy path: the exceptions are what the running system needs, and the running system is what keeps the document honest.
There is a real case, and it is narrower than the market suggests.
A company with the three pieces in place, a list, owners and systems that run from the documents, and with more than a couple of dozen documented processes, does eventually outgrow a folder. Versioning by file name breaks; nobody can tell which document is current; the link between a process and the system that implements it is in someone's head. At that point a tool that holds the documents, versions them, assigns owners and links each process to the workflow or blueprint that runs it earns its licence. The tell is that the documents exist, are used, and are becoming hard to manage. That is a good problem, and it is the one the software solves.
If the documents do not exist, the software is a nicer empty folder. If they exist but nothing runs from them, the software is a nicer archive. In both cases the money is better spent on the missing piece.
Answer three questions in writing.
Which six to ten processes would be documented first, in what order, and to what depth? If the answer is "all of them," piece one is missing.
Who owns each, with the authority to settle the handoffs between departments? If the answer names a department rather than a person, or names nobody, piece two is missing.
What system runs from each document, so that a wrong document produces a visible wrong outcome? If the answer is "the document is for reference," piece three is missing.
If all three are answered, buy the tool if the volume justifies it. If any is not, the tool will not fix it, and the fix is cheaper than the licence.
For most operators under a few hundred people, the working setup is unglamorous. A shared folder with one document per process, two pages each, dated and owned. The processes chosen by money and pain. Each document the specification for a blueprint, a workflow or an automation in the systems the company already runs, so that the document and the system are checked against each other every time either changes. When the internal tools that grew around spreadsheets are replaced with something built, the process document is the brief.
That setup produces documentation that is read, because it is the thing the system was built from, and stays true, because the system breaks visibly when it is not. It costs weeks of the process owners' time and no licence.
An AI initiative cannot run on documentation that does not exist, and cannot run safely on documentation that is wrong, and the way to have documentation that exists and is right is the three pieces, not a tool. We start every AI readiness review with the same three questions, and the answers decide the first month of work. Discovery is paid for only if you proceed; the build that follows carries a guaranteed estimate, and if we estimate low, we absorb the difference. Occasionally the answer at the end is that the company has the three pieces and should buy the software. More often it is that the software was standing in for a decision, and the decision is where the review starts.
The AI Readiness Review is a 90-minute working session plus a written scorecard across data hygiene, documented process, permissions and ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Business Process Mapping Before You Buy Anything: The Map That Decides the Software. (article)
You Can't Automate a Process Nobody Has Written Down (article)
Nobody Wrote The Process Down (video)
Because the tool was never the missing piece. Three things usually are: a decision about which processes are worth documenting and to what depth, a named owner per process with the authority to settle the handoffs between departments, and a system that runs from the document so a wrong document produces a visible wrong outcome. A company without those three ends up with the same unwritten processes in a nicer place six months later.
The six to ten that carry money or stock, ordered by how much pain they cause: order to invoice, purchase to payment, hiring, onboarding a customer, month-end. Document the decisions and the exceptions rather than every click. A bounded list turns documentation into a project of weeks. The instruction to document all processes has no edge, and people asked to do an infinite job correctly conclude it is impossible and do something else.
One person, named, with the authority to say how the process works across every department it touches. A process such as order to invoice spans sales, operations and finance, and if each owns only its part, the handoffs stay blank because nobody is allowed to decide them. Software does not confer that authority. Where no one senior enough exists to hold it across departments, that is the seat a fractional technology executive fills.
Make something depend on it. Documentation written for an audit or onboarding is read once and wrong within a quarter, because nothing breaks when it is wrong, and review reminders are ignored for the same reason. A CRM blueprint that enforces the stages, an automation that encodes the rules, or an AI agent that reads the exception table keeps the document honest, because a wrong document then produces a wrong outcome someone notices and fixes.
When the documents already exist, are used, and are becoming hard to manage: more than a couple of dozen documented processes, versioning by file name breaking down, nobody sure which version is current, and the link between a process and the system that runs it living in someone's head. A tool that versions documents, assigns owners and links each process to its workflow earns its licence then. Before that point, a shared folder with one two-page document per process works.
Yes. An AI initiative cannot run on documentation that does not exist and cannot run safely on documentation that is wrong, because the agent needs to know which decisions are its own and which exceptions go to a person. The three questions, which processes, who owns each, and what runs from each document, are the starting point of an AI readiness review, and the answers decide the first month of work.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
