Module B
Work the layers, top down
Pick what the customer said. Rule each check out as you go — the case note on the right writes itself. Faults live near the top of this list far more often than the bottom, so resist jumping to the device.
The layer model
| # | Layer | First place to look |
|---|---|---|
| 1 | Access & rights | Failed Login Attempts, Blocked Users, Disabled Users → then the user's rights |
| 2 | Contract & modules | Is the module on the contract? Menu actions depend on it — a missing button is usually this, not a bug |
| 3 | Interface & filters | List filters, group selection, columns, date range |
| 4 | Object config | Object card, tariff, device ID/type, temporary blocking |
| 5 | Sensor config | Field mapping → conversion formula → calibration table, in that order |
| 6 | Device & data | Sensors tracing, satellite count, Connection Lost, Devices offline |
| 7 | Relay | Statistics: Queue, Err, Send, Ack |
Affects everything → 1–2. One object → 4–6. One screen → 3. Fine here, missing downstream → 7.
“It works for me” proves nothing
Support logins carry far more rights than the customer's. A large share of rights cases are invisible from your session. Reproduce as the user, or read that user's rights directly.
Fix the config, then fix the history
Correcting a formula or calibration table only changes new data. Yesterday's report stays wrong until you run Recalculate for the affected period. Saying “fixed” without it earns a callback.
When to stop
All applicable layers worked and nothing found · the fix needs rights you don't have · more than one customer is reporting it, which makes it an incident, not a ticket.
Module A
Get facts, not the story
The customer reports a symptom. You need facts. Work the ladder top to bottom — scope first, because scope is what tells you which layer to start on.
| Ask for | Say something like |
|---|---|
| Scope | “Is it this one vehicle, or all of them?” |
| Timeline | “When did you last see it working? Did anything change around then?” Then check Audit history rather than taking “nothing changed” at face value. |
| Reproduce | “Can you open the list right now and tell me what you see next to the vehicle name?” |
| Identity | “Which login are you using? What's the object name or IMEI?” |
| Expectation | “What number were you expecting to see there?” |
Ask open, then narrow
“Tell me what you're seeing.” — lets them describe reality.
“Is the ignition sensor configured?” — makes them answer your theory instead.
Difficult moments
They're angry
Let them finish. Don't defend the product mid-sentence.
“You've had no tracking on that vehicle for two days — I understand why that's a problem.”
“I understand you're frustrated.” — reads as scripted. Acknowledge the impact, not the emotion.
You don't know
“I don't know yet. I'm going to check with [team] and come back to you by [time].”
Never guess out loud. A wrong guess from support becomes a fact in the customer's head.
It's their fault
Never say so. Say what fixes it.
“The notification's time window was set to weekdays only — let's widen that now, and I'll show you where it lives.”
The answer is no
State the no, the reason, and the nearest alternative.
“That action isn't available because the module isn't on your contract. What I can do is…”
You need a minute
Silence reads as incompetence. Narrate instead.
“I'm opening Sensors tracing to see what the device actually sent — give me about a minute.”
Module D
Classify before you queue
Three kinds of ticket, not one. They have different owners, different clocks, and different definitions of done.
| Type | Means | Done when |
|---|---|---|
| Incident | Something is broken. Unplanned interruption or degradation. | Service restored — not necessarily explained. |
| Service request | Something is wanted. Nothing is broken. Module activation, tokens, new users, tariff changes. | Delivered via a standard, approved path. |
| Problem | The cause behind repeated incidents. Same symptom three times = this. | Cause removed, or written up as a known error. |
Priority = impact × urgency
Not who shouts loudest. Tap a cell to set it on the case note.
The telematics twist
Some of this data has a physical clock attached. Refrigerated cargo spoils. A stolen vehicle moves. A reporting window closes. Ask: what happens in the real world while this stays broken? A sensor fault that looks like P4 on a reefer trailer is a P2.
Write it down while you solve it
Title the article in the customer's words — “fuel gauge shows zero”, not “sensor field mapping mismatch”. The next person searching is a customer or a new hire, and neither knows your vocabulary.
Module C
Hand over cleanly
Escalating early with good notes is better work than sitting on a ticket for a day. The expensive habit in 1st line is over-holding, not over-escalating.
Before you send it
The test: could the next engineer start work without asking you a single question? Your case note should already carry the customer and contract, the object or IMEI, the exact symptom with timestamps, what Sensors tracing showed, what Audit history showed, what you ruled out, and what the customer has been told.
Who owns what
| Team | Send them |
|---|---|
| 2nd line | Anything where you've worked every applicable layer and found nothing |
| Development | Reproducible bugs — not configuration questions |
| Installers | Device never reported, wiring, repeated drops at the same location |
| Integrations | Layer 7: endpoints, Queue/Err/Ack, external systems |
| Sales | Tariff, upgrades, module activation, anything commercial |
| Finance | Payments, debits, blocked for non-payment |
The owns boundaries above are the common telematics-desk defaults; the specific names, channels and triggers are company-specific — confirm them from the prep list. Default rule for anything you can't route yourself: contact your head of technical support.
Stop and route, don't help
A driver asking what data is held on them, or asking for it deleted, is a data-subject request with a legal clock — not a normal ticket.
A manager asking where a named driver was on Saturday puts you inside an employment dispute. They may well be entitled to it; you are not the person who decides that.
Deleting an object destroys its history and can't be undone. Never action a deletion from a phone call alone.
Several customers, same symptom
That's an incident, not a ticket. Escalate immediately to your head of technical support (or the on-call / incident contact) and stop debugging.