Hypothetical: Replacing a shared spreadsheet with a working application

Where the difficulty starts

In this example, a service business receives requests through email. A coordinator enters each request into a spreadsheet and assigns it to a colleague. Supporting documents stay in inboxes or shared folders. Staff update the sheet when they have time.

The same request sometimes appears twice. “Complete” can mean that the work is finished, the customer has been informed, or the invoice is ready. A manager keeps a separate list because the sheet cannot answer a basic question: which requests need attention today?

Define the work before specifying the application

The first discussion would follow a request from receipt to closure. Who checks that it is complete? Who accepts the assignment? What happens when a customer changes the request? Which actions need approval?

Those decisions would establish a small initial scope: receive a request, assign it, update its progress, record exceptions and confirm closure. Historical analysis and optional integrations could be considered separately, with their cost and value assessed before inclusion.

What an initial application could contain

These are proposed requirements for this example, not features of an existing Adviserve product.

Prepare the move from the spreadsheet

Migration would begin with a decision about what deserves to move. Current requests might need cleaning and importing; old records might be retained separately with a documented way to retrieve them. Reproducing every obsolete column would add complexity without necessarily helping the team.

Permissions would be agreed around actual duties. A person assigned to a request may need to update it without being able to change the underlying approval rules. Test records would be used to check these boundaries before live information is introduced.

What the engagement would leave behind

The proposed handover would include an agreed scope, a working application within that scope, checked migration records, test evidence, user instructions and an agreed support arrangement. Ownership would follow our standard terms: once the final payment is made, the business would own the software we build for it, with its source code, documentation and data. Third-party components inside it, such as open-source libraries or paid services, stay under their own licences. Hosting and administrative access would be recorded in the agreed terms.

Completion would be reviewed through ordinary tasks: a new request, a reassignment, a returned item, an overdue request and a correction after closure. The business would agree the acceptance criteria before development begins.

Want the method behind these steps? Two briefings set it out: questions to ask before buying software and who owns support after an application goes live.

Capabilities involved

Technology & Automation would lead the application work. Governance would help define approvals and exceptions. Cybersecurity would inform access decisions, and Corporate Training could prepare the people who will use and administer the application. Each contribution would be included only where the scope requires it.

Have a spreadsheet doing too many jobs?

Bring the current file and walk us through a recent request. In a first discussion we can work out whether configuration, a better workflow or a custom application fits the work.

Book a discussion →

Related capability:Technology & Automation →