Internal tools that match how your team actually works.

When a spreadsheet has reached its ceiling

• Several people edit it, and nobody is sure which version is current.
• It needs different views for different people — and someone maintains them by hand.
• Important rules live in one person's head, not in the file.
• You need to know who changed what, and when.
• Colleagues work around it with copies, so the "real" data is scattered.

Spreadsheets are excellent for exploring a problem. The moment other people depend on the answer, the structure around the data starts to matter more than the data.

Tools that commonly make sense

• Request and work tracking — who asked for what, who owns it, what state it is in.
• Approvals — purchase, leave or content sign-off with a clear record.
• Stock and equipment registers — what you have, where it is, who has it.
• Onboarding and checklists — repeatable processes that must not skip a step.
• Operational dashboards — the few numbers a manager needs each morning, drawn from the real data.

Design principles that make tools get used

• Built for repeat users. People will use it all day, so speed, search, filters and sensible defaults matter more than first-visit charm.
• Roles that match reality. Requesters, doers and managers need different views of the same record.
• History by default. Every change records who made it and when, so questions can be answered without detective work.
• Small steps. Replace the worst part of the old process first, then grow.

Moving from spreadsheets without disrupting work

1. Describe the current process as it really runs, including the workarounds.
2. Clean and import the data you want to keep. Expect to discover duplicates and gaps.
3. Run both in parallel for a short, agreed period so nothing depends on an untested system.
4. Switch over on a clear date and retire the old file, so shadow copies do not creep back.

The most common failure is not technical: the old spreadsheet keeps living because nobody was asked to stop using it. Agree who announces the switch.

An illustration: from scattered requests to one queue

Imagine a small events company. Requests for equipment, venue changes and supplier orders arrive by WhatsApp, by email and in conversations in the corridor. One coordinator keeps a spreadsheet; when she is away, nobody knows what is outstanding. (This is an illustrative scenario, not a client.)

A first internal tool would do three things only: give every request a record with an owner and a status; let requesters see where theirs stands without having to ask; and show the coordinator a single list of what is overdue. Reports, integrations and approvals would wait until that list is trusted.

That is the shape of most successful first releases: one list, one owner per item, one place to look.