PILOT training programme — supplement

Support Skills Module

Communication · Troubleshooting methodology · Escalation workflows · Industry standard practice

Goal. To complement the existing product training (PILOT platform, 2 weeks / Admin panel, 3 days) with the practical skills a 1st-line support engineer needs to handle a real customer case from first contact to resolution or handover.

Format. Four modules. Each can be delivered as a standalone block or woven into the existing day-by-day plan — see Integration options.

Revision 4. Modules A–D are a supplement. The two existing training plans are internal, authoritative, and correct — no flow, step, sequence or terminology from them has been altered or contradicted here. Everything below is additive.

Module A · Communication with customers

Goal. The engineer can run a support conversation that gets the information needed, sets accurate expectations, and leaves the customer feeling handled — even when the answer is "no" or "not yet."

A1. The anatomy of a support contact

• The four phases: Acknowledge → Diagnose → Act → Close. Most bad support calls fail because the engineer skips straight to Act.
• Acknowledge: restate the problem in your own words before touching the system. It proves you listened, and catches misunderstandings in the first 30 seconds instead of the twentieth minute.
• Close: never end without three things stated out loud — what was done, what happens next, and who does it.

A2. Asking the right diagnostic questions

This is the core skill. The customer reports a symptom; the engineer needs facts. Work the ladder top to bottom, never skip:

Key principle: ask open, then narrow. Start with "Tell me what you're seeing" (open), not "Is the ignition sensor configured?" (narrow). A narrow first question makes the customer answer your theory instead of describing their reality.

Anti-patterns to train out

• Leading the witness — "So the device is offline, right?" The customer will agree just to move on.
• The jargon wall — "Have you checked the contract-level module activation?" Ask instead: "Let me check something on my side."
• Assuming rights — the customer says "the object disappeared." It may never have been theirs to see. Verify before you believe.

A3. Difficult conversations

• The customer is angry. Let them finish. Do not defend the product mid-sentence. Then acknowledge the impact ("You've had no tracking on that vehicle for two days — I understand why that's a problem"), not the emotion ("I understand you're frustrated," which reads as scripted).
• You don't know the answer. Say so plainly and commit to a next step and a time. "I don't know yet. I'm going to check with our 2nd-line support team (or your head of technical support if you're not sure who owns it) and come back to you by [timeframe]." Never guess out loud — a wrong guess from support becomes a fact in the customer's head.
• It's the customer's fault. Never say that. Say what will fix 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…"
• Buying time. Silence on a call reads as incompetence. Narrate: "I'm opening Sensors tracing now to see what the device actually sent — give me about a minute."

A4. Writing it down

Tickets are read by people who weren't on the call — a 2nd-line engineer, or you in three weeks. A usable ticket note contains:

1. What the customer reported (their words)
2. What you verified (facts, with object names / IMEI / login / timestamps)
3. What you ruled out and how
4. What you did
5. What's outstanding and who owns it

Most telematics desks run on a helpdesk platform such as Jira Service Management, Zendesk or Freshdesk (PILOT's own vendor portal at helpdesk.pilot-gps.com is Jira Service Management). At minimum a ticket carries: customer / contract, object name or IMEI, category (Incident / Service request / Problem — see D1), priority (P1–P5 — see D2), channel, and the customer's own words. Confirm your desk's exact system and required fields with your head of technical support.

Module A assignments

1. Question drill. Trainer gives a one-line symptom ("My reports are empty"). Trainee produces five questions before proposing any cause. Repeat with four different symptoms.
2. Rewrite the jargon. Take five sentences from the PILOT manual and rewrite each for a non-technical fleet manager.
3. Role-play: the angry customer. Trainer plays a customer whose vehicle showed no data all weekend. Trainee runs the full Acknowledge → Diagnose → Act → Close cycle.
4. Role-play: the "no". Customer wants a feature not on their tariff. Trainee delivers the no and the alternative.
5. Ticket writing. Write up role-play 3 to the five-point standard above. Trainer grades on whether a colleague could pick it up cold.

Module B · Troubleshooting methodology

Goal. The engineer diagnoses by elimination against a known model of the system, using PILOT's own diagnostic tools, rather than guessing from memory.

B1. Three instruments, learned before anything else

PILOT ships with three tools that answer the three questions almost every case turns on. A trainee who knows only these three is already more useful than one who has memorised every menu.

B2. The layer model: work top-down

Almost every PILOT issue lives in one of seven layers. Faults are far more common at the top of this list than the bottom — but engineers instinctively reach for the bottom ("must be the device"). Always check top-down.

Rule of thumb: affects everything → layers 1–2. Affects one object → 4–6. Affects one screen → layer 3. Fine in PILOT but missing downstream → layer 7. Scope tells you where to start; that's why the Scope question in Module A comes first.

B3. The method

1. Reproduce or observe. Do not diagnose a story. Get to the screen — via the customer's description, a screenshot, or a test account.
2. Establish scope. One object / one user / everything. This selects your layer.
3. Bisect. Cut the problem in half. Does another user see it? Does another object have it? Did it work yesterday? Every answer halves the search space.
4. Change one thing at a time. Two changes at once means you learn nothing from the result.
5. Fix the config — then fix the history. Correcting a formula or calibration table changes new data only. Historical reports stay wrong until you run Recalculate (specify the agent, choose the recalculation type, set the period, run, then re-check the report). Telling a customer "fixed" without recalculating guarantees a callback.
6. Confirm the fix with the customer, not with yourself. "Refresh and tell me what you see now."
7. Record the cause, not just the fix. Write it up as a KCS article in the team knowledge base (see D3) — the helpdesk's linked knowledge base, or PILOT's own FAQ / uploaded-documents area. If no store exists yet, your head of technical support can point you to where known issues live.

B4. Worked diagnostic trees

These sit behind the four scenarios already in Day 11–12 of the support plan — same scenarios, with the diagnostic order made explicit. Each is ordered so the cheapest, most common cause is checked first.

B5. Layer 7: data reaching PILOT but not the customer's own system

Customers who relay data to an external system (their own ERP, a municipal platform, a partner) produce a distinct class of ticket: the data is correct in PILOT and missing downstream. It is not diagnosable with any of the layers above, and it is the one area where the public guide has a troubleshooting page of its own.

Start at Admin → Statistics and read four metrics:

Documented best practice: one endpoint per external system; configure Auto add when every new object in a contract should relay to the same place; before deleting an endpoint, check how many objects depend on it; and when troubleshooting, always start from Statistics.

B6. When to stop

1st line's job is not to solve everything — it's to solve the known and cleanly hand over the unknown. Teach the stop conditions explicitly:

• You've worked all applicable layers and found nothing.
• The fix requires access or rights you don't have.
• It's affecting multiple customers → this is an incident, not a ticket. Escalate immediately, don't keep debugging.
• A common default: stop and escalate after about 30 minutes of investigation with no meaningful progress on a P1/P2 (proportionally longer for lower-priority tickets). Escalate to your head of technical support with the handover from C3 — a clean early handover beats sitting on a ticket.

Module B assignments

1. Instrument drill. Open Sensors tracing on a live object and read out the last reception time, satellite count, and one sensor value. Then find the same object's last settings change in Audit history. Repeat until it takes under a minute.
2. Layer sorting. Trainer lists 15 symptoms; trainee assigns each to a layer and names the first check. Speed matters — this should become reflex.
3. Broken sandbox. Trainer breaks 6 things in the test environment in advance: block a user, deactivate a module, set a wrong sensor formula, apply a hidden list filter, mismatch an IMEI, and switch on Temporary blocking for one object. Trainee diagnoses each without being told the category. This is the single highest-value exercise in the module.
4. The Master trap. Trainer restricts a test user's rights to one object. Trainee — logged in with support rights — must explain why the customer can't see the other vehicles, without ever having seen the problem themselves.
5. Notification hunt. Trainer configures a notification with a weekday-only time window, then reports "no alerts at the weekend." Trainee finds it.
6. Recalculate drill. Fix a wrong calibration table, then make yesterday's report correct. Trainee must realise the second step is needed without being prompted.
7. Write a tree. Trainee produces their own diagnostic tree for a symptom not covered above, and defends the order of checks.

Module C · Real support workflows and escalation

Goal. The engineer knows what happens to a ticket, who owns what, and when to let go of it.

C1. The lifecycle of a request

• Channels a request can arrive on: phone, email and a self-service helpdesk portal are the industry norm; many telematics desks also take WhatsApp and partner-relayed requests. Whatever the channel, every request becomes a ticket.
• Logging: what must be created, and when. Raise a ticket for every contact at the moment of contact — never work off memory or a chat thread. Minimum fields: customer / contract, object / IMEI, symptom in the customer's words, channel, and priority.
• Priority definitions and target response times. Common telematics SLA defaults: P1 respond ≤15 min / restore ≤4 h; P2 ≤1 h / ≤8 h; P3 ≤4 h / ≤2 business days; P4 ≤1 business day / ≤5 days; P5 best-effort. Priority itself comes from the D2 matrix. Confirm your contractual SLAs with your head of technical support.
• Status meanings and who is allowed to close a ticket. Standard lifecycle: New → Open / In progress → Pending customer → Escalated → Resolved → Closed. The engineer who resolves a ticket closes it; tickets pending customer confirmation auto-close after a set period (commonly 3–5 business days). Only the ticket owner or a team lead reopens a closed ticket.

C2. Who does what

A one-page map of the org from a support engineer's point of view. The owns boundaries below are common telematics-desk defaults; fill in the real names and channels locally. Where a contact isn't yet defined, the default route is your head of technical support.

Note the Integrations row: layer 7 tickets look like platform faults but are almost never resolved by the same people. Decide early who owns them. In most telematics operations relay / endpoint tickets are owned by the Integrations team, not general 2nd line — route them there, or via your head of technical support if that team isn't yet defined.

C3. Escalation

• Escalation is not failure. Escalating early with good notes is better work than sitting on a ticket for a day. Say this out loud in training — new hires routinely over-hold tickets to avoid looking incapable, and that is the single most expensive habit in 1st line.
• What must be in an escalation. A handover that makes the next person start from zero wastes the whole investigation. Required: customer + contract, object/IMEI, exact symptom, timestamps, what Sensors tracing showed, what Audit history showed, what you checked and ruled out, what you think it is, and what the customer has been told and expects.
• Triggers: standard triggers are — the investigation time limit reached with no progress (see B6); P1/P2 severity; multiple customers affected (an incident); a VIP or strategic account; any data loss or deletion request; and anything touching billing, contracts or admin rights you don't hold. When a trigger fires, escalate to your head of technical support with the full handover above.
• Emergency / out-of-hours path: the industry norm is a documented on-call rota with a single emergency contact point. Out of hours, raise P1 incidents immediately to the on-call engineer or your head of technical support; everything else waits for the next business day.
• The customer stays informed. Escalating does not end your ownership of the relationship — by default, 1st line remains the customer's single point of contact and owns communication until the ticket is resolved, even after the technical work moves to another team. Confirm this with your head of technical support.

C4. Special cases

• Multiple customers reporting the same thing → suspected platform incident. Stop debugging it case by case and alert your head of technical support (or the on-call / incident contact) immediately, so a single incident ticket is opened and customers are updated together.
• Customer requests something needing admin-panel access they don't have (new contract, module activation, tariff change) → route to the team that owns the action (Sales for commercial / module changes, 2nd line or admin for rights) through the documented approval path. If no path is defined, your head of technical support authorises or forwards it.
• Data recovery: deleting an object destroys all its data and history, and restoring requires a system administrator. Treat any deletion request as irreversible and confirm before acting. Restoration is only possible if a backup still covers the period, and the window is limited — never promise recovery. Raise it to your head of technical support at once, because the window is time-critical.
• Feature requests → log as a service / feature request and pass to Product via your head of technical support. Tell the customer honestly that it's been recorded and passed on, with no committed date — never promise a feature.
• Angry customer demanding a manager → don't refuse. Acknowledge, and escalate the call to your team lead or head of technical support — a demand for a manager is itself a valid escalation trigger.

Module C assignments

1. Route the ticket. Trainer gives 10 real (anonymized) past requests. Trainee names the owning team and justifies it. Use genuine past tickets — invented ones are always too clean.
2. Write an escalation. Take the unresolved case from Module B's broken-sandbox exercise and write the handover. The 2nd-line engineer who receives it grades it: could they start work without asking a single question?
3. Shadowing. A common default is 8–16 hours (2–4 days) listening to live calls before handling their own, adjusted to how quickly the trainee is ready. Confirm the volume with your head of technical support.
4. Reverse shadowing. Trainee handles live contacts with a senior listening in. Typically a further 2–3 days; sign-off when the trainee completes a full Acknowledge → Diagnose → Act → Close cycle unaided on a real contact. Your head of technical support signs off readiness.

Module D · Industry standard practice

Goal. The engineer works to the conventions the support profession already uses, rather than inventing local habits — and understands the one obligation specific to telematics that has no equivalent in ordinary software support.

Modules A–C are about handling a case. This module is about the system the cases live in. Most of it is drawn from ITIL 4 (the dominant IT service management framework) and KCS (Knowledge-Centered Service, developed by the Consortium for Service Innovation since 1992). Both are worth knowing by name: they are what a support professional joining from another company will already expect.

D1. Three kinds of ticket, not one

The most common structural mistake in a young support desk is treating everything as "a ticket." ITIL separates three, and they have different owners, different clocks, and different definitions of done:

Why this matters here. A large share of PILOT 1st-line volume is service requests, not faults — module activation, tariff changes, user creation, tokens. They need an approval path, not a diagnosis (see C2). Mixing them into the incident queue makes the queue look broken and hides the real outages. Equally: if the same symptom arrives three times, that is a problem, and continuing to fix it one ticket at a time is the most expensive thing a support desk can do.

D2. Priority is calculated, not felt

The industry standard is a priority matrix: priority is derived from impact (how much of the business is affected — how many users, is a critical service down, is there risk to revenue or compliance) crossed with urgency (how fast it must be fixed — driven by deadlines, operational cycles, and commitments). Priority then drives response time, escalation path, and how loudly you communicate.

The point of a matrix is to stop the desk from prioritising by who shouts loudest. It also settles the argument new engineers always have: a single-user issue can still be urgent — the classic example is a payroll problem the day before payroll runs.

A starting matrix for a telematics desk. A draft to argue with, not to adopt. The matrix below is a common industry default; agree the final priorities and response targets with your head of technical support and team leads, and publish them to customers so expectations are shared.

D3. Capture knowledge while you solve, not afterwards

KCS (Knowledge-Centered Service — since May 2026 renamed Knowledge-Centered Success) is the standard model for this. Its central claim is that knowledge should be a by-product of solving the problem, created in the workflow, rather than a documentation project someone does later. The operational half is the Solve loop: Capture → Structure → Reuse → Improve.

The practices worth importing verbatim:

• Capture in the customer's words. Not "Sensor field mapping mismatch" — the article should say "fuel gauge shows zero." The next person searching is the customer or a new hire, and neither knows your vocabulary. This is the single highest-leverage habit in KCS.
• Search before you solve; if it isn't there, write it. Every ticket either reuses an article or creates one.
• Content is demand-driven. Write articles for what customers actually ask, not what you think they should know. The ticket queue is the editorial plan.
• Improve on reuse. Whoever finds an article slightly wrong fixes it then and there. Articles are not owned by an author.

D4. Measure the right things

Every support metric distorts behaviour. Adopt them knowing how:

As a default, most telematics desks track FCR, CSAT, reopen rate and escalation rate for coaching and process improvement, and AHT only for capacity planning — never as an individual target. Which are actually measured here, their targets, and whether they feed coaching or formal review, are questions for your head of technical support; answer trainees plainly, because evasion here damages trust fast.

D5. Driver data is personal data

The reference position, widely cited across the industry: the European Data Protection Board's Guidelines 01/2020 on connected vehicles treat location, speed, distance and driving-behaviour data as personal data once they can be linked to a natural person. In practice that covers essentially everything a modern tracker collects — GPS traces, harsh-braking events, idling time, login IDs, camera footage.

This is enforced, not theoretical. In January 2025 the Italian regulator fined a road haulier €50,000 over GPS tracking of 50 tractor-trailers: the tracking stayed active during drivers' breaks and location data was retained for 180 days. Transparency, retention and proportionality each contributed to the penalty independently — getting one right does not excuse the others.

Which regime applies depends on the customer, not on us. Default working rule: apply the strictest regime that touches the contract, treat all driver location and behaviour data as personal data, and send any doubt to your head of technical support (or the company's data-protection lead). The regimes below are the common ones across PILOT's customer base.

• Ghana: the Data Protection Act, 2012 (Act 843), enforced by the Data Protection Commission, with mandatory registration of data controllers and processors.
• EU / UK: GDPR, with fines reaching €20m or 4% of global turnover at the top tier.
• Elsewhere: PILOT's own documentation shows integrations for Saudi (WASL), the UAE (Etisalat) and Riyadh Municipality — so the customer base spans several regimes at once. Default position: the fleet operator (the customer) is the data controller and PILOT / your company is the data processor acting on their documented instructions. Confirm this per contract with your head of technical support or data-protection lead.

What this actually changes for a 1st-line engineer

Not abstract compliance — five concrete rules:

1. Access is not authorisation. Master status lets you open any customer's driver history. That you can does not mean you may. Open the object on the ticket; nothing else. Default: assume admin-panel access is logged and reviewable, and behave accordingly. Confirm the real logging position with your head of technical support, and tell trainees plainly either way.
2. A request from a driver is not a normal ticket. Drivers have rights over their own data — access, correction, erasure. If a driver contacts support directly asking what is held about them, that is a data-subject request with a legal clock on it. Route it, unchanged, to your head of technical support or the data-protection lead — do not fulfil it yourself.
3. "Where was driver X on Saturday?" puts you inside an employment dispute. The fleet manager may well be entitled to it — but the engineer pulling the report is not the person who should be deciding that. Default: don't fulfil ad-hoc "where was driver X" requests on the spot. Confirm the requester's authority and route through your head of technical support; the person pulling the report is not the person who decides it's lawful.
4. Deletion is irreversible and may be either an obligation or a breach. Deleting an object destroys all its data and history. Retention has a floor (evidence, contracts) and a ceiling — the 180-day retention was part of the Italian fine. Never action a deletion on a phone call alone. Default: act on a deletion only with written authorisation from the customer's authorised contact, subject to any legal retention floor. Route every deletion request to your head of technical support.
5. Know that "private mode" is a real category. Industry practice for personal use of company vehicles is a privacy mode suppressing location during non-work time — the Italian case turned partly on tracking continuing through breaks. If a customer asks whether PILOT can do this, it is a real question with legal weight, not a feature whim. Default answer: yes — suppressing location during personal / non-work time is standard telematics practice and PILOT supports privacy-mode configuration; treat the request as legitimate and route the setup through your head of technical support.

The line to teach: support engineers are not lawyers, and should never adjudicate. But they must recognise the shape of a data-protection request and route it, rather than helpfully fulfilling it. The failure mode is not malice — it is an engineer being accommodating.

Module D assignments

1. Sort the queue. Trainer gives 12 anonymized past tickets. Trainee labels each Incident / Service request / Problem, then assigns a priority from the D2 matrix and justifies impact and urgency separately. Disagreement here is the exercise — argue it out.
2. Find the problem. Given a month of tickets, identify the recurring symptom that should be raised as a problem rather than solved twelve more times.
3. Write a KCS article. Take the resolved broken-sandbox case from Module B and write it up titled in the customer's words. Test: search for it using only the phrase a customer would type. If you can't find it, retitle it.
4. Physical clock drill. Trainer reads out six faults; trainee answers only "what happens in the physical world while this stays broken?" and re-prioritises accordingly. Include a refrigerated trailer and a stolen-vehicle case.
5. The uncomfortable request. Role-play: a fleet manager asks for a weekend location report on one named driver, and is annoyed at hesitation. Trainee must neither refuse flatly nor simply comply — they route it, and keep the relationship intact. Default outcome for the role-play: the trainee routes the request to their head of technical support and keeps the relationship intact, rather than refusing flatly or simply complying. Brief the trainer on the local policy if it differs.
6. The driver on the phone. Role-play: a driver calls support directly asking what data is held on him and demanding it be deleted. Trainee must recognise the category and route it. Most trainees will try to be helpful. That is the lesson.

Documentation map

Anyone comparing the internal training plans against the public documentation needs to know how the two relate before drawing conclusions.

What the documentation covers

That third row is the important one. A significant part of both plans covers admin-panel and commercial concepts that simply are not in the public documentation. Their absence there says nothing about their correctness.

Worked example: why "/1000" is right

Day 7 of the support plan teaches setting the formula /1000 on a battery voltage sensor. An earlier draft of this supplement claimed this had been superseded by reusable "handlers." It has not.

The documentation's own worked example is a battery sensor reporting millivolts, converted to volts by entering /1000 in the Conversion formula field. Simple formulas start with an arithmetic sign and the raw value is substituted automatically; complex ones start with = and require the value explicitly as %value%. Handlers are a reuse mechanism for applying the same conversion across many sensors — an addition alongside direct formulas, not a replacement.

The plan is correct. The lesson is about method: absence of a statement in the public documentation is not evidence that an internal plan is wrong.

If you do want to refresh the plans

Not corrections — optional additions, for whoever owns the material to accept or reject:

• Sensors tracing could be mentioned in Day 4 alongside Current Track and Follow Object, since it lives in the same right-click menu and is the most useful diagnostic view in the product.
• Recalculate has no home in either plan, yet it is the step that makes a sensor fix apply to historical reports.
• Topics in the documentation but not in either plan, if scope ever allows: Report builder, Control room, sensor handlers, webhook notifications, the Telegram bot, Teltonika FOTA, relay/endpoints, and the mobile apps.

Integration options

Option 1 — Bolt on as Week 3 (simplest). Product training runs as written, then this module runs as a third week. Clean to schedule. Downside: two weeks of pure product knowledge before the trainee hears a customer, which is a long time to stay abstract.

Option 2 — Weave in (recommended). These skills are habits, and habits need repetition, not a single week.

Shadowing is the part I'd protect if time gets squeezed. Everything else can be compressed; supervised live contact can't be substituted.

Checklist: information needed before delivery

Ordered roughly by how much it blocks:

1. Ticketing system name, required fields, priority definitions, response targets
2. Team contact map — names, channels, ownership boundaries (C2), including who owns layer 7 / relay tickets
3. Escalation triggers and the out-of-hours path
4. Whether 1st line retains customer contact after escalation
5. Approval path for admin actions (new contracts, module activation, tariff changes)
6. Incident procedure — who gets alerted when several customers report the same issue
7. Where known issues / solutions are documented
8. Investigation time limit before escalation
9. Data restoration: who can recover a deleted object, and within what window
10. Shadowing volume and sign-off criteria
11. 10 anonymized past tickets for the routing exercise, and access to a breakable test environment with admin-panel visibility

Sources drawn on in this supplement: PILOT documentation — Roles and access rights; Object menu; How to apply formulas; Sensor handlers; How to create a notification; How to set up notification delivery; Audit and Audit history; Failed Login Attempts; Connection Lost; Raw data; Recalculate; Troubleshooting; Statistics. Industry practice: ITIL 4; KCS (Consortium for Service Innovation); EDPB Guidelines 01/2020 on connected vehicles; Ghana Data Protection Act 2012 (Act 843).