Rules that protect operations.
Workflows turns real operating conditions into behaviors that execute directly on the fleet: it combines telemetry, CAN bus and sensors with custom firmware so that an operational rule ends up as an action on the vehicle.
The problem
The operation already knows what should happen. The problem is that someone still has to make it happen.
Every operation has clear rules: if the vehicle sits idling, cut the engine; if no driver is identified, don't start; if it enters a risk zone, warn. But those rules end up spread across procedures, operators and systems. Telemetry detects what happens; someone still has to interpret the signal and decide what to do.
Traditional model
- Signal
- Alert
- A person reviews it
- Interprets the context
- Decides
- Executes
With Workflows
- Signal + condition
- Workflow
- Action
- Traced execution
The difference
It's not just about knowing that something happened. It's about defining what should happen when it does — and making it happen.
From an operating rule to a vehicle behavior.
You don't adapt to a closed list of automations: first we understand what the operation needs, then we build the behavior.
Define the condition
What has to happen, on which vehicles and under which circumstances.
Build the logic
MyKeego combines the necessary signals, the conditions and the action.
Deploy to the fleet
The rule runs where it should and every execution stays traced.
The platform
defines and supervises
The vehicle
executes
Examples
Workflows already running on fleets
This is what we've already built with real operations — not a closed catalog. The logic adapts to the operation, not the other way around.
Idle engine cutoff
Detects the engine running with no movement and cuts it off to save fuel.
Cabin presence
Sensors that detect whether someone is in the cabin and trigger rules based on context.
Efficiency calculation
Crosses fuel use, idling and driving style to measure each vehicle's real efficiency.
Rain via wipers
Uses the wiper state to detect rain and adjust speed alerts accordingly.
Driver identification
The vehicle only starts once the driver identifies; every trip is tied to a person.
Remote doors & engine
Opens doors or blocks the engine remotely, by rule or on demand.
Geofences
Define geographic zones and trigger entry and exit alerts per vehicle.
A real case, from rule to result.
How an operating rule ended up as a vehicle behavior, with a measured effect.
01 · Operational need
Avoid prolonged idling
Vehicles running without moving, burning fuel without producing work.
02 · Signals used
GPS + CAN bus + voltage
Speed, engine state and alternator voltage to tell an engine running apart from a key left in.
03 · Condition
Engine on, speed 0
Sustained for several minutes.
04 · Action
Reversible engine cutoff
The cutoff is automatic, but the driver can undo it: the rule changes the default behavior without trapping the vehicle.
05 · Measured result
−53.9% idling events
From 18.0 to 8.3 events per day, ~45 L of fuel saved per month per vehicle. Measured over 29 days of operation.
Automating a decision doesn't mean losing visibility over it.
Every automatic action remains observable and traceable from the platform: which workflow is active, which vehicles it runs on, what condition triggered it, what action it took and when.
Execution history
logidle-cutoff·AB123CD
Engine on · speed 0 · 5 min
Engine cutoff executed
plant-zone·EF456GH
Entry to restricted geofence
Alert sent to supervisor
driver-id·IJ789KL
Ignition without driver identified
Starter block activated
Custom firmware
We combine the vehicle's signals — CAN bus, GPS, dedicated sensors — with custom firmware that doesn't just read: it acts. The logic adapts to the operation, not to a closed catalog of rules.
Turn one of your operation's rules into a Workflow.
Book a demo to evaluate which repeatable decisions of your operation can become automatic behaviors on the fleet.