Skylark: a logistics control tower where the dispatch board knows the rules
One multi-tenant platform running inbound and outbound loads, driver allocation, live telematics, in-app communication and proof of delivery from the field, for a Canadian carrier group operating both highway and city work.
- 6 tools replaced by one platform
- 4 clocks on every Canadian driver
- 2 timestamps on every field event
- 1 region, data resident in Canada
What the platform does
Before, the operation ran on tools that did not speak to each other. Telematics in one system, messaging in another, several more for individual slices of the job, and underneath all of it the actual coordination kept by hand in a spreadsheet.
Now it runs in one place.
Loads. Inbound and outbound, planned and documented electronically, with the state of every load visible to everyone who needs it.
Drivers. Who is free, where they are, what they are on, and what their hours allow.
The fleet. Live position and vehicle data from the trucks' and trailers' own systems, sitting beside the dispatch data rather than in a separate application.
The field. A driver application carrying jobs out and bringing proof of delivery and job documents back, captured at the moment they happen.
The conversation. Messaging inside the platform, so a dispatcher assigns a delivery inside the thread rather than in a second product with its own login.
- Client
- Skylark, a Canadian logistics operator
- Sector
- Logistics and mobility
- Operation
- Highway and city freight, run across a group of related companies
- Our scope
- Platform architecture, load planning and dispatch, telematics integration, driver application, multi-tenancy, cloud infrastructure and data residency
The one fact that shaped everything
In trucking, most of the constraints are somebody else's, and breaking one is not a bug.
A driver's hours are set by federal regulation and enforced at the roadside. A delivery window is set by a customer. A dock's availability is set by a warehouse. A trailer's temperature range is set by what is inside it. A border, a weight limit, a curfew.
Software in most industries can be wrong and be corrected. Here a wrong decision produces a violation, a refused load, a spoiled shipment or a claim, and each of those has a cost attached before anybody notices the software was involved.
That changes what a dispatch platform is for. It is not a faster way to make the same decisions. It is a system that knows the rules the decision has to satisfy, so a dispatcher cannot casually plan something that will not work.
The old spreadsheet was not slow. It was silent. It accepted a driver with no hours, a temperature no cargo wants, and a delivery nobody could make, and it said nothing about any of it.
The four decisions that mattered
If you read nothing else on this page, read this.
The board knows before the dispatcher does, so a run that cannot legally fit is visible at assignment rather than at pickup.
On a long run the clock binds. On a multi-stop day the sequence and the dwell bind.
Validation catches the typo. Monitoring catches the correct setting on a failing unit, which ruins the same load.
Because the moment proof of delivery is captured is the moment a driver is most likely to have no signal.
Remaining hours are a dispatch input
Canada requires electronic logging on most commercial vehicles, and unlike the United States the device has to be certified by an accredited third party rather than self-certified by its vendor. The market includes a small number of established providers, and the one integrated here is on that list.
That solves the log. It does not solve dispatch, and in most fleets those are two different products with two different screens.
The consequence is quiet and expensive. A dispatcher looking at a board that shows a driver as available assigns a six hour run to somebody with two hours left on their day. The driver refuses, and the load moves late. Or the driver takes it and runs over, and the fleet now owns a violation that a person planned deliberately without knowing they were planning it.
It is harder than it looks because availability is not one number. A Canadian driver is running four clocks at once: driving time today, total on-duty time today, a cycle total across several days, and a mandatory reset that cannot be borrowed against. Loading and waiting consume the second one, which is why a driver can run out of day without having driven very far.
What we did
Hours sit on the driver, next to their location and their trailer. The remaining driving time, remaining on-duty time and cycle position come from the certified device in the truck through the telematics integration, and appear on the same board a dispatcher assigns from.
A run that does not fit is visible at assignment. Not flagged afterwards in a compliance report, which is a record of a decision already made.
The platform reads the log. It does not become one. Compliance is computed by the certified device, and the record of record stays there. What the platform does is make the number available where the decision happens, which is a different job and the one nobody was doing.
Availability is shown as what it is. Four numbers and a date rather than a green tick, because a tick beside a driver with forty minutes of cycle left is telling the dispatcher something untrue.
A violation stops being something a dispatcher can plan by accident. The information that would have prevented it is in front of them at the moment they need it rather than in a different product.
Loads stop being assigned and then refused. Which costs the run, the relationship with the customer, and an afternoon of re-planning.
Planning extends past today. Cycle position makes it possible to see that a driver who is fine now will not be on Thursday, which is the difference between dispatching and firefighting.
The compliance record stays where the regulator expects it. The platform adds a dispatch capability rather than taking on an obligation that belongs to a certified device.
Highway and city, one model
The client runs both, and they are not the same problem with different mileage.
On a highway run the clock binds. Few stops, long legs, and the question is whether the run fits inside the driver's day and where they will be when it does not. Get that wrong and the load does not move.
On a city run other people's schedules bind. Many stops, short legs, and the question is delivery windows, dock availability, and how long each site actually takes rather than how long it claims to. A single site overrunning by an hour does not delay one delivery, it delays every remaining stop on the run.
Software built for one forces the other into a shape it does not fit. A long-haul planner treats a twelve-stop city day as one job. A last-mile planner has no concept of a driver running out of legal hours two provinces from home.
What we did
One model, because the objects are the same. A load, a driver, a trailer and a clock. What differs is which constraint binds first.
The planner surfaces different things. On a long run, hours and reset points. On a multi-stop day, the sequence and the dwell at each site.
Time at a site is recorded, not estimated. Arrival and departure come from the driver's phone, so how long a dock actually takes is a number rather than a belief, and it feeds the next day's planning.
Both kinds of work run on one platform rather than the second one being run on a spreadsheet beside it, which is how the old patchwork started.
Dwell becomes visible. A site that consistently holds trucks for two hours is identifiable, which is the first step to either charging for it or planning around it.
Detention is arguable. Timestamped arrival and departure captured in the field is the evidence a detention claim rests on, and without it the conversation is one company's word against another's.
The planner reflects the job. A dispatcher planning city work is not fighting a tool built for long haul, which is most of why the old tools were replaced.
The trailer reports what it is doing
The incident that made the case for the whole project is worth telling precisely.
Somebody setting a trailer's temperature typed minus fifty instead of fifty. The trailer sat in the yard for three days at the wrong setting, carrying paint. The paint froze and the load was ruined.
The obvious lesson is that spreadsheets accept anything. But it is not the whole lesson. Validation catches the typo. It does not catch the failure. A correct setpoint on a reefer unit that is not holding it produces exactly the same ruined load. So does a unit somebody switched off, a door left open, or a genset out of fuel. The entered value is right and the cargo is still lost.
The real finding was not that a person mistyped. It was that a trailer could sit in a yard for three days doing the wrong thing with nobody watching.
What we did
A setpoint has a range. Temperature is a value with limits appropriate to what is in the trailer rather than a free cell, so minus fifty for paint is refused rather than accepted.
The trailer reports its actual temperature. Telematics brings back what the unit is really holding, so the question stops being what somebody set and becomes what the box is doing.
Divergence raises an alert. A trailer running away from its setpoint, or sitting at one that does not match its load, surfaces in minutes rather than on the third day.
The history is kept. What the trailer actually held, minute by minute, for the length of the journey.
A whole class of silent failure became loud. Not just the mistyped value, but the failing unit, the open door and the empty genset, none of which validation can see.
Three days became minutes. The cost of this category of incident is almost entirely a function of how long it runs before somebody notices.
A cargo claim becomes a document rather than an argument. A minute-by-minute record of what the trailer held is the evidence in a dispute.
The fix generalises. Any monitored condition on a trailer follows the same shape: a valid range, a live reading, and an alert on divergence.
The phone holds its own state
Proof of delivery is captured at exactly the moment a driver is least likely to have a connection. Inside a warehouse. In an underground bay. In an industrial park. On a highway stretch between towns.
An application that requires signal to record a delivery is an application that gets worked around, and the workaround is paper, which is the thing the driver app existed to remove.
A dispatcher looking at a screen where a truck has not moved for an hour needs to know whether the truck is stationary or the phone is out of contact. Those look identical if the platform only renders the last known position, and they mean completely different things.
What we did
Capture happens on the device. A scan, a signature, an arrival or a status change is recorded locally with the time it happened, and syncs when there is something to sync to. The driver's job is finished when they finish it rather than when the network agrees.
Every event carries two times. When it happened and when it arrived. A delivery completed at two and synced at five is a two o'clock delivery, and which timestamp the system treats as authoritative decides a detention claim.
Every event carries its own identity. A phone that regains signal mid-upload will retry, so a repeat has to update rather than create a second delivery against the same load.
Absence of data is displayed as absence. A driver who has not reported for an hour shows as out of contact rather than as stationary, because a control tower that renders silence as a position is telling the office something untrue.
Paper stopped being the fallback. The app works where the work happens, which is the only test that matters for a tool used by somebody standing in a loading bay.
Documents arrive at the source. Proof of delivery and job paperwork reach the office as they are captured rather than at the end of a shift.
The office can tell silence from stillness, which is the difference between a tracking screen and something a dispatcher can act on.
Timestamps hold up. Recording when something happened rather than when it was received is what makes the record usable in a commercial dispute.
One platform, several companies, one shared load
The client is not one company. It is a group, with partner operators running their own drivers, trucks, customers and rates, some of them under partnership arrangements on shared work.
Keeping tenants apart is the easy half. Each company operates in its own space, with its own fleet, staff and commercial data, and nothing of its position is visible to another tenant by default.
Letting them work together is the harder half. A partnered load means one company's truck moving another company's freight. Both need to see the job. Neither should see the other's rates, margin, customer list, driver pay, remaining fleet or any other load they are running.
Sharing is granted per load rather than per company. Access derives from a job somebody is actually on, not from a relationship somebody agreed to once. A partnership that ends does not leave a standing view into a competitor's operation.
Role-based permissions sit above all of it, so what an owner, a dispatcher and a driver see differs inside a tenant as well as between them.
One platform serves a group rather than one system per company, which is where the licensing sprawl came from in the first place. A new partner is onboarded rather than deployed for. And the commercial separation that makes a partnership possible is enforced by the platform rather than by everyone remembering.
The controls underneath
Data stays in Canada. The platform runs in a Canadian cloud region, so operational and fleet data, including driver location and scanned documents, remains resident in the country the operation runs in. For a federally regulated carrier that is a procurement question before it is a technical one.
The operational core is not on the open internet. Services run in private networking with no direct public exposure, and traffic reaches them through controlled entry.
Access is least privilege, per user and per tenant. Fine-grained permissions rather than roles that accumulate, so reaching one company's data requires being in that company.
Documents are protected in transit and at rest, including the scanned proof of delivery and job paperwork arriving from the field, which are the records a freight claim eventually turns on.
Three classes of event are recorded with actor and time. Who assigned or reassigned a load and when. Who changed a trailer's setpoint, and what it was before. And who accessed or exported another tenant's shared load data. These are the three that get questioned afterwards, and the third exists because shared access between partner companies is the place where a mistake would be least visible.
Retention is deliberate. Hours records, delivery documents and trailer condition history all have periods for which they need to survive, set by regulation or by how long a claim can be brought.
Monitoring is continuous, so an integration that has stopped delivering, a device that has gone quiet, or a sync that is failing surfaces as a state rather than as a gap somebody notices later.
Which criteria a fleet platform is judged on
Two of the five trust services criteria carry most of the weight here, and the first is unusual because it is not about the datacentre.
Availability, on this platform, is measured at a loading dock with one bar of signal. The infrastructure can be perfectly healthy and the platform completely useless to the person it exists for, because they are standing inside a metal building holding a phone. That is why capture happens on the device, why events carry two timestamps, and why the office is shown the difference between a truck that is stationary and a phone that is out of contact. Availability of the service is table stakes. Availability of the function, in the places the function is performed, is the engineering problem.
Processing integrity is the second, and the paint incident is the argument for it. A system that accepts a value nobody could have meant, acts on it, and reports nothing has not failed in any way it would notice. Input ranges, live readings compared against intent, alerts on divergence, and a recorded actor behind every change to a load or a setpoint are all answers to that criterion rather than to a security one.
Confidentiality sits underneath both, in the multi-tenant separation, and it is covered above.
The control set was designed against the criteria rather than mapped to them afterwards. That is a statement about how the platform was built. It is not a claim to hold an attestation, and where the operator needs one, the work is theirs to complete with an auditor.
The constraints we designed around
A platform sitting between regulators, telematics vendors, customers and drivers meets constraints set by all four.
Building for all of them on day one is not prudence, it is waste. The work is knowing which to design for up front, which to address when they become real, and which are somebody else's decision to be routed around cleanly.
The truck already has a computer in it
The challenge. Modern trucks and trailers carry their own telematics, and the fleet had a provider the client found expensive, complex and limited. Replacing the hardware is not an option and reinventing what it already does is waste.
What we did. Integrated the vehicle's own systems directly, so location, vehicle data and hours arrive from the equipment already installed and sit alongside dispatch rather than in a separate application.
The fleet moved to modern telematics without a hardware programme, and the data landed where the decisions are made rather than in a second screen nobody had open.
Some partners have a portal and no interface
The challenge. Not every counterparty offers a way for software to talk to them. Some have a web portal a human logs into, and that is the entire integration surface on offer.
What we did. Automated the portal where there was no alternative, and treated it as what it is: a bridge, contained in one place, with the expectation that it breaks when somebody else redesigns a page.
Work that would otherwise be re-keyed by a person happens automatically, and when the far side changes, one component fails rather than a workflow silently producing nothing.
Freight has its own language
The challenge. Shippers and brokers exchange load tenders, status updates and invoices through electronic document standards that predate most of the software in this industry and are not going anywhere.
What we did. Treated it as an adapter into the same internal load model that everything else uses, so a load arriving through a document exchange and a load entered by a dispatcher are the same object downstream.
A customer's preferred way of sending work stops being a reason not to win it, and the operation does not maintain two definitions of a load.
Drivers are the most monitored workers in the economy
The challenge. This platform tracks a person's location continuously, records their hours, and knows how long they spent at every stop. That is necessary to run the operation and it is also continuous employee monitoring, which carries obligations of its own in Canada.
What we did. Kept the data resident in country, scoped access so a driver's detailed movement is visible to the people who need it operationally rather than to anyone with a login, and treated retention as a deliberate period rather than an indefinite one.
The operational benefit is kept and the surveillance surface is bounded, which matters commercially as well as legally. Drivers are scarce, and a fleet with a reputation for watching them badly recruits worse.
Outcomes
Consolidating six separately licensed tools and a spreadsheet onto one platform removed the licensing sprawl underneath the operation. The client reports total monthly operations cost, cloud infrastructure included, falling by roughly six times.
That is a figure about their licensing rather than a measurement of our engineering, and it is stated here rather than in the hero for that reason.
The impact, depending on your job
If you run the business
The saving came from consolidation, not efficiency. Six licences and a spreadsheet became one platform, and the cost that disappeared was the licences. That is a repeatable argument for any operation running a patchwork, and it is more defensible than a productivity claim.
Correct dispatch is a commercial position. A fleet that does not refuse loads, does not run over hours and does not spoil cargo is cheaper to insure, easier to sell to shippers, and better at keeping drivers.
One platform serves the group. A partner company is onboarded rather than deployed for, which is what makes adding one a commercial decision rather than a project.
If you run engineering
The hours integration is the part worth your attention, because it is a modelling decision rather than an integration one. Availability is four numbers and a date, and putting them on the dispatch board is what turns a compliance feed into a planning input.
Then the edge. Capture on the device, two timestamps on every event, identity so retries are safe, and absence rendered as absence rather than as a stale position.
If you run a delivery team
Most of what is on this page came from deciding where complexity lives. One load model for two kinds of work. One adapter per external system, including the portal that has no interface. Sharing granted per load rather than per company.
That last one is the maintainability decision. Access derived from a job somebody is on has no cleanup problem when a relationship ends, which is where permission models usually rot.
If you own the numbers
Licensing sprawl was the cost, and it is gone, along with the overhead of tracking it across six vendors.
Spoiled cargo is a controllable loss. Continuous monitoring turns a three-day silent failure into a minutes-long alert, and the record afterwards is what decides who pays.
Detention becomes claimable. Timestamped arrival and departure captured in the field is the evidence, and an operation without it absorbs the cost silently.
Data residency was an infrastructure choice with a procurement return. Keeping operational data in country removes a question that otherwise arrives in every enterprise conversation.
Talk to the client, not just to us
Everything on this page is our account of our own work. If you are seriously evaluating us, we will arrange a reference call with a client who has been through a build like this one, and you can ask them the questions you would rather not ask us.
Technologies we built with
We name the layers rather than the suppliers on the operational data path, because a supplier map is our client's exposure rather than our credential. Full detail available under NDA.
More case studies
View all case studiesRunning an operation across too many disconnected tools?
Tell us what you're building, and we'll tell you honestly how we'd approach it.