This article is a draft awaiting approval. The text may still change, and search engines are asked not to index it yet.
Digitising an approval process only helps when the organisation has first agreed who owns each step, what a complete request looks like and what happens when someone does not act. Software makes those decisions visible and repeatable. It cannot make them for you.
The short answer
When a company moves its internal requests from paper, email and spreadsheets onto a workflow platform, the hard part is rarely the software. The hard part is agreeing who owns each step, what information a request needs before it can move, and what happens when a request stalls. If those questions are not settled, the new system reproduces the old confusion, only faster.
Why it matters
Most organisations have dozens of internal processes that grew up informally: purchase requests, leave approvals, document sign-offs, equipment requests. They live in printed forms, email threads and Excel files. The symptoms are familiar. Requests wait on someone’s desk, nobody can say where a request is, and two departments approve the same thing in different ways.
It is tempting to treat this as a tooling gap. Buy or build a BPM platform, draw the flows, and the delays will disappear. In my experience the tooling is necessary, but it is the second step.
The argument
A workflow encodes decisions. Every box in a process diagram stands for a decision someone has to make: who approves, in what order, based on which fields, and with what deadline. On paper these decisions can stay vague, because people work around them. A clerk knows which manager to call. An email gets forwarded to whoever seems right.
A digital workflow removes that flexibility. It needs a named role for every step, a rule for every branch and a defined path for exceptions. That is exactly why it helps: it makes the process traceable and consistent. But it also means that every unresolved management question surfaces as a blocked request or a design argument.
So the first deliverable of a workflow project is not a screen. It is an agreed description of the process: the owner, the steps, the rules and the escalation path. The software then makes that agreement repeatable.
What this looks like in practice
On the business process management platform I worked on with a team during my employment, the goal was to replace paper, email and Excel-based requests with digital forms, approval flows and task tracking on web and mobile.
Work like this tends to surface three patterns:
- Parameters instead of one-off builds. Designing the platform so that a process could be configured, rather than coded each time, only works once departments agree on shared building blocks such as roles, approval levels and request types.
- Forms expose missing rules. Turning a paper form into a digital one quickly shows which fields nobody ever checks and which approvals depend on one person’s judgement.
- Traceability changes the conversation. Once every request has a visible status, discussions move from “where is it?” to “why does this step exist?”, which is a management question.
Qualifications
This is not an argument against software. Without a platform, even well-designed processes stay hard to track and easy to bypass. Nor is it an argument for long analysis before anything is built. Small, real workflows are often the fastest way to discover where the decisions are missing.
The point is about order and ownership. Treat process ownership as part of the scope, not as background.
Related
- Case study: Business Process Management Platform
- Service: Business process automation
