Workflow and document management are sold together so consistently that many buyers assume they are one product, and it is worth separating them before you shop. Document management is about the documents themselves: where they are, whose they are, which version is current, when each arrived. Workflow is about the work: what stage a job is at, who has it, what has to happen next. They are related because most work in a practice is triggered by a document arriving or held up by one that has not, but they answer different questions and a product can be good at one and poor at the other. This guide separates them, says what a small practice genuinely needs from each, and describes the configuration trap that catches practices who buy more workflow than they can maintain.
What document management answers
Where is the client's trial balance, which version did they approve, when did it arrive and who sent it. These are questions about objects, and they are answered by metadata, versioning and an audit trail. A practice that cannot answer them is losing time in every busy season and is exposed whenever a client disputes what was sent.
What workflow answers
Which jobs are in progress, which are waiting on the client, which are ready for review and which are done. These are questions about state. A small practice usually needs to see that state, not to automate transitions between states, and the distinction is the whole of the buying decision.
The configuration trap
Workflow engines let you model your process precisely, and modelling your process precisely is a project that never quite finishes. Practices that buy a configurable engine often spend the first year building it and the second maintaining it, while the underlying question, what is waiting on whom, was answerable from a fixed set of statuses on day one. Fixed statuses also make two people's records comparable, which a bespoke model does not.
Questions people ask about workflow and document management
Do we need a workflow engine?
A practice of one to twenty usually does not. What it needs is visible status: what has been requested, what has arrived, what is under review, what is finished. If you find yourself wanting conditional branches and approval chains, check first whether the underlying process is more complicated than it needs to be.
Can document management alone give us workflow?
Partly, and often enough. If the system shows what has been requested and what has arrived per engagement, you can see the bottleneck without a separate workflow product, because in a small practice the bottleneck is almost always a document that has not turned up.
What does Tickmarko do here?
It tracks status and deliberately stops there: engagements move through a fixed set of stages, and documents are outstanding, arrived or reviewed. There are no branches, approval chains or automation rules to configure, which is a limitation and, for this size of practice, mostly the point.