To choose a fleet tracking system in DRC, start from the losses you need to control, then test each supplier on 2G coverage and offline storage, hardware inputs, installation quality, local support, alert delivery, data export and ownership, and the full cost per vehicle. Run a short pilot on your own routes before signing for the whole fleet.
What problem are you actually trying to solve?
Write down the two or three losses that justify the project before you meet any supplier. Fuel siphoned from tanks, unauthorised night trips, long idling, drivers leaving agreed routes, slow response to breakdowns and generators running when nobody needs them are different problems. They need different sensors, different alert rules and different people to act on them.
A supplier who demonstrates every feature without asking about your operation is selling a screen, not a solution.
Will the tracker work on your routes, including where the network drops?
Many vehicle trackers, including widely used compact models such as the Teltonika FMB920, communicate over 2G GSM. That matters in DRC. ITU’s Facts and Figures 2024 notes that areas where 2G is the best available standard are found in rural regions, and that Africa has the largest mobile broadband coverage gap. A 2G device may keep reporting where a smartphone loses data, but no network covers every road, mine or river crossing.
The real question is what the tracker does with no signal. Ask the supplier to show that the device keeps recording positions and events while offline and sends them in order when it reconnects. Ask how the platform marks a delayed position, so that dispatchers do not treat a stale location as the current one. Ask which mobile operators they have tested on your corridors.
Does the hardware match the data you need?
Position, speed and ignition come from almost any tracker. Fuel level, engine data, door or PTO status, temperature and generator readings need the right inputs and accessories. Ask which model is proposed for each vehicle type, why, and which inputs will actually be wired.
- Ignition: wired to a real ignition source, not inferred from supply voltage alone.
- CAN or engine data: confirm whether the model reads it directly or needs an adapter, and which values your vehicles actually expose.
- Fuel: which sensor brand, which interface (RS-232, RS-485 or Bluetooth) and how each tank will be calibrated. Omnicomm’s documentation, for example, describes connecting its LLS fuel level sensors to a terminal over RS-485 or RS-232.
- Generators: which controller protocol is supported, and over which port. Trackers with serial interfaces, such as the Teltonika FMB125 with RS-232 and RS-485, are used for this, but the controller model and its register map still have to be confirmed (see the generator monitoring guide).
Who installs the devices, and how is the work checked?
Installation decides more outcomes than the tracker brand. A device on a loose ground, a badly tapped fuse or an antenna under sheet metal will produce data gaps and false alarms that look like platform faults.
Ask who does the installation (own staff or subcontractors), what each technician records per vehicle and what the acceptance test covers. A good answer includes photos, the device identifier matched to the registration, a test of every wired input, a confirmed position and transmission, and a signed sheet for each unit. The operations guide lists the commissioning checks.
What happens when a unit fails in the field?
Ask where the support team is based, which languages it works in, how a fault is reported and who travels to the vehicle. Ask whether spare trackers, sensors and harnesses are held in the country or imported for each replacement. A tracker waiting weeks for a part is a vehicle you cannot see.
Will alerts reach the right person in time?
An alert that sits in a dashboard nobody opens at night is a log entry, not an alert. Ask which channels are supported (WhatsApp, SMS, email, mobile app), whether alerts can be routed by site or vehicle group, and whether quiet hours and escalation are possible. Then ask who owns each alert and what response is expected. A few precise alerts beat a stream that everyone mutes.
Can you get your data out, and who owns it?
Reports should answer your questions without a support ticket: trips, stops, idling, mileage, fuel events, geofence visits and driver behaviour, filtered by vehicle, group and date. Check that each report exports to Excel or CSV and that raw history can be extracted if you ever change supplier.
Put data ownership in writing. Ask who can see your fleet, how user access is granted and removed, whether actions are logged and what happens to your history when the contract ends.
Should you run a pilot before equipping the whole fleet?
Yes. Equip a small, representative group: a vehicle on long-distance routes, one that parks overnight somewhere exposed, one with a fuel sensor and, if relevant, one generator. Run it long enough to see normal days, refuelling, a coverage gap and at least one real event. Agree in advance what the pilot must prove, and use it to test the supplier as much as the hardware.
What does it really cost?
Compare suppliers on the full cost per vehicle over the period you plan to use the system, not on the device price alone. Ask for each item separately:
- hardware: tracker, sensors, harnesses and accessories;
- installation and calibration, including travel to remote sites;
- the monthly platform subscription, and what it includes;
- SIM cards and data, and who manages them;
- maintenance visits, re-installation and replacement of damaged units;
- training for dispatchers and managers.
A cheap device with paid support for every visit can cost more over time than an all-inclusive offer.
Questions to ask every supplier
| Question to ask | Why it matters | Good answer looks like |
|---|---|---|
| What does the tracker do with no network? | Coverage gaps are part of many DRC routes; lost data cannot be recovered. | Records are kept in memory and sent in order on reconnection; the platform marks delayed positions. |
| Which model goes in each vehicle, and which inputs are wired? | The model decides which data is possible. | A per-vehicle plan naming the model, inputs and sensors. |
| Who installs, and what is the acceptance test? | Poor installation causes data gaps and false alarms. | Trained technicians, photos, input tests and a signed sheet per unit. |
| Where are support staff and spare parts? | Downtime grows with distance and import delays. | Named local contacts, a fault process and spares held in the country. |
| How do alerts reach people? | An unread alert changes nothing. | WhatsApp, SMS or email routed by group, with an owner for each alert. |
| Can we export everything? | You need reports for audits and the option to leave. | Excel or CSV exports, and raw history on request. |
| What is the full cost per vehicle? | Hidden recurring costs change the comparison. | Hardware, installation, subscription, SIM data and support itemised. |
Checklist before you sign
- Two or three target losses written down, each with an owner.
- Coverage tested on real routes; offline storage and retransmission demonstrated.
- Tracker model and wired inputs agreed for each vehicle type.
- Fuel sensor brand, interface and calibration method confirmed for each tank.
- Installation standard and acceptance sheet agreed before the first unit.
- Local support contacts, fault process and spare parts confirmed.
- Alert channels, recipients and escalation set for every alert.
- Report list and export formats checked with real data.
- Data ownership, user access and exit arrangements in writing.
- Pilot scope, duration and success criteria agreed.
- Full cost per vehicle itemised: hardware, installation, subscription, SIM data and support.