Feature · Issue tracking
Issue tracking your shop can actually run on the radio.
Sequential per-tenant issue numbers like ISS-000042 you can call out by voice. Priority. Dual-axis due — calendar AND meter. Photo attachments. Resolution that links straight to the work order that closed it.
app.fleetservice365.com/issues/ISS-000042
ISS-000042
High priority
In progress
SLA · at risk
Brake squeal above 40 mph · front pads suspect
TRK-17 · F-250 · reported Apr 12, 2026 · 06:42
Due · date
Apr 17, 2026
5 days remaining
Due · meter
84,500 mi
@ odometer · TRK-17
Reported @
82,417 mi
odometer at report
Notes · append-only
3 events · since Apr 12
REPORTED
Apr 12 · 06:42
Brake squeal above 40 mph on TRK-17. Worse cold; fades after 5 mi. Audible from cab.
2 photos · azure blob · SAS
PROGRESS
Apr 12 · 09:15
Triaged High. Pulled into bay 2 after route. Pads measured 2/32 LF, 3/32 RF — replacing front set.
PROGRESS
Apr 13 · 14:02
WO-1042 opened · BP-FA-D2 (×1 set), labor 1.4 hr scheduled. Linked to this issue.
WO-1042 · linked
Closes automatically when WO-1042 saves
resolution required · 5 types
What’s broken today
Issue trackers built for software don’t survive the shop floor.
01
“What’s the issue number again?”
Saying f7-a3-c2-9b over a radio is impossible. UUID issue IDs are useless in operations — your dispatcher can’t read it, your tech can’t pull it up, and your shop foreman gave up after the third try.
02
Editable comments = no audit trail.
When you can edit history, you can rewrite history. Insurance auditors and DOT inspectors don’t accept “trust us, this is what happened” — they want an append-only log that proves what was said when.
03
The same defect, over and over.
Without recurring-issue detection, your shop keeps fixing the same brake squeal on the same truck every two months because nobody connects the dots between three separate work orders.
What’s behind it
Shipped today
Eight pieces. Each does one job, and admits what it doesn’t do.
Watchers and an escalation engine are v2. OBD ingestion is v2. VMRS-clustered recurring-fault detection is v2. Everything below is in the product today.
Per-tenant sequential numbers
ISS-000042. Each tenant starts at 1 and advances independently. Human-readable, sayable over a radio, allocated atomically inside the insert transaction.
ISS-000042
Priority + SLA chip
Critical / High / Medium / Low. A client-side SLA chip (red / yellow / green) computed from priority + age in status. No escalation engine in v1 — but the chip is honest.
priority · age_in_status
Dual-axis due
Calendar date AND meter reading. Both reported and due meter readings are scoped to a single meter_id — pair-checked in the database.
due_at · due_meter
Status lifecycle
Open → InProgress → Resolved | Cancelled, with Resolved → Reopened back into the active loop. Transitions are explicit, not free-text.
status_transition
Append-only notes
Three note types: Progress, Resolution, Reopen. Inserts only — never overwrites. Insurance auditors and DOT inspectors get a clean immutable record.
issue_note · INSERT only
Structured resolution
Required at resolve time. RepairedInHouse / RepairedByVendor / NoFaultFound / Duplicate / Cancelled. Drives clean MTTR and root-cause reporting.
resolution_type · 5 enum
Photo & attachment uploads
Direct to Azure Blob via short-lived SAS URLs. Driver photographs the defect from the cab, foreman sees it before the truck pulls in. No file size theatre.
azure blob · SAS URL
Related open issues panel
On every issue detail view: up to 10 other open issues on the same asset. The cheapest recurring-fault detection ever shipped — no ML, no clustering.
/issues/:id · side panel
Status lifecycle
Four states. One loop back. No free-text status field.
Status is an enum, not a notes field. Reopen is its own transition — it inserts a Reopen note and routes back through InProgress with the full prior history intact.
Open
triage→
InProgress
WO saves→
Resolved
reopen↩
Reopened
→ routes back to InProgress
also from Open / InProgress→
Cancelled
Deep dive · 01
Shipped
Dual-axis due — calendar AND meter, pair-checked at the database.
Fleetio only lets you set a calendar due. Samsara only meter. We let you set both, on the same specific meter, with a database constraint that prevents a bare “500” from meaning either odometer OR reefer hours. Multi-meter assets stay coherent.
- Two axes, one issue. due_at is a calendar date. due_meter is a meter reading. Either one tripping fires the SLA chip — whichever comes first wins.
- Meter_id, not “miles.” A reefer tractor has an odometer AND a refrigeration-unit hour meter. “Due at 500” is meaningless until you say which meter. We require it, and the database enforces it.
- Pair-checked. The reported meter and the due meter must be the same meter_id — enforced by a CHECK constraint. You can’t report a problem at odo 82,000 and set the due against reefer hours.
- Monotonic. due_meter > reported_meter at the database. No “due 100 miles ago” data quirks.
- SLA chip reflects both axes. Red if either dimension is breached, yellow if either is within 20% of breach, green otherwise. Honest from the second the row is inserted.
DUE · DUAL-AXIS
ISS-000042 · pair-checked at the database
Calendar · Apr 12 → Apr 17
5d remaining
Apr 12
now
Apr 17 · due
Meter · odometer · meter_id TRK-17-ODO
2,083 mi left
82,417 mi
84,500 mi · due
DB constraint
CHECK ( reported_meter_id = due_meter_id AND due_meter > reported_meter )
No ambiguous “due at 500” on a reefer tractor. The reported and due meters must be the same meter on the same asset.
SIDE PANEL · ISS-000042
Related open issues on TRK-17
ISS-000038
High
Alternator whine at idle
ISS-000031
Medium
Battery slow to start · cold
ISS-000027
High
Alternator output low · 13.2V
ISS-000019
Low
Trailer marker light intermittent
ISS-000012
Medium
Alternator belt squeal · cold
ISS-000007
Low
Cab dome light flickering
SELECT id, title, priority, age FROM issues WHERE asset_id = $1 AND status IN (Open, InProgress)
no ML · no clustering · just a query
Deep dive · 02
Shipped
“Related open issues on this asset” — the cheapest recurring-fault detection ever shipped.
The side panel on every issue detail lists up to 10 other open issues on the same asset. No ML, no clustering — just a query the data already supports. Patterns become obvious in seconds.
- One query. No model. WHERE asset_id = $1 AND status IN (Open, InProgress) — the data was already there, we just put it on the screen.
- Right where the eyeballs are. The panel lives on the issue detail view — the page a shop manager already has open while they’re thinking about the truck.
- Patterns surface to the human. “Three of the last six mention the alternator” is something a person spots in 10 seconds. No NLP needed.
- What’s on the roadmap. Cross-asset clustering with VMRS codes is V2. The v1 panel is “open issues on this asset” — a real wedge, today.
- Honest framing. We don’t claim ML. We don’t claim “AI insights.” We claim that putting six rows of related context next to the issue you’re looking at is the highest-leverage UI move in the whole module.
Compare
Fleet Service 365 vs. Fleetio.
Where issue tracking diverges — and why the difference matters the first time a dispatcher reads an issue number over the radio, or an auditor asks for the original note.
| Capability | Fleet Service 365 | Fleetio |
|---|---|---|
| Sequential per-tenant issue number | ✓ISS-000042 | UUID-style |
| Dual-axis due (date + meter) | ✓ | Date only |
| Append-only notes | ✓ | Editable |
| Structured resolution type | ✓5 categories | Free-text |
| “Related open issues on this asset” panel | ✓ | ✗ |
| SLA chip from priority + age | ✓ | ✗ |
| Photo attachments | ✓ | ✓ |
| Closes via Work Order in one transaction | ✓ | ✓ |
See full Fleetio comparison →
Comparison based on publicly listed Fleetio capabilities as of May 2026.
Use cases
Three roles, one issue record.
Dispatch · radio
“ISS-42 on Truck 17, brakes squealing above 40 mph.”
A dispatcher relays it from the cab over the radio. The technician opens it from the dashboard in two clicks. No “spell that for me” — sequential per-tenant numbers are sayable, typeable, and unique.
Shop · root cause
Three alternator complaints in nine weeks.
A shop manager opens ISS-42 and the “Related open issues” side panel surfaces three other open complaints mentioning the alternator on the same truck. Diagnostic root cause becomes obvious — fix the alternator, not the symptom.
Director · MTTR
Mean-time-to-resolve, sliced by priority.
A fleet director pulls an MTTR report: resolved_at − reported_at across resolved issues, sliced by priority. Honest numbers, because Critical / High / Medium / Low is an enum — not a free-text “urgency” field that means whatever the last person typed.
FAQ
Questions we hear a lot.
How do issue numbers work — are they really sequential per company?
Yes. Each tenant has its own counter starting at 1, formatted as ISS-000042. The number is allocated atomically inside the insert transaction — no gaps from optimistic concurrency, no collisions, no UUIDs. Your dispatcher can say it over a radio and your tech can type it from memory.
Can I attach a photo of the defect?
Yes. Upload goes direct to Azure Blob via a short-lived SAS URL — your browser PUTs the file straight to storage, not through our app servers. The driver can photograph a sidewall cut from the cab, the foreman sees it on the issue before the truck rolls into the bay. Multiple photos per issue, multiple per note.
What happens when I save the work order — does the issue close automatically?
When you save the work order that resolves an issue, the issue’s status transitions to Resolved in the same database transaction. A Resolution note is inserted, the resolution type (RepairedInHouse / RepairedByVendor / NoFaultFound / Duplicate / Cancelled) is recorded, and resolved_at is stamped. One transaction, no half-saved states.
Can I reopen an issue after it’s been resolved?
Yes. Resolved → Reopened is an explicit transition. A Reopen note is required — the immutable record now shows who reopened, when, and why. The issue lands back in the active loop (InProgress) with its full prior history intact. Nothing is overwritten.
How does the dual-axis due work — date AND meter?
You set a calendar date and / or a meter reading on a specific meter_id. Both reported and due meter readings must reference the same meter_id (enforced by a CHECK constraint), and due_meter must be greater than reported_meter. Either axis tripping fires the SLA chip — whichever comes first wins. Multi-meter assets (a reefer tractor with an odometer AND refrigeration hours) stay coherent.
Can I delete an old issue?
No. The notes log is append-only by design — that’s the audit trail insurance auditors and DOT inspectors actually accept. The issue itself can be Cancelled (a real transition with a Resolution note) but the row stays. If you need an issue to disappear from default views, the dashboards filter by status — Cancelled drops out of the open queue.
Can my drivers report issues from the field?
Yes. A driver-scoped role can create issues against assets they’re assigned to, attach photos from the device camera, and add Progress notes. They can’t resolve, reopen, or edit prior notes — those permissions live with foreman and shop manager roles. Field-reported issues land in the same queue, with the same sequential number, as anything reported from the shop.
More to explore
Related features.
Sayable numbers. Honest SLA. Append-only history.
14-day free trial. No credit card. A seeded ISS-000042 already in your trial tenant with three retreads of notes and the related-issues panel populated — see exactly what an audit-grade issue timeline looks like.