Look for operational pressure, not file size
A small spreadsheet can deserve software if every row creates follow-up work, customer communication, approval, scheduling, or reporting. A large spreadsheet can remain fine if it is only a reference table. The trigger is operational pressure: people asking who owns the next step, whether a record changed, or why an approval happened.
The old Wecode portfolio included CRM and personnel dashboard work. That category is still useful because the business problem is durable: teams need to route records, review status, assign responsibility, and understand what happened without searching through chat, email, and file versions.
Define the records and states first
A workflow system starts with nouns and states. Common records include leads, requests, providers, customers, lessons, tickets, approvals, invoices, tasks, and assets. Common states include new, in review, assigned, waiting, approved, rejected, complete, and escalated.
That is why process modeling practices matter even for small custom systems. Camunda describes BPMN as a way to model processes for automation in its guide to automating a process using BPMN. You do not need a heavyweight workflow engine for every project, but you do need enough process clarity that people and software agree on what the next step means.
Once those are clear, the interface becomes easier to design. Lists need filters. Detail pages need history. Managers need dashboards. Operators need quick actions. Customers need status updates. None of that has to be overbuilt, but it has to be explicit.
Keep the first workflow narrow
The first release should not replace every spreadsheet in the company. It should replace one workflow where the current process is expensive, visible, or risky. Intake and review are often good starting points because they reveal ownership, validation rules, and reporting needs quickly.
The GOV.UK Service Manual argues that services should solve a whole problem for users rather than optimize one isolated screen. That principle from “Solve a whole problem for users” is useful for business workflow software too: a workflow that captures a request but leaves assignment, communication, and reporting outside the system has not solved the whole operational problem.
Exports still matter. Good workflow software often keeps CSV export, audit logs, and simple reporting because teams need continuity while the new system earns trust.