A polished software demonstration can make a complex process look simple. The important question is not whether a SaaS product can handle the standard path. It is whether it can handle the rules, exceptions, terminology and accountability that make your day-to-day operation work.
This guide helps UK SMEs assess packaged SaaS fit for a complex operational process without turning the exercise into a vendor feature checklist. It is useful for workflows such as job tracking, quotations, production planning, inspections, approvals, maintenance and recurring reporting.
The aim is to decide whether a packaged product can support the process with acceptable changes, or whether the workflow needs a more tailored managed application.
Start with the operating process, not the product
A spreadsheet, email chain or shared register may show only part of the process. The real workflow often includes decisions made in conversations, checks performed outside the file, and exceptions handled from experience.
Before reviewing SaaS products, write a short description of:
- what starts the process
- what counts as complete
- the roles involved
- the records, documents and outputs produced
- the decisions that affect price, status, approval or compliance
- the situations that interrupt the usual flow
Keep this deliberately practical. You do not need a full software specification to assess SaaS fit. You need enough detail to distinguish a genuinely standard process from one that only appears standard until a difficult case arrives.
For a deeper exercise in documenting an Excel-led workflow, see how to map an Excel process before replacing it.
Assess SaaS fit across six areas
Use the following areas to guide product conversations and internal discussion. They are not a universal scoring system. A single issue, such as an approval rule that cannot be enforced or a required audit trail that cannot be produced, may matter more than several minor matches.
| Area | Questions to ask | Signs of stronger SaaS fit | Signs of a possible fit gap |
|---|---|---|---|
| Standard flow | Does most work follow a repeatable sequence? | The usual stages, statuses and outputs match the product's normal workflow. | Staff would need to bypass core stages or maintain a parallel tracker. |
| Exceptions | What happens when work arrives late, changes, fails or needs escalation? | Exceptions are limited, understood and can follow a clear route. | Important cases depend on unwritten judgment, repeated overrides or side conversations. |
| Business rules | How are prices, eligibility, dates, allocations or approvals determined? | Rules can be configured, tested and governed without distorting the process. | The product needs manual calculations, free-text workarounds or repeated custom intervention. |
| Terminology and records | Does the product reflect the records your team actually uses? | Fields, statuses and documents can represent meaningful operational information. | Teams must translate vital terms into vague generic fields or duplicate records elsewhere. |
| Permissions and accountability | Who can view, change, approve or reopen work? | Roles, approvals and audit evidence match the required accountability. | Controls are too broad, too rigid or cannot show who made a decision. |
| Change handling | How often do rules, services or responsibilities change? | Changes can be made through an understood process without disrupting operations. | Frequent changes would require ongoing workarounds or create a growing set of exceptions. |
A process can be run by one person and still need stronger controls if it affects customer commitments, financial decisions, regulated work or a critical handoff. Equally, a large multi-user process may fit packaged SaaS well when its rules and exceptions are genuinely standard. User numbers and workbook size are context, not a decision rule.
Test the exceptions before trusting the normal path
Most products can demonstrate a clean transaction from start to finish. Ask to see what happens when the process becomes less tidy.
Build a small list of real situations from recent work. Use incidents that changed a price, delayed a job, required a manager's decision, caused rework or led to a customer question. The list should reflect your process rather than a generic software test script.
Useful cases might include:
- a quote requiring an unusual discount or revised delivery condition
- a job reopened after work has started
- a missing product, supplier or customer reference
- an approver who is unavailable
- a partial delivery or changed order quantity
- a record entered with incomplete information
- a late import or correction that affects a report
- a manual override that needs a reason and an audit trail
For each case, ask the provider or implementation team to show:
- what the user sees;
- whether the system blocks, routes or records the exception;
- who can authorise the next step;
- what changes in related records, documents and reports; and
- what evidence remains afterwards.
A free-text note can explain why something happened, but it does not necessarily enforce a decision, recalculate a value or prevent the next step. Where an exception affects money, status, access or compliance, look for a controlled route rather than an informal note.
Check whether rules can be represented without distortion
Packaged SaaS is often a strong option when the process can reasonably follow the product's operating model. The difficulty begins when the product can only fit by changing business rules that exist for a real reason.
Separate each apparent requirement into one of three categories:
- Essential rule: a rule needed for legal, financial, contractual or operational control.
- Useful local practice: a preference that may be simplified without harm.
- Historical workaround: a step created because the existing spreadsheet or system was limited.
This distinction prevents two common mistakes. The first is demanding that a new product reproduce every spreadsheet tab and workaround. The second is accepting a standard workflow that removes a control the business genuinely needs.
Ask specifically how the SaaS product handles rule changes. For example, if approval levels, product codes, service types or pricing conditions change, who can make the change, how is it reviewed, and can you see when it took effect? A process that changes regularly may still suit SaaS, but it needs a workable way to manage those changes.
Test language, permissions and ownership
Operational fit is not only about screens and automation. It also depends on whether people can understand the records and work within appropriate boundaries.
Terminology and records
Ask whether the product can represent the terms your team relies on. This does not mean every internal label must be copied exactly. It means users should be able to distinguish the records, statuses and decisions that matter to the process.
If a critical job status, inspection outcome or commercial condition must be kept in a generic notes field, reporting and accountability may quickly become weak.
Permissions and approvals
Use realistic role scenarios rather than relying on a permissions slide in a demonstration. Check whether people can:
- see only the information relevant to their role where needed;
- enter and amend the records they are responsible for;
- approve or reject only the decisions they are authorised to make;
- identify who changed a record and when; and
- access documents, exports and notifications consistently with those permissions.
The goal is not maximum restriction. It is clear accountability without creating unnecessary delays.
Data and change ownership
Clarify what can be exported, what data remains available at exit, and whether the records include the history needed to understand them. Also establish who owns field definitions, reference data and workflow configuration in everyday use.
A product may be suitable even where some configuration is provider-managed. The key question is whether your business can operate and change the process without becoming dependent on undocumented workarounds or unclear responsibilities.
Make the decision from the pattern of evidence
After testing the process, group findings into three outcomes.
Packaged SaaS is likely to fit
This is more likely when the core workflow matches the product's standard flow, important exceptions have controlled routes, required permissions are available, and the business can accept the practical process changes involved.
Packaged SaaS may fit with deliberate changes
This is more likely when some local habits can be simplified, reports can be adjusted, or a limited number of non-critical steps can change. Record those changes explicitly and make sure process owners agree with them.
A tailored managed application may be a better fit
This is more likely when the workflow depends on distinctive calculations, approval paths, terminology, controlled exceptions or integrations that a standard product cannot support without parallel spreadsheets and repeated manual intervention.
A managed custom application is not about reproducing every spreadsheet cell. It can be appropriate where the operational process itself is specific and needs to remain controlled as it changes. For a broader comparison of approaches, read managed custom web apps and packaged software for one Excel workflow.
Record the decision clearly
Create a short decision record after each evaluation. Include:
- the process and outcomes being assessed;
- the normal flow that was demonstrated;
- the exceptions that were tested;
- rules or controls that need further evidence;
- process changes the business is willing to make;
- unresolved gaps and their operational consequence; and
- the recommended next step.
This keeps the decision focused on operational fit rather than presentation quality. It also gives colleagues a clear basis for challenging assumptions before a new system becomes embedded.
Start with a Free Fit Check
If an important spreadsheet or operational process is difficult to fit into packaged software without losing key rules or accountability, Spreadsheet Upgrade can help you consider whether a managed custom web application is the better route.
You can also learn more about the managed approach on how it works.