What needs to be settled before choosing software?
Agree what a record represents, who may change it, which states mean work can progress and where the authoritative information lives. Then choose software around that agreement. If staff disagree about whether a row means requested, approved or completed, an automated hand-off will carry the disagreement into the next system faster.
Inspect the work around the workbook
Follow a recent item from the original request to its final outcome. Include email approvals, chat messages, copied tabs, formulas, hidden columns and the person who fixes mistakes before the weekly report. Ask staff to demonstrate an ordinary case and a disputed one. The spreadsheet is evidence of the workflow, but it rarely contains the whole operating process.
Identify why the spreadsheet has become painful
Separate volume from ambiguity. Too many rows may be a tooling limitation. Competing copies, unclear approvals and undocumented status colours are ownership problems. Write the consequence in business terms: staff cannot tell which jobs need action, customers receive conflicting updates or someone must reconcile the same records repeatedly. This establishes what the replacement must improve.
When should a business keep, configure or build?
Keep spreadsheets for exploratory analysis and contained work that remains understandable under existing controls. Configure an existing product when its workflow and permission model fit the business with manageable changes. Consider custom software when important rules, hand-offs or integrations cannot be represented clearly without persistent workarounds. The decision should follow the operation, not dislike of spreadsheets.
Evaluate a real case instead of a feature checklist
Run the same representative request through each option, including reassignment, correction and cancellation. Check who can edit sensitive fields, whether staff can find blocked work, how changes are recorded and whether data can be exported meaningfully. A product with many features can still force the most important decision into an email.
Include the cost of operating the replacement
Compare configuration, migration, integrations, staff training, reporting and support alongside the subscription or build cost. Custom software creates ongoing ownership obligations. An existing product creates constraints around its model and integration options. Neither removes the need for a business owner who can settle what the workflow should do.
How do you turn rows into a clear operating model?
Model one complete piece of work using stable identifiers, explicit states, responsible roles and permitted transitions. Separate source facts from calculations and decisions. The first deliverable can be a short workflow agreement that staff can test against real cases before any interface is built. It should explain who acts next and what evidence allows progress.
An illustrative service-request example
Imagine a workbook where green means either assigned or finished, depending on the team. Replace that colour with named states: received, awaiting information, ready to schedule, assigned, completed and cancelled. A coordinator moves a request to ready only when the required details are present; a dispatcher assigns it; the responsible operator records completion evidence. Colour can support the display, but no longer carries the business rule.
Keep different facts in different records
Give the customer, service request and invoice separate stable identities, linked where needed. A customer name is not a reliable request identifier. Keep payment status with the authoritative finance record instead of allowing an operations tab to redefine it. Decide who resolves duplicate customers and incomplete requests before importing them. The Government Data Quality Framework provides useful supporting guidance on assessing whether data is fit for its purpose.
Preserve a visible path for uncertainty
An incomplete address should leave a request awaiting information with an owner and reason. A cancelled request should retain its history. Give staff a supported way to correct a mistake instead of forcing them to create another private spreadsheet. Model only the exceptions that materially affect the first workflow, with a named temporary process for the rest.
What should the first migration include?
Move one valuable workflow from intake to its final operational outcome, including permissions, corrections and the reports needed to run it. Migrate the records required for that workflow and retain accessible historical evidence where appropriate. Avoid making every department and every historical workbook part of the first cutover unless the dependencies genuinely require it.
Prepare a migration ledger
For each source column, record its meaning, destination, transformation, validation and owner. Preserve source identifiers so disputed imports can be traced back. Count accepted, rejected and duplicate rows separately. Reconcile meaningful totals and relationships as well as row counts: an import can contain the right number of requests while attaching them to the wrong customers.
Quarantine ambiguity rather than guessing
Keep malformed dates, conflicting statuses and unresolvable duplicates in a review queue with an owner. Do not silently select a convenient value to make the import pass. Test a representative sample that includes old formats and awkward records. The business owner should accept both the mapping rules and the unresolved exceptions before those records drive live work.
Make integration status honest
If completion triggers invoicing in another system, record whether the hand-off is pending, confirmed or needs attention. Decide which system owns each field and how retries avoid duplicates. A replacement that depends on someone manually checking whether the other system received the record has preserved a central source of uncertainty.
How can the business stop using the old workbook safely?
Define cutover as a transfer of write authority, with a named owner, acceptance checks and a recovery procedure. A parallel comparison period can help verify the new workflow, but staff need one authoritative place to make operational changes at each stage. Otherwise the migration creates another competing copy instead of resolving the original problem.
Use an explicit go-live gate
Before switching, require reconciled migration results, working role permissions, a demonstrated correction path and staff who can complete representative tasks without the builder's help. Compare unresolved work and key reports with the agreed source. Review completion time, manual corrections and work waiting for an owner against a baseline; choose thresholds that reflect this operation rather than adopting an arbitrary target.
Account for writes made after cutover
Freeze routine edits in the old workbook when the new system takes ownership, then retain the archive under appropriate access controls. If a critical problem requires returning to the old process, first capture and reconcile new-system changes made since the switch. Restoring an old export without those changes can lose real work. Assign someone to authorise the switch back and confirm where staff should work.
Start with one workbook and one disputed hand-off
Twofold can help map the current operation, compare a configured product with a custom workflow and scope the first useful migration. Bring a representative workbook with sensitive information removed and an example of work that repeatedly stalls. AI can be considered later for a specific interpretation task once the record and decision rules are clear.