Excel is not a problem just because your business uses it every day. A well-owned workbook can be the simplest, cheapest and most flexible tool for a process that is still changing.
The problem starts when the workbook stops being a tool and becomes the workflow itself. A request arrives in email or WhatsApp, somebody retypes it into a sheet, another person approves it in chat, and a manager asks for a status update because the current state cannot be trusted from the file alone.
That does not automatically mean you need custom software. It means you need to decide what role Excel should continue to play, what can be fixed with process discipline, and what has become important enough to give a proper operating record.
This guide gives you that decision framework.
Keep Excel when
Keep the workbook if most of the following are true:
- One person clearly owns it.
- Only a small number of people edit it.
- The process is still changing every week.
- The workbook mainly calculates, analyses or presents data.
- There is one agreed version and everyone knows where it is.
- Mistakes are easy to spot and inexpensive to correct.
- Approvals, permissions and audit history are not important.
- Updating it does not require repeated copying from other tools.
In that situation, replacing Excel may create more work than it removes. A new system would force you to define fields, states and rules before the process is stable enough to justify them.
Improve the workbook first. Remove duplicate tabs, protect formulas, define the owner, standardise inputs and archive old versions. If that restores trust in the process, stop there.
Replace it when
Consider replacing one Excel-led workflow when several of these conditions happen together.
Nobody trusts the current version
The team has copies in email, local folders and shared drives. Changes have to be reconciled, and the phrase “which file is the latest?” appears in normal operations.
Version control is not just a tidiness problem. Once people stop trusting the shared record, they create private tracking methods. The process becomes harder to see precisely when management needs a reliable view.
The status lives outside the row
The row says a job is open, but the real position is in a WhatsApp message, an email thread or the coordinator's memory. A manager cannot tell what is waiting, blocked or complete without asking somebody to reconstruct it.
A workflow system is useful here because status, owner, next action and history become part of the record rather than commentary around it.
Several people perform the same handoff
One person receives a request, another checks it, somebody approves it, and a final person sends or exports the result. Each handoff introduces another place where work can wait without being visible.
A shared sheet can list these steps, but it cannot reliably enforce who can do what, what information is required, or which event moves the work forward.
The same data is retyped
The team copies customer, job, order or quote details from a form into a workbook, then into an email, accounting package or customer document. The issue is not that typing is slow once. It is that the same fact has several chances to drift.
This is often a good candidate for Excel workflow automation: capture the information once, keep one operational record, and export or connect it only where the first release requires.
Permissions and accountability matter
If some users should see only certain records, if an approval must be attributable to a person, or if you need to explain how a record reached its current state, a shared workbook is being asked to behave like an application.
That is usually the point to consider a custom internal tool with explicit roles, actions and history.
The process is stable enough to describe
Custom software works best when you can name the starting event, required information, decision points, owners and completed state. If the team cannot agree on those, the first task is process design, not development.
Do not automate disagreement. You will only make the disagreement harder to change.
A practical decision test
Choose one workflow and answer these ten questions:
- What event starts the work?
- What information is required before anybody can act?
- Who owns the record at each stage?
- Which states can the work be in?
- What decision moves it from one state to another?
- Which exceptions need human judgement?
- What is copied to or from another system?
- Who should be able to view, edit and approve?
- What evidence shows the work is complete?
- What happens when an integration or input fails?
If the team can answer these consistently, the workflow may be ready for software. If every person gives a different answer, run the workflow manually with a shared checklist first and use the differences to settle the operating rule.
Then score the problem from zero to two on each of these dimensions:
| Dimension | 0 | 1 | 2 |
|---|---|---|---|
| Frequency | Occasional | Weekly | Daily or continuous |
| People involved | One owner | Two or three | Several roles or teams |
| Copying | None | One repeated copy | Several systems or channels |
| Visibility | File is enough | Some follow-up needed | Status must be reconstructed |
| Error consequence | Easy correction | Rework or delay | Customer, cash-flow or compliance impact |
| Process stability | Still changing | Mostly agreed | Stable and repeatable |
A high score does not prove that custom software is the answer. It tells you the problem deserves a structured comparison against process fixes and off-the-shelf products. The final question is economic: will the value of fewer handoffs, clearer ownership and better visibility justify the build and ongoing maintenance?
Decide what to replace first
Do not start with “replace Excel across the company.” Start with one record moving through one lifecycle.
Good first-release boundaries sound like these:
- A service request from intake to assigned work.
- A purchase request from submission to approval.
- A customer onboarding file from document collection to handover.
- A freight enquiry from complete request to quote status.
- A logistics job from confirmed handover to completion.
For logistics teams, the relevant first step may be a job tracking system that makes job state, ownership, documents and exceptions visible. It should not pretend to replace a transport-management system, customs platform or carrier network.
The boundary matters because the first release must be small enough to test against real acceptance criteria. “Operations platform” is not a testable scope. “Create a job, assign an owner, move it through six agreed states, attach required documents and show blocked work” is.
Compare three possible answers
1. Keep Excel and tighten the process
Choose this when the workflow has one owner, low risk and limited handoffs. Standardise the template, lock formulas, define naming rules and decide where the authoritative file lives.
This is the right answer more often than software vendors admit.
2. Automate around the workbook
Choose this when Excel still performs a useful calculation or analysis, but intake, routing, reminders or status tracking are the real bottlenecks.
The workbook can remain as an import, export or specialist calculation. The workflow around it gains structure without forcing every formula into a new application.
3. Build a custom internal tool
Choose this when the business needs roles, permissions, workflow states, audit history or a dedicated interface that an ordinary workbook cannot provide safely. The Business App / MVP service shows the corresponding first-release scope and published range.
The first release should cover one core flow. Additional reports, portals and integrations can follow only after the team has operated that flow and confirmed what is actually missing.
What not to build
A replacement project becomes risky when the brief is a collection of every complaint anyone has ever made about the workbook.
Keep these outside the first release unless they are essential to the core workflow:
- A company-wide data warehouse.
- Every historical report.
- Unrestricted dashboards for every role.
- A native mobile application when a responsive web interface is sufficient.
- Large historical migrations that nobody has reviewed for quality.
- Integrations that have not been checked for documented access.
- Automated decisions that still require commercial or operational judgement.
Write the exclusions next to the inclusions. This makes quotations comparable and gives the project a finish line.
Our software project scoping guide provides a brief template for users, integrations, existing data, permissions, scale and out-of-scope items.
Set a baseline before you change anything
Before replacing the workflow, record what happens today. Use your own operational data rather than a vendor's generic promises.
Possible baseline measures include:
- How long it takes to make a request ready for action.
- How many follow-up messages are needed to complete the information.
- How many open items have no clear owner.
- How often the team reconciles conflicting versions.
- How long work waits at each approval or handoff.
- How many records require correction after retyping.
Choose one or two measures that reflect the actual reason for the project. Track them before launch and again after the team has adopted the new workflow. Without a baseline, you can confirm that software was delivered but not whether the operating problem improved.
Check the commercial fit
A useful workflow is not automatically worth custom development. Compare the likely value with both the initial build and the ongoing cost of hosting, maintenance, support and future changes.
PSOI Tech publishes its current service ranges and scope examples. The lower end assumes a bounded workflow, limited roles and standard connections. More roles, bespoke integrations, unclear data and production requirements move a project upward.
If an off-the-shelf product covers the process without forcing major workarounds, use it. Custom software is justified when the workflow matters enough, differs enough, and stays stable enough that owning the fit creates more value than configuring around a generic product.
Use relevant work carefully
A case study should show what was actually delivered, not imply that every part of your planned system already exists.
The NS Logistics Global case study documents a freight-forwarding engagement that included clearer service communication and structured quote-request capture. It is relevant proof of work in a logistics operating context, but it is not a claim that the same screens, integrations or outcomes apply to your workflow.
Ask any vendor to separate reusable delivery experience from assumptions that still need validation in your operation.
A 30-minute worksheet
Take one spreadsheet-led process and write this on a single page:
WORKFLOW:
The one process we are reviewing.
START:
The event that creates a record.
REQUIRED INPUT:
The information needed before work begins.
STATES:
The small set of positions a record can be in.
OWNERS:
Who is responsible at each state.
HANDOFFS:
Where another person or system becomes involved.
EXCEPTIONS:
What still needs judgement.
OUTPUT:
What proves the workflow is complete.
CURRENT BASELINE:
One or two measures we can record now.
KEEP:
What Excel or existing systems should continue to do.
REPLACE:
What a first software release should take responsibility for.
OUT OF SCOPE:
What we are deliberately not building yet.
If you can complete this with the people who run the process, you have the start of a useful brief. If you cannot, the missing agreement is the work to do next.
Frequently asked questions
Is Excel unsuitable for a growing SME? No. Excel can remain the right tool for analysis, calculation, planning and low-risk processes. Replace a workflow because its handoffs, permissions, visibility or error consequences justify a different system, not because the business reached an arbitrary size.
Should we buy software before considering a custom build? Yes. Compare suitable off-the-shelf products first. Choose custom software only when the workflow matters, available products create material workarounds, and the value justifies ownership and maintenance.
Do we have to migrate every historical row? No. Decide what the team needs to operate from launch, what can remain in a read-only archive, and what has enough value and quality to migrate. Historical migration should be an explicit scope item, not an assumption.
Can the new system still export to Excel? Yes. Excel can remain useful for ad hoc analysis, finance handoffs or specialist calculations. The goal is to give the operational record a reliable owner and state, not to ban spreadsheets.
What should the first conversation with a developer produce? It should identify the core bottleneck, the smallest useful release, important unknowns, likely integrations, boundaries and an indicative commercial range. You should also hear when process changes or an existing product are a better fit.
If one spreadsheet has become the queue, approval trail and status report for a repeated workflow, describe it in the four-field workflow review. You will get the main bottleneck, a recommended first release, an indicative cost and an honest view of whether custom software is justified.