Signs Your Team Needs Its Own Internal Tool
When an inbox, three spreadsheets and a group chat are your workflow, a small internal tool can pay for itself. The signs, and what to build first.
Most businesses run part of their operation on a workflow nobody designed. A request arrives by email, someone copies it into a spreadsheet, someone else checks a second spreadsheet, a third person updates a system, and a message in a group chat says it is done.
It works, mostly. But it depends on people remembering the steps, and it gets slower and more fragile as the business grows. Often the answer is not another product from a vendor, but a small internal tool built around how your team actually works.
What an Internal Tool Is
An internal tool is software your own team uses to do its job, not something customers see. Common examples:
- An admin panel for managing customers, orders or accounts
- An approval workflow for quotes, discounts, refunds or purchases
- A scheduling or dispatch screen for jobs and staff
- A single view that pulls together information currently spread across several systems
- A simple customer portal for status updates, so your team stops answering the same email
They are usually small. A good one does one job well for a handful of people, and nobody outside the company ever sees it. They also tend to last: because they are built around one team's real work, a good internal tool often stays in use for years, saving the same minutes many times a day.
Signs You Need One
- The same data is typed in more than once. Every retype is time spent and another chance for an error
- Work lives in an inbox. Requests get lost, nobody can see what is outstanding, and finding out where something stands means asking someone
- One person is the process. If they are on holiday, the work stops or goes wrong
- Approvals happen by message. Nobody can find who approved what, or when
- New staff take weeks to learn the steps. Because the steps are not in a system, they are in people's heads
- A spreadsheet has rules nobody may break. Locked tabs, warning colors, and a note at the top saying not to touch column F
Two or three of these in the same part of the business usually means the workflow has outgrown the tools it runs on. We wrote about the spreadsheet version of this in Signs Your Spreadsheet Has Quietly Become a Database.
Buy or Build?
Before building anything, check whether a product already does the job. For common workflows like support tickets, project tracking or basic approvals, there is usually a good off-the-shelf option, and it is often the right choice.
Internal tools are worth building when the workflow is specific to how your business works, when it needs to connect several systems you already use, or when the off-the-shelf options would force your team into a process that does not fit. Our post on choosing between custom software and off-the-shelf goes through that decision in detail.
What Makes a Good Internal Tool
| Quality | What it means in practice |
|---|---|
| Built around one workflow | It does one job from start to finish, not ten jobs halfway |
| Uses the systems you have | It reads and writes your existing systems instead of keeping another copy of the data |
| Fast for daily users | The people who use it all day can do the common tasks in a few clicks |
| Clear about status | Anyone can see what is waiting, who has it, and what happened |
| Records who did what | Every change and approval is logged with a name and a time |
| Easy to change | When the process changes, the tool can follow without a rebuild |
The second row matters most. An internal tool that keeps its own copy of customers or orders becomes one more system to reconcile. The best ones sit on top of the systems you already trust.
A Worked Example: Discount Approvals
Picture a sales team where any discount above a set level needs a manager's approval. Today the salesperson sends a message, the manager replies when they see it, and the approved price is typed into the quoting system by hand, sometimes days later.
A small internal tool turns that into one screen. The salesperson enters the quote and the requested discount. The tool checks it against the rules and either approves it automatically or sends it to the right manager with the deal details attached. The manager approves or declines in one click, and the approved price goes straight into the quoting system, along with who approved it and when.
Nothing about this is complicated, and none of it needs a new system of record, because it sits on top of the tools the team already uses. But it removes the waiting, the retyping, and the question nobody can answer three months later: who agreed to this price?
Start Small
The most successful internal tools start with a single painful workflow and a handful of users. Build the smallest version that replaces the current process from end to end, put it in front of the people who do the work, and improve it based on what they actually use.
- Pick one workflow. The one that causes the most errors or the most chasing.
- Sit with the people who do it. Watch the real process, including the workarounds.
- Build the smallest useful version. Enough to replace the old way completely for that workflow.
- Run both for a short while. Then switch off the old way, so there is one place to look.
- Improve from use. The second version is shaped by what people actually did with the first.
Trying to build one tool for every department at once is the most common way these projects stall.
It also helps to decide up front what success looks like: fewer errors, faster turnaround, or less time spent chasing. Measure it before the tool goes live, so you can tell afterwards whether it worked.
Who Should Use It First
The first users should be the people who feel the pain every day, not the managers who asked for the tool. They know the exceptions, the shortcuts and the steps nobody wrote down, and they will tell you quickly when something is in the way.
Give them a direct line to whoever is building it during the first few weeks. Small fixes made quickly, like a missing field or an extra click removed, do more for adoption than any launch announcement.
What It Takes to Keep It Running
Like any software, an internal tool needs looking after: hosting, security updates, and changes as your process and your other systems change. A small, focused tool is cheap to keep, and a sprawling one is not, which is one more reason to start narrow.
Whoever builds it should leave it documented and tell you plainly what it will need over time, whether they support it afterwards or your own team takes it over. If they will not, that is worth knowing before you start.
Where to Start
Pick the workflow your team complains about most, and write down every step it takes today, including the copying, the chasing and the checking. That list is the brief for the tool, and often the best argument for building it.
If you would like a second opinion on whether it is worth building, tell us about the workflow. Internal tools are a core part of what we build, alongside the integrations that connect them to the systems you already run.