A request for an “all-in-one system” usually begins with a real frustration: someone is copying information, chasing approvals, or reconciling conflicting records. The frustration is specific, but the proposed project quickly expands into replacing the entire operation.
Before commissioning that replacement, define a pilot around one complete workflow. The purpose is to learn whether software improves a repeatable task enough to justify the cost of building and maintaining it.
Observe the work before listing features
Choose a process with a visible start and finish, such as receiving a service request and assigning it to the right person. Follow several real examples with the people who perform the work. Use anonymized or synthetic records when sharing material beyond the authorized team.
Write down who receives information, where they record it, who decides what happens next, and what exceptions require a different path. Include work done outside the official system: a follow-up message, a copied spreadsheet row, or an approval obtained verbally.
The GOV.UK Service Manual's discovery guidance is a useful reference for investigating the problem, user needs, and constraints before committing to a solution. It is a design method here, not a requirement imposed on a private business.
Establish a baseline that can be repeated
Measure the current workflow before introducing a tool. Useful observations include elapsed time, active handling time, repeated data entry, incomplete records, and how often a task returns for correction.
Define the measurement precisely. “Processing time” might mean minutes of staff effort or days waiting for approval; those reveal different problems. Record unusual cases separately and note the workload during the observation period.
Do not choose an improvement target simply because it sounds impressive. Agree with the team on what would make the pilot worth continuing, and retain the original measurement method for the comparison.
Compare a process change, an existing tool, and a custom build
Some bottlenecks need a clearer owner or a shorter approval path. Others fit an existing product with reasonable configuration. Custom software becomes a candidate when the workflow's requirements and expected value justify owning the resulting system.
Compare each option against the same needs: required roles, integrations, exportability, recurring cost, support, and what happens if the provider changes. Include the time your team will spend maintaining records and resolving exceptions.
A pilot can be a configured tool or a limited custom module. Its value comes from answering a question about the operation, not from maximizing the amount of code delivered.
Define acceptance through real scenarios
Describe the smallest complete flow. For example: a request arrives, required information is checked, an authorized person assigns it, and the requester receives a clear status.
Then define the exceptions:
- A required field is missing and someone must correct it.
- The same request is submitted twice.
- An employee tries to access a task outside their role.
- An integration is unavailable.
- A record needs correction after assignment.
- The team needs an export to reconcile or move its data.
For each scenario, state the expected behavior and who approves it. “The dashboard works” is difficult to test. “An authorized coordinator can see unassigned requests and assign one without losing its history” is a usable acceptance criterion.
Plan the return path before the pilot starts
Keep the existing process available until the pilot is accepted. Agree on the authoritative record during the trial, how changes are reconciled, and who decides to pause. Avoid maintaining two competing sources without a reconciliation owner.
Document how data can be exported, what a tested restore involves, and how access will be removed when someone changes roles. These tasks belong in the pilot's scope rather than in a vague promise to handle operations later.
Review outcomes before adding modules
At the review, compare the baseline with the pilot using the same definitions. Inspect errors, incomplete tasks, staff effort, and whether people can explain the status of their work. A faster screen does not establish a faster process if approvals still wait in an inbox.
Continue, revise, or stop based on the agreed criteria. Stopping a poor fit is a valid result. If the pilot succeeds, prioritize the next workflow using evidence from actual use.
KAIZO's custom software services can start with that bounded operational question, so the first delivery gives your team something concrete to evaluate.