A Workflow Map Should Show Who Carries the Cost

Imagine a hypothetical enterprise team evaluating two SaaS products. Both demonstrations look convincing. Both appear to cover the broad requirements. Then someone asks a less comfortable question: when a request arrives incomplete, whose responsibility is it to make it usable?

The room may have several answers. The software shortlist has none.

My direct answer is this: technology consulting should begin by mapping how work moves, where responsibility changes hands, and who bears the cost of each trade-off. Only then does a product comparison have a meaningful basis.

Map the work people inherit

As Founder & Growth Head at Vahmine Technologies Pvt Ltd, my work spans enterprise technology, SaaS product building, and consulting. Vahmine delivers enterprise automation services and runs Toolyt, Dale and Acadle. That combination makes me wary of treating product selection as the whole consulting assignment.

A product can be evaluated against a list of requirements. A workflow needs to be understood as a chain of obligations.

For each step, I want the map to show the trigger, the person responsible, the information required, the output, and the condition that allows work to move forward. I also want it to show what happens when that condition is not met.

“Send for approval” is not enough. Who checks whether the submission is ready? Can the approver return it? Who explains the correction? Does the original requester know that the work has stopped?

These are not details to fill in after procurement. They define what the organisation is asking software to support.

Follow one request through competing realities

Consider a hypothetical purchasing workflow. An employee submits a request, a manager approves it, and a purchasing team takes it forward.

On a diagram, that is three boxes.

Now add the work between them. The employee may not know which information purchasing needs. The manager may approve the business purpose without checking completeness. Purchasing may then have to chase missing details from someone who believes their part is finished.

Each participant can reasonably describe a different workflow. The employee sees submission. The manager sees authorisation. Purchasing sees preparation, clarification, and eventual execution.

I would map these perspectives separately before combining them. Otherwise, the cleanest account can become the official account, while the effort that keeps everything moving disappears.

The aim is not to identify a guilty department. It is to distinguish necessary work from work created by unclear handoffs. A good map makes those differences discussable without turning them into personal criticism.

Compare where the burden goes

Once the current workflow is visible, the next task is not simply to reproduce it digitally. It is to compare possible arrangements.

In our hypothetical example, requiring more information at submission could reduce later clarification. It could also make occasional requesters struggle with fields they do not understand. A specialist review step could help them, but would introduce another queue and another responsibility.

Neither arrangement is automatically better.

I would evaluate the alternatives across requester effort, reviewer workload, waiting time, visibility, maintenance, and the ability to correct mistakes. These criteria can conflict. The consulting task is to make the conflict explicit, not hide it behind a single score.

This is where the SaaS shortlist becomes useful. Ask vendors to demonstrate the same representative workflow, including an incomplete submission and a returned request. Separate what is demonstrated from what remains an assumption.

Then examine the implementation burden. A configuration that fits closely may require ongoing ownership. Changing the workflow to suit a product may be simpler technically but harder organisationally. Connecting existing systems may preserve familiar tools while adding dependencies to maintain.

I want the recommendation to say not only what improves, but also who takes on additional work and why that exchange is acceptable.

Make the recommendation accountable

Before recommending a product or an implementation approach, I would use this checklist:

• Trace one representative request from its trigger to a clearly defined outcome.
• Record the owner, required information, and completion condition at every handoff.
• Include at least one incomplete, rejected, or returned request.
• Ask each participating role to correct the map.
• Compare alternative workflows, not just alternative products.
• State whose effort increases and whose effort decreases.
• Identify who will maintain the workflow after implementation.
• Mark untested assumptions and agree how to verify them.

The map does not need to become an elaborate document. It needs to be accurate enough to challenge an attractive demonstration and practical enough to guide implementation.

What matters to me is the honesty of the final recommendation. Software rarely makes every participant’s work easier in exactly the same way. Some effort is removed; some is relocated; some becomes more visible.

Starting with the workflow gives us a chance to make those choices deliberately. I would rather recommend a system with understood compromises than an impressive shortlist whose consequences only become clear after people must live with it.