Handbook

Appearance

The Fleet App ​

What this chapter covers ​

The fleet app at app.korido.net is the web command center for a trucking company on the Douala-N'Djamena corridor. This chapter describes who uses it, the surfaces it gives a dispatcher or owner — live map, vehicle diary, mission creation and tracking, the fuel dashboard, the alerts center, and the fleet overview — and the deliberate lines the app does not cross.

Who it is for ​

The fleet app is the daily operating tool for the people who run a fleet: the owner and the dispatchers working on the owner's behalf. Only the owner role enters the app shell; a Korido support operator may enter through a short-lived impersonation handoff, but they see the tenant's own data through the tenant's session, never a cross-tenant view. Drivers do not use the web app — their surface is the driver app. Customers never see it at all; they get a scoped tracking link.

The app is built around an operating rhythm: every screen exists to help answer the questions asked while trucks are moving.

The fleet overview ​

The landing surface is a command center: it leads with fleet attention, then geography, then the work queue:

  1. A metric strip that makes fleet health scannable at a glance — active missions, open alerts, and the moving / stopped / offline split.
  2. A live fleet map as the main visual surface.
  3. Side panels (on desktop) or panel sheets (on mobile) for missions, alerts, and recent activity — the queue of things that need acknowledgement, investigation, or a phone call.

Live dashboards refresh on a modest 30-second cadence. That is a deliberate compromise: recent enough for dispatch decisions, but not a real-time animation system that would burn battery and bandwidth on metered corridor connections.

The live map ​

The live map is a first-class workspace: it owns vehicle selection (backed by the URL so a view can be shared or reloaded), the fleet list, and a selected-vehicle detail panel with tabs for the current trip, vehicle identity, diagnostic telemetry, and alerts. Where the driver's phone number is known, the panel offers a one-tap call.

The map's core job is to show each vehicle in a state a dispatcher can trust. Each vehicle carries a display state derived from its latest signal:

Display contract

The web app, owner app, and tracking portal all read from the same liveness contract. Differences between surfaces are privacy and wording choices, not separate state machines.

Three of these states are the ones that make corridor tracking honest, and the app names them plainly:

  • "Stationné — dernière position connue" — the truck is parked. Corridor trackers stop sending GPS fixes while a truck sleeps, so a fresh heartbeat with the ignition off and a known position means the truck is simply parked where it was last seen. While the last heartbeat stays fresh — within roughly 2 hours — this reads as confidently parked; if the tracker is alive but cannot reconfirm its fix, the map shades the same parked state amber to flag that the position may be stale. Once the heartbeat itself goes quiet, the truck reads as offline instead.
  • "Sans GPS" — the tracker is alive and talking, but it cannot get a satellite fix. This is a real, distinct condition, separate from a parked truck and separate from a truck that has gone silent.
  • "Hors service" — the tracker has stopped reporting entirely; there is an open signal gap.

A vehicle that has never produced a position still appears in lists and summaries; it simply cannot be placed on the map. Missing position, stale signal, and offline are treated as meaningful states, never as rendering errors. The liveness rules behind these labels are the subject of Part 2 — Telemetry; the gaps that drive "Hors service" and "Sans GPS" come from Part 3 — The fleet engine.

The vehicle diary ​

The vehicle diary is the evidence layer — where an owner reconstructs what a truck actually did on a given day, and the answer to any dispute about delay, fuel, route, or driver activity. Its power is the pairing of a map trail with a time-ordered story: trips, stops, signal gaps, fuel events, waypoint visits, and Route Guard deviations only tell a coherent story when time and geography are visible together.

The diary offers day, week, and calendar views. Today's view refreshes more often than historical review, which polls position history about once a minute. The workspace carries a KPI strip for the chosen period, a split map-and-timeline layout on desktop (a toggle on mobile), a replay panel that scrubs the day's telemetry — speed, fuel, engine, coolant, altitude, GSM — and story filters.

The diary is allowed to interpret, but only from telemetry and explicit rules. A signal gap that overlaps an authorized stop reads differently from an unexplained offline stretch, and when a gap has been classified, the reason is discoverable in the story. The diary never invents a timeline row the engine did not produce.

Missions: quick-assign and tracking ​

Creating a mission is meant to be fast, because corridor work is repetitive. The app uses a guided wizard whose central move is quick-assign: the operator supplies the few facts only a human knows, and the wizard fills in everything it can infer from them.

The pivotal inference is the corridor: once the operator picks an origin and destination, Korido recognises the named corridor that connects them and suggests it, so Route Guard coverage attaches without anyone drawing geometry. Around that, a known client fills in reusable pickup and delivery locations, scored recommendations propose a driver, vehicle, and trailer from past trips, and a template or a cloned mission hydrates the whole plan at once. For a one-off haul, the operator drops ad-hoc pins on the map instead. The wizard also offers a Règles de conduite (driving policy) selector, so an operator can attach an explicit set of driving rules — speed, night driving, authorized stops — to the mission, or let it inherit the tenant's default.

The owner UI collects intent, but the server owns mission authority. It rejects a mission for a vehicle that already has an active one — regardless of which driver is assigned — with a friendly validation message rather than a raw error, computes the planned distance from the waypoints itself (operators never type a distance), unions the selected corridor segments into a Route Guard polygon, and enriches ETA and predictions after the mission is safely created. The mission creation flow is covered in depth in Part 5 — Missions.

Mission detail is the bridge between the plan and the evidence: it shows the planned route and cargo alongside the predicted ETA, the waypoint sequence with per-leg predictions, observed visits, and the measured segments. Lifecycle actions — force-start, pause, resume, complete, cancel — are offered strictly by the mission's current status, so an operator cannot skip an evidence-producing state just because a button exists.

Customer tracking is managed from here too. An owner generates a per-mission link, sets its expiry, copies or shares it over WhatsApp, watches its access count, and revokes it — all without granting the customer any view of the dashboard. What the customer then sees is the tracking portal.

The fuel dashboard ​

Fuel is operational evidence. The fuel surfaces present a tank gauge for current level, a stream of fuel events — refuels and drops detected by the sensor, joined with driver-submitted receipts where the mobile app captured them — and rankings that surface the vehicles or drivers worth a closer look over a rolling window. A vehicle-specific view drills into one truck's history.

The framing is deliberate: a good fuel workflow separates sensor confidence, receipt timing, and expected consumption before anyone calls a discrepancy fraud. The detection rules that produce these events live in Part 3 — The fleet engine.

The alerts center ​

The alerts center is a triage queue over vehicle events. Each row carries a severity indicator, the event type, the vehicle reference, and a relative time, and moves through open, investigating, and action-taken states as an operator acknowledges and resolves it. The open-alert count feeds the shell and the fleet overview's attention model.

The alerts center is a triage surface. It shows which events fired and lets an operator work them; it does not claim to monitor WhatsApp delivery, group recurrences, or manage escalation policy. How alerts are raised and delivered is the subject of Part 6 — Fleet intelligence and the WhatsApp channel.

The document review center ​

The paperwork drivers capture on the road lands in a document review center — a filterable list of every uploaded document beside a preview-and-decision panel. An owner filters by category, status, or the mission, vehicle, or driver a document belongs to, opens the photo with its metadata, and records one of three decisions: "Valider", "À corriger", or "Rejeter". A correction or rejection sends the driver a directed retake request; a validation simply confirms the document. The full capture-to-review lifecycle, its statuses, and the retake loop are the subject of Part 5 — Documents.

The boundaries of this surface ​

The fleet app is powerful because it is narrow. Its deliberate limits are part of the design:

  • Corridors are curated in the admin portal. An owner selects Route Guard coverage for a mission, but the shared waypoints, road segments, and named corridors are curated in the admin portal. This keeps route intelligence consistent across every tenant.
  • The phone is never fleet truth. Backend position comes only from the hardware tracker through the telemetry pipeline. A driver's phone GPS is display-only on their own app and is never synced into the fleet the owner sees.
  • Planned distance and corridor geometry are server-authoritative. The UI previews and guides; it never becomes the source of truth for distance, lifecycle state, or coverage.
  • Partial modules stay honest. Directions like maintenance and richer reporting appear only where real data flows exist. A disabled nav entry is preferred over a placeholder page that implies a guarantee the system does not yet make.

How it connects ​