[ Case study ]Fleet Telematics

    Fleet Telematics · Control Room Console

    A new console for a fleet telematics control room. It turns a flood of raw telemetry into one ranked board of what needs a person's attention now, with every alert on an SLA clock.

    • Claude Code delivery
    • Built in two months

    A feed, not a working view

    The problem

    A fleet telematics provider runs a control room that manages roughly 3,500 tracking devices. Its old board showed every raw telemetry event as an identical card, with no filtering or prioritisation, so operators had to sort the urgent from the background noise themselves. A tamper alert or an off-route vehicle looked exactly like routine telemetry, which meant a real issue could get lost and not be acted on in time. The client had wanted a proper console for a long time but never had the internal resources to build it.

    Four problems, one working board

    What we solved

    Only what needs action, ranked by urgency

    The Console groups raw events into alerts across three SLA tiers, and the working board shows only those alerts. The old raw feed is still there as a separate Events tab for reference.

    Every alert on a clock

    Each alert carries a live countdown to its SLA deadline and an escalation trail, so operators see what is about to breach before it does.

    Incidents tied to the trip

    Any operator, at any tier, can generate an incident with a date, time and comment. It attaches to every alert on that trip, including ones already resolved.

    Access the client already knows how to run

    Instead of the six-role model first proposed, access comes down to two permission flags, View Dashboards and Manage Dashboards, which the client sets in the portal it already runs. There's no new admin screen to build or learn.

    A single alert card with a live SLA countdown and escalate, resolve, generate incident and hold actions
    The Generate incident dialog recording an incident against a trip, beside an expanded alert showing contacts

    What changed for the client

    Results
    • 01

      Operators open one board that shows only what needs action, ranked by urgency. They no longer triage a scroll of telemetry by hand.

    • 02

      Each incident is recorded against the trip it happened on, alongside the rest of that trip's activity.

    • 03

      The client manages who can do what in the portal it already uses.

    • 04

      The client finally has the console it had wanted for a long time. It was built in two months and opens a new vertical for them.

    How it was built

    Behind the build

    Typed from day one, re-pointed to go live

    A Vue 3 and TypeScript console built behind typed interfaces, with a full mock estate standing in for the client's live API until cutover. Going live meant re-pointing it at the real API, with nothing to rebuild. Three views cover the live Console, a full history List and the raw Events feed.

    Embedded in the portal they already use

    The console runs inside the client's existing portal and signs in through a secure token handoff, so there's no second login. Tokens refresh in memory and never touch browser storage.

    Built end to end with Claude Code

    riivo's first engagement delivered on a Claude Code model: build, independent review, then supervisor sign-off at four checkpoints.

    Ready to give your control room a working view?

    Let's discuss how we can deliver similar results for you.