You cannot manage a distributed team you cannot see
A field IT team is a genuinely hard operational problem. Everyone is busy, everyone is somewhere else, and the only honest answer to “are we covering our sites?” is usually a shrug and a promise to find out.
✗Coverage by group chat
- The only record of who went where is a message thread that scrolls away by Thursday.
- Nobody can tell which sites have not been visited this month until someone complains.
- Remote work is invisible, so the technicians who fix the most look like they do the least.
- Monthly reporting is a manual reconstruction that takes half a day and is wrong anyway.
- Public holidays differ by state, and the roster does not know that.
✓Coverage on a live board
- One screen shows active now, technicians reporting, on-site versus remote, sites covered and completed today.
- Coverage percentage by state and by site, for any period, in one click.
- Remote work is a first-class mode, logged and counted exactly like an on-site visit.
- Reports are generated, not reconstructed, and export as CSV or PDF.
- State-based public holidays are held in the system — including the ones only one state observes.
Five screens that replace the status meeting
Built for the person who has to answer for coverage, and for the technician who just wants to log the day and move on.
The live board
Real-time coverage across every site — who is where right now, on site or remote, and what they are working on. Active now, technicians reporting, on-site and remote counts, sites covered today and completed jobs across the top. Per-technician cards show the current site, mode, live status and work categories, with regional coverage bars and a live activity feed beside them.
Twenty seconds to log a day
The technician view. Choose the clinic, pick on-site or remote, set the live status, tick the work categories that apply and add a line of description. Several clinics can be logged for the same day. If logging a visit takes longer than a coffee order, nobody does it — so this screen is deliberately the least impressive one in the product.
Coverage reporting that writes itself
Daily, weekly or monthly, all sites or one. Total visits, site coverage percentage, sites visited against the full estate and active technicians, then visits over the period, coverage by state, support coverage by technician, the on-site versus remote split and the most-visited sites. Export to CSV or PDF.
Every action, attributable
A complete activity log of every action performed in the portal by every user, administrators included — timestamp, user, role, category, action, detail and source IP. Filter by category or user, export to CSV. Useful for accountability, and considerably more useful the first time a record is disputed.
The feed the service desk actually watches
A rolling feed of every visit as it starts and finishes — technician, mode, site with postcode and state, work categories and status. It is the fastest way to answer “is anyone near Auburn today?” without interrupting anyone to ask.
Take the full tour
Five screens from the working portal.
The operational detail that makes it stick
Site directory
Every location with its postcode, state and visit history — searchable, so a new technician can find a site without asking.
On-site and remote as equals
Remote support is logged, counted and reported alongside physical visits, because most of the work is remote.
State-aware holidays
Public holidays maintained per state, including the ones only one state observes, so coverage targets are fair.
Technician profiles
Seniority, region and history per technician, so the load distribution in reporting means something.
Coverage targets
Set an expected visit frequency per site and let the reporting surface the sites drifting past it.
Auto-refresh
The board refreshes itself on a twenty-second cycle — designed to live on a wall screen in the operations room.
Scheduled reporting
Daily and weekly coverage reports generated and exported without anybody opening the portal.
Work categorisation
Twelve categories on every visit, so the reporting answers what the team spends its time on, not just where it went.
Built for any estate
Clinics, branches, depots, retail sites or schools — the model is sites, technicians, visits and coverage.
Small product, serious record-keeping
A visit log becomes an operational record the moment somebody disputes it. This one is built to hold up.
Live inside a fortnight
Load
Your sites, postcodes, states and regions are imported, along with the technician roster and seniority.
Configure
Work categories, coverage targets, reporting periods and state public holidays are set to match how you operate.
Adopt
Technicians log their first week. The form is short enough that adoption is a habit question, not a training question.
Report
The first monthly coverage report comes out of the product instead of out of somebody’s Sunday evening.
Straight answers
No, and deliberately so. It tracks site coverage and work type, not minutes. Technicians log which sites they worked and what kind of work it was — the product is built to answer coverage questions for management, not to surveil individuals.
That is the whole design constraint. Logging a visit is one short form — clinic, mode, status, tick the categories, one line of description — and several clinics can be logged for the same day in under a minute. Adoption failures in tools like this are almost always a form-length problem.
Yes. The underlying model is sites, technicians, visits, work categories and coverage. Clinics, branches, depots, retail stores, warehouses and schools all fit it without modification — only the labels change.
Yes. The live board auto-refreshes on a twenty-second cycle and is laid out for exactly that. Most teams run it on a monitor in the operations room and stop having a morning coverage meeting.
As a first-class mode. Remote visits are logged, counted and reported alongside on-site work, with an explicit on-site versus remote split in the reporting so the technicians who resolve the most remotely are visible rather than invisible.
See your own estate on the board
Send us your site list and we will load it into a private instance, so the first thing you see is your own network with your own regions rather than a demo dataset.