Design internal software around the decisions a shared workbook conceals
An internal tool often begins as a response to repeated coordination: staff ask which request is current, who approved an exception, or why a number changed. The workbook or inbox may still contain the answer, but finding and interpreting it has become part of the daily workload.
Before replacing that arrangement, follow one task with the people who know it. The aim is to preserve useful judgment while making the record and responsibility easier to understand.
Separate the visible process from the working process
A written procedure might say that a coordinator prepares an estimate and a supervisor approves it. In practice, the coordinator may copy a previous estimate, change a rate, ask about an exception in a message, and mark a cell to indicate verbal approval.
Those actions are requirements evidence. Determine which are legitimate business decisions and which are workarounds for missing functionality. Do not assume every historical behavior should become a permanent feature, but do not discard it before understanding why it exists.
Use a harmless ordinary example and an unusual one. Ask the people involved to explain each input, calculation, and decision. Record disagreements for the person authorized to settle them.
Model the records staff need to distinguish
An estimate, customer, job, approval, and export may be related without being the same record. Identify stable references and the relationships needed to investigate a result later. A reused row number or a person's memory should not be the only connection.
Distinguish editable working information from the version used for a decision. If an approved amount changes, staff may need to know the earlier value, the reason for correction, and whether another review occurred. A single current number can be insufficient.
Reference data also needs ownership. Rates, categories, locations, and status meanings should not drift because several people update different copies without an agreed source.
Map authority through actions
List what each role may do: create, revise, submit, return, approve, export, administer, or correct history. Include the record boundary. A supervisor may review their team's work while an accounts role needs accepted results across the organization.
Consider absence cover and staff moves. Temporary delegation should have a reason and an endpoint. Removing a person's access should not make their past decisions impossible to interpret or leave active work without an owner.
Test refused actions as carefully as allowed ones. A convenient interface must not quietly grant authority the business did not intend.
Design queues around the next decision
A useful working view shows the information a person needs now. A reviewer may need exceptions, supporting evidence, and the age of the request. An operator may need the accepted instruction and any unresolved handoff. Showing every field to everyone can obscure the task.
Define why an item appears in a queue and how it leaves. A request waiting for missing information should not look identical to one awaiting approval. A stalled item needs a responsible person and a way to recognize that intervention is required.
Notifications can support the process, but the current queue should not depend on someone retaining an email. Staff need to find the authoritative record independently.
Decide how corrections behave
A correction may change a draft freely, create a new version, or require a reason from an authorized role. The rule depends on the consequence of the change. Avoid both extremes: unrestricted overwriting and an inflexible process that forces staff into unofficial records.
Competing edits need a policy too. If one person approves while another saves an older view, the second action should not silently reverse the decision. Preserve useful unsaved work when a conflict is rejected so the user can review and continue.
The history should explain meaningful events to staff. Technical logs serve a different purpose and should not become an uncontrolled duplicate store of private information.
Introduce the tool as a working change
A first release can cover one team and one request type. Rehearse migration with checked samples, including an exception and a record with history. Confirm relationships and the meaning of values, not only the number of imported rows.
Choose the moment the new application becomes authoritative. Explain whether the old workbook is read-only, archived, or retained for a deliberately separate task. Two active sources with unclear ownership can recreate the original problem.
Train users with the same examples used for acceptance. Ask them to complete a correction and hand work to another role without coaching through missing instructions.
Give the system continuing owners
Name the business-rule owner, access administrator, technical maintainer, and person responsible for provider accounts and recovery. Keep the released version, operating guidance, and acceptance examples connected.
The result should reduce the work of establishing what is true. Staff can still make judgments, but the application gives those judgments a defined place, a visible consequence, and a record another person can understand.