Process Documentation Software: When the Tool Is Not the Missing Piece.
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.
Missing piece one: a decision about what is worth documenting.
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.
Missing piece two: an owner per process, with the authority to say how it works.
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.
Missing piece three: a reason the document has to be right.
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.
When the software actually helps.
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.
A test to run before buying.
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.
What the alternative looks like.
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.
Why it matters now.
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.
Know whether your data and processes are ready for AI before you pay for it.
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:
Comments