Plan
Define the operation's reference: demand, routes, stops, schedules, capacity, estimated cost and comfort.
- People and addresses
- Shifts and sites
- Contract rules
- Routes and stops
- Schedules and capacity
- Estimated cost of the scenario
Merus connects data, people and contracts to show how passenger transport really happens, from the planned trip to the recorded evidence.
Merus Tracker is an operational control and governance platform. It brings together planning, vehicle, passenger and contract information, relates each event to its trip and creates a common foundation for monitoring, decision-making, transparency and auditing.
It is not just tracking: it is a reading of the operation organized around the service that was contracted and delivered.
From plan to evidence, each step feeds the next. Choose a step to see what goes in and what comes out.
Define the operation's reference: demand, routes, stops, schedules, capacity, estimated cost and comfort.
Receive data from the sources that already exist, via APIs and files: tracking, telemetry, validators, fare collection and corporate systems.
Group vehicle, route, driver, passenger, event and contract around the same trip.
Make trips, ETAs, boardings, deviations and alerts available to the responsible roles.
Compare planned with actual: punctuality, mileage, occupancy and exceptions.
Produce records, reports and dashboards for oversight, auditing, payment and continuous improvement.
Merus works as a hub that correlates sources from the perspective of the trip actually made. The same evidence can serve operations, HR, finance, oversight and control, according to the rules of each project.
Each moment of the trip raises different questions. The platform keeps the answer in the same place.
The capabilities below rest on the same foundation of trips. Each project enables what its sources, equipment and rules allow.
Calculates stops, route and schedules from addresses, shifts, capacity and rules.
Organizes operational indicators to compare fleet, cost and service, without promising results on its own.
Compares the schedule with the recorded execution at the unit of the trip.
Supports operational and contractual review when rules and sources are part of the scope.
An arrival reference in flows where the capability is enabled.
Relates attendance or boarding to the passenger and the trip, depending on the implementation.
Merus can use equipment and systems that already produce data. A technical assessment identifies sources, owners, frequency, quality and rules; equipment, protocols and levels of automation are defined and validated in each project.
There is no universal connector or published timeline: each scenario goes through technical validation before implementation.
The technical foundation is the same. The applications change according to each organization's pain point and contract.
Demand, employees, trips, boardings and contract review with the carriers.
Scheduled service, oversight, local rules, subsidy and accountability to the public.
Usually not. Merus can use the data that already exists when integration is technically feasible, with sufficient quality, a defined purpose and agreed responsibilities.
Events are linked to the corresponding trip. This way, planning, vehicle, passenger, execution and evidence can be consulted in the same context.
There is no promise of universal integration. Each project validates sources, formats, interfaces, frequency, quality, security and responsibilities before implementation.
The technical foundation is shared, but the applications change. In corporate charter transport the focus is on people and business; in the public sector, on contracts, oversight and transparency.
The data depends on the goal and scope. Planning, tracking, telemetry, boardings, fare collection and corporate or public systems are possible classes; no source is assumed to be available before the diagnosis.
The site does not establish a mandatory device. Equipment and identification methods are assessed according to the rules and sources of each project.
The initial conversation identifies the goal, sources and responsible parties; the technical scope defines configuration, integration, validation and operation. Timelines are not published because they depend on the scenario and still require commercial confirmation.
Hosting, access, retention, responsibilities and controls must be answered in the context of the project. The security page records only verified principles and offers a specific subject for questionnaires.
Content updated on October 15, 2026.