Read me first

If you have just been handed this software and you are wondering what it is, this is the page to start on. It is written for someone who runs vehicles for a living, not for someone who writes software. There is nothing technical here.

---

1. Who this is for

Organisations that operate their own vehicles and currently keep track of them with some combination of a tracking website, a maintenance spreadsheet, a WhatsApp group and somebody's memory.

That covers a lot of businesses: haulage and distribution operators, builders' merchants and plant hire, waste and recycling rounds, utilities and field service, coach and minibus operators, council fleets, and any industrial site with its own yard vehicles. If you have somewhere between a handful and a few hundred vehicles, and the people who look after them sit in the same organisation, this is aimed at you.

It is aimed at one operator per installation. It is not built to let a service provider run several unrelated customers' fleets side by side out of a single copy.

2. What it does

It shows you where your vehicles are, tells you when something needs attention, keeps their servicing on schedule, records what your drivers found when they checked them, and keeps an honest record of who did what.

Concretely, it holds five things together in one place:

• Where everything is, updated as the vehicles report in, with the history of where they have been.
• What needs your attention — arriving, leaving, straying somewhere it should not, idling too long, going too fast — decided by rules you write.
• What needs servicing, worked out from the distance and hours the vehicles themselves report, and the jobs raised to deal with it.
• How the vehicles are being driven, per driver, adjusted for how far each one actually travelled.
• What the drivers reported on their walkaround checks, and what happened to each fault they found.

What it is not. This is a core build, and it is worth being blunt about the edges. It does not provide hours-of-service or electronic logging device compliance, and it does not produce fuel-tax returns — if you have a legal obligation in those areas, this software does not discharge it. It also does not do fuel cards, electric-vehicle charging, dashcam video, route optimisation, carbon reporting, or automatic predictions of which part will fail next. Those were deliberately left out rather than half-built. What is here is meant to work properly.

3. The domain

Running a fleet is the business of keeping a set of expensive, mobile, legally regulated assets working, in the hands of the right people, without spending more than you have to.

Four pressures pull against each other all day:

• Service. Somebody is waiting for the vehicle to arrive.
• Cost. Fuel, tyres, parts, labour and downtime.
• Safety. How the vehicle is being driven, and whether it was fit to leave the yard this morning.
• Compliance. Vehicles are inspected, drivers are licensed, and both have to be demonstrably looked after — usually to somebody with the power to stop you trading.

The daily rhythm is familiar wherever you go. Drivers walk around their vehicle before a shift and record what they find. Vehicles go out, do work, and come back. Something goes wrong — a breakdown, a late arrival, a tyre below the legal tread. Meanwhile the odometer ticks over and services fall due whether or not anyone is watching. The job of a system like this one is to make sure nobody has to hold all of that in their head.

Two ideas run through the whole product and are worth knowing up front:

• It will not guess. When a vehicle stops reporting, it says so and withholds the position rather than showing you a stale one that looks current. A blank you understand is safer than a number you cannot trust.
• Nothing quietly disappears. A fault becomes work or becomes a recorded decision that it was not going to. An alert gets acknowledged by a named person. The record of who changed what cannot be edited by anyone, including you.

4. Where it fits

Who uses it. Typically an operations or transport manager who lives on the live screen; a workshop supervisor or mechanic who lives in the maintenance and defect lists; someone responsible for safety who reviews driver behaviour; the drivers themselves, on their phones; and an administrator who decides who can see what.

What it needs from the outside world. Position data has to come from somewhere. This platform accepts it through an open, documented submission interface rather than tying you to a particular brand of tracker — which means you are not buying hardware from whoever sold you the software, and you can change your mind later. In practice you have three options:

• A phone in the vehicle running a common free tracking app. The platform understands the reporting convention those apps use, so this works on day one with no hardware at all.
• A tracking box whose supplier can be pointed at a web address you choose. Many can.
• The built-in simulator, for trying the system out before any of the above.

Proprietary, closed tracker protocols are not implemented. If your existing boxes only speak one of those, they will need either a supplier-side forwarding option or additional work.

What it can talk to. It publishes a full programmable interface, so your other systems — a transport management system, a finance or payroll package, a yard gate, a reporting warehouse — can read from it and be notified by it. Notifications are pushed out as things happen and are signed, so the receiving system can prove the message genuinely came from your platform. You issue each connected system its own credential with only the access it needs, and every use of that credential is recorded against its own name.

There is also an optional plain-language assistant. It answers questions about your fleet from your own records — but it only works if you connect it to a language model, which you choose and supply. Nothing is sent anywhere unless you make that decision.

5. First run

The very first thing to do is sign in — because the first person who signs in becomes the administrator.

A newly installed system starts out unclaimed. It holds no operational data and will refuse to serve any until somebody claims it. Claiming happens exactly once and cannot be undone.

So make sure the first person through the door is the right person. It should be whoever will genuinely own access control for this deployment, not whoever happens to be nearest the keyboard when it comes up. Everybody who signs in afterwards arrives with no permissions at all until that administrator grants them some — which is the system working correctly, not a fault, and is worth warning your colleagues about before they try.

If you are evaluating the trial version rather than installing for real, none of this applies: it comes ready-populated with a demonstration fleet and signs you straight in. See section 10.

6. Setting up

Work through it in this order. Each step assumes the one before it.

1. Decide your structure. Your organisation is a tree — the operator at the top, then depots, regions or subsidiaries beneath it. You build this on the organisation screen. It is what controls who can see what later, so it is worth ten minutes' thought now rather than a rebuild in three months.
2. Load your fleet. Your vehicles, your drivers, and a tracking device for each vehicle. In this core build these are not typed into the screens. They are loaded through the platform's programmable interface — in practice, from the spreadsheet or system you already keep them in, by whoever is doing your installation. Once loaded they are visible and usable everywhere; it is only the initial creation that happens this way. Ask your installer to do this as part of setup, and give them your vehicle list (registration, type, current odometer and running hours) and your driver list (name, contact, licence number, class and expiry).
3. Note the device credentials. Each tracking device is issued its own credential when it is registered. It is shown once, at that moment, and never again — whoever registers the devices must capture them then. Those credentials are what the phone app or tracker uses to report in.
4. Let your people sign in. You do not create user accounts here. People appear once they have signed in for the first time, arriving with no permissions at all; an administrator then grants each of them a role on the users screen. Tell colleagues this in advance, or their first experience will be an application that appears to show them nothing.
5. Draw your places. Depots, customer sites, and anywhere you want to know about arrivals and departures. Draw them on the map with a pointer, or type in coordinates — both produce exactly the same thing, so use whichever suits how you work.
6. Write your alert rules. Start with fewer than you think you need. A queue people actually work beats a comprehensive one everybody ignores. Rules go to roles rather than to named individuals, so they keep working when somebody changes depot.
7. Set your service requirements. Define each recurring need by distance, running hours, elapsed time, or a combination. The system tracks progress from what the vehicles report.
8. Set your safety thresholds. What counts as harsh braking, harsh cornering, sustained speeding or excessive idling for your operation. A tipper on a site road is not a coach on a motorway.
9. Check your privacy and retention settings before real data starts accumulating — see section 8.

Steps 1 and 4 to 9 are all done in the application by an administrator. Steps 2 and 3 are part of installation. Setting up a real production system also has technical prerequisites and a deliberately guarded first-time procedure — whoever installs it should follow production-initialisation.md in this same folder.

7. Day to day

The operations desk. Start on the live screen. The counts across the top tell you the shape of the shift at a glance — how many are moving, idle, stopped, and how many have gone quiet. Work the alert queue: open each one, decide, and acknowledge it, which puts your name against it. Click any vehicle to see where it has been today, trip by trip, with distances and idle time.

The workshop. Two lists, most days. The maintenance list shows what is falling due or overdue, worst first, and lets you raise the job straight from the row. The defect list shows what drivers found on their checks, oldest first — because one that has been sitting three days is more urgent than one raised this morning. Each defect ends up either as a job or as a recorded decision that it did not need one. On a job you record the tasks, parts and labour as you go; completing it resets the service schedule and draws the parts down.

Safety. Weekly rather than daily for most operators. Look at the driver scores, which are adjusted for distance so somebody on long trunk runs compares fairly with somebody on short urban drops. Open anyone worth a conversation and you get the actual events behind their score, each one showing what was measured and the threshold that applied at the time — which is what turns it into a discussion rather than an argument.

Drivers. On their phones, drivers do three things: complete the walkaround check before driving, see their own trips, and read messages. The walkaround works with no signal at all — it saves on the phone and sends when there is a connection, and it is safe to close the app in between. Anything failed on a check becomes a defect on the workshop's list automatically.

8. Ongoing care

Every week or month, depending on your size:

• Run the reports. There are five: fleet utilisation, trip history, maintenance cost per vehicle, driver safety, and alert history. Each covers a date range you choose and downloads as a spreadsheet. Utilisation is the one most operators find uncomfortable and useful — it includes the vehicles that did nothing at all.
• Review the alert rules. Any rule that has fired hundreds of times and been acknowledged without action is a rule with the wrong threshold. The system flags rules that would reach nobody.
• Check what is failing to deliver. If you have connected other systems, the integration screen shows deliveries that are not getting through.

Every few months:

• Review who has access. People change jobs. The audit record shows what has actually been done, by whom.
• Check licence expiries on your drivers.
• Review your retention settings. Position data accumulates quickly. You decide how long detailed location history is kept before it is reduced or removed; keeping everything forever is a choice with both a cost and a liability attached.

Privacy. If a vehicle is used privately — a weekend, a commute, an agreed personal-use arrangement — record a privacy window for that period. During it, the driver's location is discarded before it is ever stored: not hidden, not restricted, never written down, so there is nothing for a future change of permissions to expose. Distance and running hours still accrue, so servicing stays correct. Drivers can see what is recorded about them.

Backups are your responsibility. The system keeps your data safe from being edited; it does not keep it safe from your building burning down. Whoever runs the server should be taking regular backups of the database and the stored inspection photographs, and — this is the part people skip — should have restored one at least once to prove it works.

---

9. A short glossary

Term	What it means here
Geofence	A named place, drawn as a circle or a shape, that the system can notice vehicles entering and leaving.
Trip	A worked-out period of movement, with a start, an end, a route, a distance and an idle time. Nobody types these in.
Position report	One observation of one vehicle at one moment, sent in by its phone or tracker.
Stale	A vehicle that has stopped reporting. Its last position is deliberately withheld rather than shown as current.
Alert rule	A condition you define. Alert — one occurrence of that condition being met.
Cooldown	How long a rule waits before it will fire again for the same vehicle, so one long event is one alert rather than a hundred.
Walkaround / DVIR	The check a driver makes before driving. DVIR stands for driver vehicle inspection report.
Defect	A fault a driver found on a walkaround, waiting for a decision.
Work order	One maintenance job: its tasks, parts, labour and cost.
Service requirement	A recurring maintenance need, measured in distance, hours or time.
Safety occurrence	One detected harsh-driving or idling event, attributed to a vehicle, a driver, a time and a place.
Driver score	A rating for a period, adjusted for distance covered so drivers doing different work compare fairly.
Privacy window	A period during which a driver's location is not recorded at all.
Service account	A credential given to another computer system rather than to a person.
Audit record	The permanent list of who changed what, when, and from where.
Claiming	The one-off act of the first sign-in, which makes that person the administrator.

10. The other documents here

• production-initialisation.md — for whoever installs this for real. Covers prerequisites, preparing a fresh live system, the safeguards around wiping a database, the first sign-in, and how to verify it afterwards. Technical.
• store-thumbnail.png — the listing image. Nothing to read.

There is more material outside this folder. The collateral folder holds a complete user guide and a getting-started guide, an installation and integration guide, technical and security documentation, and a set of short papers on the thinking behind particular decisions. The docs folder holds a narrated walkthrough of every screen, with pictures.

11. Who can do what

Six roles come as standard. You can create your own from the same catalogue of permissions.

Role	What it covers
Administrator	Everything, including access control and the audit record.
Fleet manager	Runs the fleet: vehicles, drivers, devices, places and alerting.
Maintenance	Service schedules, work orders, parts and defects.
Safety	Driver behaviour, safety occurrences, scores and alert review.
Driver	The in-cab views only: their own trips, checks, defects and messages.
Read only	Sees everything within their part of the organisation, changes nothing.

Roles are also limited by where somebody sits in your organisation tree. A manager at one depot sees that depot. This applies everywhere consistently — a report will not show a total worked out from records the reader could not open directly, and the plain-language assistant declines a question about another depot rather than quietly narrowing the answer.

12. The demonstration data

The trial version arrives with a complete invented operation already loaded: depots and a workshop, a dozen vehicles, ten drivers, named places, service schedules, work orders, completed inspections with photographs, and a day of tracking with the trips, alerts and safety events worked out from it. Every screen is populated, so you can judge the software rather than stare at empty tables.

None of it is real, and none of it is yours. Break it freely — by default nothing survives restarting the trial, and you are back to a clean demonstration.

To start fresh with your own data, you do not clean out the demonstration — you install the real thing. That is a separate procedure with its own safeguards, and it is what production-initialisation.md is for.

One thing that surprises people: the demonstration's tracking data was recorded when the trial package was built, so after the trial has been running a while the vehicles stop reporting and correctly show as stale. That is the software being honest about old data, not a fault.

13. Common questions

Do I have to buy your tracking hardware? No, and there isn't any. A phone running a common free tracking app will report into it. So will many tracker boxes, if their supplier lets you choose the address they report to.

Does this keep me legal on drivers' hours or tachographs? No. It has no hours-of-service, electronic logging or fuel-tax capability, and you should not treat it as covering any of those obligations.

Can I run several customers' fleets from one copy? No. One operator per installation, with as many depots as you like inside it.

Where does my data live? Wherever you install it. This is self-hosted software: you hold the database.

I've bought a new lorry. Where do I add it? Not on the screens — not in this core build. Vehicles, drivers and tracking devices are created through the platform's programmable interface, so adding one is a small job for whoever supports your installation. Everything you do with a vehicle afterwards is on the screens as normal.

Somebody signed in and can't see anything. Is it broken? No. New people arrive with no access until an administrator grants some. That is deliberate.

A vehicle shows no position. Where has it gone? It has stopped reporting — flat battery, no coverage, unplugged, or switched off. The system withholds the old position on purpose rather than showing you where it was six hours ago as if it were now.

Can I delete an audit entry? No. Nobody can, including administrators. Entries leave only when their retention period runs out, and that expiry is itself recorded.

Can I change how it looks and add what's missing? Yes — that is rather the point. See below.

14. Where to get help

This application was built end to end by artificial intelligence, and what you have is deliberately the core: the working machinery, without company styling or branding. It is meant to be taken and made yours — your colours, your terminology, your rules, and whatever else your operation needs that is not here yet.

If you know this industry and you are comfortable with AI tools, that is work you can do yourself. If you would rather someone did it for you, go to wbsp.ai, where you will find people who can, and a community that has built many versions of this application and a great many others besides. One of them may already be closer to what you need than this one.

It is also the place to suggest what this should do next.