Expert consulting on GPS monitoring and telematics in Azerbaijan
We survey your fleet and your requirements before any hardware is bought: interviews with the manager, the dispatcher and the accounts department, an inspection of every type of vehicle and, if you wish, a pilot on 3–5 vehicles. You get a system architecture, an equipment specification by vehicle type, a budget and an implementation plan, or a tender specification. Payback is calculated on your own figures and presented as an estimate, not a promise.
- 1Vehicles reporting in 943 vehicles with no data for over a day
- 2Engine hours on plant 83
- 3Fuel reports 68opened once a month
- 4Fuel level sensor calibration 57tanks were replaced, sensors never recalibrated
- 5Fuel drain notifications 35no recipients assigned
A document you can procure and implement a system from: which tasks it solves, what equipment goes on each type of vehicle, how connectivity, the Wialon structure, reports and integrations are arranged, what it costs and in which order to roll it out. Wherever the data is thin, the document states plainly what needs to be verified on the pilot.
When a tracker and a map are no longer enough
A straightforward fleet of cars can be fitted out in a day: a tracker, a SIM card, access to Wialon. The difficulties begin when the fleet also holds tractor units with tachographs, old KamAZ lorries with no CAN bus, excavators that stand on a site in Karabakh for months, and an accounts department that wants mileage delivered straight into 1C.
Telematics consulting exists to design that kind of system before the money has been spent on hardware. We work through the business requirements, look at the vehicles in person, choose trackers and sensors for each type of machine, and think through connectivity, integrations and access rights. The output is a system architecture, an equipment specification and a budget.
Consulting is particularly useful ahead of a tender, when moving from another platform, and in cases where a system is already installed but delivers less than was expected of it.
How the work goes, step by step
What each role needs
Manager, dispatcher, workshop manager and accountant: each has their own expectations, and those often pull in different directions.
One of every type
CAN bus, tanks, tachograph, places to mount sensors. We travel out to the regions and to sites in Karabakh.
Equipment and Wialon
A kit per vehicle type, connectivity and roaming, groups, reports, notifications, an integration diagram.
3–5 vehicles of different types
Optional: we check that the data arrives as intended before the full volume is purchased.
Architecture and budget
Specification, budget and a week-by-week plan. You can implement it with us, with another integrator or on your own.
How a fleet survey might run
An illustrative example: 40 vehicles — vans in Baku, tippers and excavators on a site near Sumgait, mileage needed in 1C.
- Interviews with management, the dispatcher and the accountant 4 meetings
Accounts need mileage in 1C, the dispatcher needs fuel drains. We note down where the expectations diverge.
- Inspection of vehicles at the depot and on site one per type
An engineer needs 15–30 minutes per vehicle, so we look during a break or at the end of a shift.
- The older tippers have no CAN bus limitation
For those the design calls for a fuel level sensor and an engine operation sensor. Engine revs cannot be obtained without extra work — and we say so in the document.
- Design: equipment, Wialon, export to 1C design
A kit for each vehicle type, groups and reports, and the exchange format for the accounts department.
- The final document reaches the client done
Budget, a week-by-week implementation plan and a list of what to verify on the pilot before purchasing.
The questions people come to us with
Requests for consulting almost always start with one of these questions:
Which tracker should we fit?
The fleet has five types of vehicle, and five different sellers recommend five different devices. What is needed is a single logic for choosing, so you do not end up running a menagerie of hardware.
Do we need a fuel level sensor, or will CAN do?
The answer depends on the model of the vehicle, its year of manufacture and what exactly you want to catch: fuel drains, overconsumption, or simply counting refuelling events.
How do we connect monitoring to 1C?
Accounts need mileage and consumption on the waybills, logistics need trip statuses in the ERP. You have to decide what is passed across and how.
We are announcing a tender — what goes in the specification?
You want competitive procurement without woolly requirements, the kind that let the winner supply a cheap device that cannot do half of what you need.
We have a system, but little to show for it
The trackers have been in place for two years, nobody opens the reports, and fuel still is not being accounted for. An outside view is needed.
We are moving from another platform
The history has to be preserved, the hardware that can be reflashed must not be thrown away, and the dispatchers cannot stop working.
How a project runs
A typical project takes between two and five weeks, depending on the size and the variety of the fleet.
- Interviews with the client (1–2 days). We talk to the manager, the dispatcher, the workshop manager and the accountant. Each has their own expectations of the system, and those often contradict one another.
- Vehicle inspection (2–5 days). An engineer looks at one vehicle of each type: whether there is a CAN bus, what the tanks are like, where sensors can be mounted, how the tachograph is wired in. For sites in the regions we travel out: Sumgait, Ganja, Mingachevir, construction sites in Karabakh.
- Design (1–2 weeks). An equipment layout by vehicle type, the choice of connectivity tariff, the structure of objects and groups in Wialon, the set of reports and notifications, the integration diagram.
- Pilot (optional, 2–4 weeks). We fit equipment to 3–5 vehicles of different types and check that the data arrives as intended.
- Final document. Architecture, specification, a budget for hardware and subscription fees, and a week-by-week implementation plan.
The document is yours. You can implement it with us, with another integrator or in-house.
What we need from you and where our responsibility ends
People for the interviews
Manager, dispatcher, workshop manager, accountant — an hour to an hour and a half with each. If one of them does not take part, their requirements go into the design marked as not confirmed.
Access to the vehicles and the data
A list of vehicles with models and years, the chance to inspect one vehicle of each type, access to the current monitoring system if there is one, and a description of what is currently sent to 1C or the ERP.
What we are answerable for
That the specification is technically feasible on the vehicles we inspected, and that the limitations of each solution are set out. If a vehicle we did not see turns out to have a different specification, the design will have to be revised.
What you decide
Which tasks take priority, what budget is acceptable, and who implements the system. We show the options and the consequences of each, but the choice and the purchasing remain yours.
The standard architectures we start from
Company cars and vans
A tracker in the class of the Teltonika FMB140 or FMC130, reading CAN through a contactless adapter: mileage, fuel level as a percentage, engine revs. Driver identification by card or key where a vehicle is shared between several people.
Separate fuel level sensors are usually unnecessary here: for cars the CAN data is enough, and cutting into a plastic tank is harder and dearer. The main reports are mileage, private journeys and driving style.
A tender specification: what to put in it
Large companies and public bodies procure monitoring through tenders. A weak specification leads to one of two outcomes: either the cheapest bid wins and cannot do half of what is needed, or the requirements are tailored so tightly that only one bidder qualifies.
We help write a specification that describes the task rather than the brand:
- the functions that have to work (for instance, detection of fuel drains of 10 litres and above with a notification within five minutes), rather than the model name of a tracker;
- requirements for connectivity and for working without a network: buffer size, support for several operators;
- the format and retention period for data, the method of export, the openness of the API;
- fitting requirements: sealing, a photo report, an acceptance record for every vehicle;
- the support SLA: response times, call-outs to the regions, replacement equipment;
- assessment criteria in which price is an important but not the only parameter.
We can take part in such a tender as a supplier. If that is a conflict of interest for the client, we prepare the specification and do not bid — this is agreed in advance.
What the final survey document looks like
Objectives and metrics
What the company wants to control and by which figures it will know the system is working: consumption per 100 km or per engine hour, the share of vehicles reporting in, how long a dispatcher takes to react to a fuel drain.
The fleet by type
A table: vehicle type, quantity, presence of CAN, type of tank, tachograph, particular features. For each type, the chosen equipment kit and the reasoning behind it.
Limitations
Which data cannot be obtained on which vehicles, or will be imprecise, and what to do about it: accept it, invest in extra work, or leave the vehicle out of some of the reports.
Connectivity, platform, integrations
Operators and roaming, the structure of objects and groups in Wialon, the list of reports and notifications, and what goes to 1C or the ERP and in what format.
Budget and plan
One-off costs and monthly payments, the implementation stages week by week, and what to verify on the pilot before the full volume is purchased.
When a tender specification can be considered ready
Before a specification goes out to tender, we run it past a few questions. If the answer to any of them is no, the document goes back for revision:
Requirements can be verified
Every requirement can be checked at acceptance: a fuel drain of 10 litres shows up in the report, rather than effective fuel control.
No tie to a brand
Functions and characteristics are described, not the model of a tracker. Equipment from several manufacturers meets the requirements.
Acceptance is described
How the winner hands the work over: records, photographs, test scenarios, a pilot. Without this, the argument about quality starts after the invoice is paid.
Every role is accounted for
The requirements of accounts, dispatchers and the security team do not contradict one another and are brought together in a single document.
Auditing a system that is already in place
It happens that the equipment has been working for a long time, yet the manager cannot say whether anything has improved. In an audit we look at three things.
Data quality. How many vehicles are genuinely reporting in, whether there are gaps in the tracks, whether the fuel level sensors are calibrated, whether the engine hours are telling the truth. It is not unusual to find that a third of the fuel sensors have been producing nonsense since a tank was replaced or a repair was carried out.
Platform settings. Whether the sensors are set up correctly, whether the notifications work, whether there are any fuel and idle-time reports at all. A familiar picture: the system is capable of catching fuel drains, but the notifications are not routed to anyone.
Use. Who goes into the system and how often, and which decisions are taken on its data. If nobody reads the reports, the problem is not with the trackers.
The result is a list of fixes: what to reconfigure, what to recalibrate, what people need to be taught. This often achieves more than buying new hardware. The reconfiguration can be ordered separately as GPS system configuration.
What consulting gives you before you buy
No surplus equipment
Fuel level sensors go where they are needed, rather than onto every vehicle in turn. On a mixed fleet that is usually a noticeable share of the budget.
One logic across the fleet
The same sensor names, common reports, a structure of groups that makes sense. New vehicles are connected from a template.
The budget is worked out in advance
Equipment, fitting, connectivity, licences and integrations are costed before procurement, including roaming and working outside network coverage. Items that depend on the outcome of the pilot are flagged separately.
No lock-in to a supplier
The document describes a solution, not a brand. You can implement it with any contractor, and the data stays in open formats.
Three formats of consulting
Vehicle inspection and interviews are part of all three; what changes is the deliverable.
| Implementation design | Tender specification | System audit | |
|---|---|---|---|
| When it is commissioned | Before buying | Before procuring through a tender | System in place, little benefit |
| Equipment specification | Yes, by vehicle type | No, functions without brands | No, the system is already installed |
| Budget and implementation plan | Yes, week by week | No, criteria for assessing bids | No, a remedial plan |
| Verification on vehicles | Yes, optional pilot | Yes, we describe acceptance | Yes, against current data |
| What you end up with | Architecture and specification | Verifiable requirements | What to reconfigure and what to teach |
Questions about “Expert consulting on GPS monitoring and telematics in Azerbaijan”
Request a call
A specialist will call back and match a solution to your fleet and your task.