Before Choosing SaaS, Decide Which Differences Deserve to Survive

Imagine a hypothetical enterprise where three teams handle the same kind of request in three different ways. One uses a spreadsheet, another follows an email chain, and the third maintains a shared document. A technology discussion begins, and someone suggests finding one platform for everyone.

That sounds sensible. But it leaves an important question unanswered: are these three versions of the same work, or three genuinely different kinds of work wearing the same label?

My direct answer is this: technology consulting should begin by mapping the workflow and deciding which differences to remove, which to preserve, and which to investigate. Only then does a software shortlist have a clear purpose.

Map the reasons, not just the steps

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 gives me a useful lens: a process question should not automatically become a product requirement.

For workflow mapping, I would start with a specific unit of work—a request, an application, or an internal approval—and follow its movement.

What starts it? What information arrives? Which decisions change its route? Where does it wait? What makes someone send it backwards?

But documenting the sequence is only the beginning. Beside each meaningful branch, I would add a reason.

“Manager approval required” describes a step. “Manager approval required because this request changes an agreed resource allocation” explains why it exists.

That distinction matters. Without the reason, removing a step can look like efficiency even when it removes a necessary decision. Keeping it can look like caution even when its original purpose has disappeared.

Separate necessary variation from inherited habit

Return to the hypothetical three teams. Suppose one handles routine requests, while another handles requests that depend on an external party. Their workflows may reasonably differ.

Now suppose the third team uses an extra approval only because its old spreadsheet made delegation inconvenient. That difference deserves a different discussion.

I would sort workflow variations into three groups:

• Necessary differences: the work has a distinct constraint or requires a different decision.
• Inherited differences: the process reflects an earlier tool, reporting arrangement, or habit.
• Unexplained differences: nobody can yet give a convincing reason for the variation.

The third group is especially important. “We do not know yet” is more useful than quietly turning uncertainty into a permanent requirement.

This is not an argument for making every team identical. Nor is it a defence of every local preference. It is a way to ask for reasons before choosing either uniformity or flexibility.

Evaluate two kinds of change

Once those differences are visible, the SaaS discussion becomes more concrete.

One option may fit a common workflow but require teams to change their routines. Another may accommodate more variation but demand more configuration, documentation, and ongoing administration. These are possibilities to evaluate, not assumptions about any particular product.

I would compare both the change required from the organisation and the complexity introduced into the system.

A close fit to today’s process is not automatically the better choice. It may preserve work the enterprise should stop doing. Equally, a simpler system is not automatically better if it forces genuinely different decisions into one path.

For a product builder, this creates a useful boundary. A customer’s variation may reveal a broader product need. It may also be better addressed through process change rather than another feature.

The consulting task is to make that choice explicit—not to make the software appear capable of absorbing every disagreement.

Give the shortlist a decision brief

Before comparing products, I would want a short checklist completed:

• Map one representative workflow and its meaningful variations.
• Record the reason behind each routing or approval difference.
• Mark differences as necessary, inherited, or unexplained.
• Agree which routines the organisation is willing to change.
• Identify variations any proposed solution must accommodate.
• Compare implementation effort with the ongoing effort of maintaining complexity.
• Keep unresolved process questions visible rather than disguising them as feature requests.

The result need not be a large document. It needs to explain what the enterprise wants to make common and what it has good reason to keep different.

I find that a more honest starting point than asking which platform has the longest feature list. The shortlist can wait until the organisation understands its own variations. Otherwise, we risk buying flexibility to avoid a conversation—or buying simplicity before understanding what it would erase.