Coverage Insurance Agency had no clear read on how its team spent the day. We built a disclosed, privacy-first activity tool that turns producers’ day-to-day into coaching rather than surveillance, and a live dashboard for their outreach showing what is sent, answered and clicked. Both run on the agency’s own stack, and both were used the day they shipped.
01 — INTERNAL TOOLS
The dashboard that replaces the load-bearing spreadsheet
Most businesses have one file everything depends on. It has a colour code only its author understands, it breaks when two people open it at once, and it is still the only place the real numbers live.
An internal tool is software built for the way one business actually works — a dashboard, a form, a small app — replacing the spreadsheet or shared document a team has quietly come to depend on. Perspicality builds the tool, the data plumbing that feeds it, and the reporting that drafts itself from the same source. It runs on your stack under your own accounts, shaped around your process rather than asking your process to bend around a product.
02 — BUILD
What we build
An internal tool earns its place only by replacing something people already do by hand. Each piece below starts there: the view, the thing that captures the work, the data underneath, and the report that used to eat a morning.
The internal dashboard
One screen answering the questions your team keeps asking — what is in flight, what is stuck, who has what — pulled live from the systems that already hold the answer rather than from a file somebody updates on Fridays. Panko’s review of the research on spreadsheet errors concluded that they are both common and non-trivial, which is the real argument against running a business off one.
The form or the small app
The place the work actually gets entered: an intake form, a request queue, a job-tracking screen built for one job rather than configured out of something general. Narrow tools get adopted because they ask for exactly what is needed and nothing else, which is also why they replace the spreadsheet instead of sitting next to it.
Pulling and cleaning the numbers behind it
A dashboard is only as good as what feeds it, so most of the work is underneath: getting data out of the systems holding it, reconciling records that disagree, and handling the duplicates and gaps every real dataset has. Done properly, this is the part that stops people quietly keeping a private copy on the side.
Reporting that drafts itself
The recurring report — the weekly numbers, the client update, the summary for whoever asks — assembled from the same source the dashboard reads, so the report and the screen cannot disagree. A person still edits it and sends it. What disappears is the morning spent rebuilding the same tables from the same exports.
03 — PROOF
Where this already runs
Coverage Insurance Agency is where internal tools replaced guessing at the day. What the agency runs now is a disclosed activity tool for its producers and a live dashboard for its outreach.
04 — PROCESS
How it works
Four steps, the same four on every system we run: we watch the work, agree what gets built, ship it, then operate it.
Diagnose
We spend a week inside the work, watching how it is really done, and name where the time and money leak.
Design
We write down what the system will do — owners, hand-offs, what happens when it is wrong — and you approve it before anything ships.
Build
We build on your stack and ship a working tool in weeks, not quarters. Your team uses it the day it lands.
Compound
One-time setup, then flat monthly to monitor and tune it. Each system frees up time and data the next one builds on. If it does not earn its keep, fire us.
05 — FIT
Where it fits
An internal tool is the right call once a spreadsheet or a shared document has quietly become infrastructure. If losing that file would stop work, it is already a tool wearing a spreadsheet’s clothes.
- A spreadsheet has quietly become infrastructure, and losing it would stop work.
- The numbers everyone quotes get rebuilt by hand, and no two versions agree.
- People keep a private copy of the data because they do not trust the official one.
- The tool you need does not exist as a product, because the process it serves is yours.
- Somebody spends a morning every week producing a report nobody then changes.
06 — LIMITS
What this doesn't do
We build the tool your business is missing, not a second copy of one it already has. The limits below are where a custom build stops being the right answer.
We do not rebuild software you already pay for. If your CRM, your ticketing system or your accounting package already does the job, the honest work is configuring it and wiring it in — not writing a worse version of it.
We do not put a dashboard on data nobody trusts. Cleaning what feeds it comes first, because a good-looking screen over bad numbers only spreads the bad numbers faster.
This is not a data-warehouse programme. We build the tool the business is missing and the plumbing it needs, not an enterprise reporting stack that would need its own team.
We do not build a tool nobody asked for. If the people who would use it are not in the room while it is designed, it ends up beside the spreadsheet rather than instead of it.
07 — FAQ
Questions we get asked
Replacing the file a team runs on makes people nervous in specific, reasonable ways. Every question below has been put to us more than once.
Why not just use an off-the-shelf tool?
Often you should, and we will say so. Where a general builder covers the job, configuring it is faster and cheaper than anything custom. What those tools handle badly is the part underneath — reconciling data across systems, rules particular to your process, and anything that has to keep working unattended. That is usually where a build starts being worth it.
What happens to the spreadsheet?
It stops being load-bearing. We move the process into the tool first and let the file run alongside until the team stops opening it, which is the only honest test of whether the replacement is finished. The history comes across; what does not come across is the version somebody keeps on their own laptop.
Do we own what you build?
Yes. It is built on your stack, under your accounts and your domain, and the data stays in systems you control. We operate and extend it with you for as long as that earns its place, but there is no version of this where ending the relationship turns the tool off.
How do you make sure people actually use it?
By building around what they already do rather than what an org chart says they do. We watch the real work first, keep the tool narrow enough to learn in one sitting, and put it where the rest of their day happens. Adoption is a design problem rather than a training problem, and a tool nobody opens is a failed build whatever it cost.
Who maintains it, and who changes it later?
We do, and being asked is the point. Building it is one charge; keeping it useful is the flat monthly: the view somebody wants once they are in it daily, the fix when a source system moves underneath. A tool nobody can change grows a spreadsheet beside it.
08 — RELATED
Related systems and reading
Most engagements touch more than one of the systems we build, because each one feeds the others. The links below are the closest matches to this service.
Want this running for your business?
Tell us what isn't working and what done looks like. We come back with what we would build first and what it takes to run it.