Before you build an internal tool, map these five things.

The spreadsheet is not always the problem. Sometimes it is doing exactly what it was asked to do, while the process around it has become too complicated.

A request arrives in a chat. Someone adds it to a sheet. Someone else asks for missing information. By the time the work is finished, three people are maintaining different versions of the same story.

It is tempting to replace all of that with a custom app. Before choosing a framework or drawing a dashboard, map a single real request from beginning to end. These five things will tell you much more about what the tool needs to do.

1. What starts the work, and what finishes it?

“We need a request management system” is a category. “A customer asks for a change, and our team needs to agree the scope before work starts” is a process you can design around.

Pick a recent example. Where did the request first appear? What made it ready to work on? What did the person responsible need to know? Write down the actual steps, including the quick messages and copy-and-paste work that never made it into a formal procedure.

Then define the finish. Is a request done when the work is delivered, when someone approves it, or when the invoice is paid? A tool that cannot tell those states apart will move the confusion into a nicer interface.

2. Who can see, change and decide?

The person who enters a request may not be the person who approves it. The person doing the work may need internal notes that the customer should never see. Put those differences on paper before creating accounts.

Make a small list of roles and the actions each one needs. Keep the roles specific to the work: requester, coordinator, reviewer and owner are often more useful than a single “admin” who can do everything.

• Who can create or edit a request?
• Who can change its priority or approve a cost?
• Who should be notified, and who only needs a summary?
• Who takes over when the usual owner is unavailable?

Ask the people doing the work to check the map. A handover that looks simple to a manager can contain several small decisions that only the operator knows about.

3. What information belongs in the system?

Start with information required for a decision, rather than every field you might want later. If the team cannot explain what a field changes, leave it out of the first version.

For each important piece of information, record its source and owner. A customer name might come from a customer directory. A quoted price might belong to the person approving the scope. If both systems can edit the same value, decide which one wins.

Also decide what you do not need. Passwords, unnecessary personal details and sensitive documents should not end up in a general notes field simply because the field is available.

4. What happens when the normal path breaks?

Most process diagrams describe a request that arrives complete, gets approved and finishes on time. Real work has duplicates, missing details, changed priorities and people who are on leave.

Take three awkward recent examples and run them through your proposed process. What happens if someone withdraws a request after work starts? Can a reviewer ask a question without rejecting everything? Where does a failed connection or an unassigned request appear?

You do not need to automate every exception. You do need a visible place for it to land and a person who knows it is theirs to resolve. An explicit “needs review” state is often more useful than a workflow that silently guesses.

5. What will the team need after launch?

A working demo is one milestone. A system the business can keep using is another. Before building, decide who will own access, hosting, updates and the next change request.

Include a handover in the scope: a short guide, an explanation of permissions, a way to export important records and an agreed process for reporting a problem. If the system will hold business data, discuss backups and how recovery will be checked.

These decisions affect the build. It is easier to make data export possible when you understand the records than to discover the need during an urgent change of tools.

Define a first version worth building.

Now reduce the map to one useful slice. For the request example, a first version might capture the request, show missing information, assign an owner, record an approval and display the next action. Advanced reporting and automatic estimates can wait.

Agree a few real scenarios that the team can use to check the result. A complete request, an incomplete request and a request that changes halfway through will teach you more than a long list of screen names.

The goal of the brief is not to predict every future need. It is to make the first decision clear enough that everyone knows what they are building and why.