Freight moves whether or not your systems do. We build the tracking, the driver app and the proof of delivery your customers ring you about, and we keep the depots online behind it.
Most operators have plenty of vehicle data. What they lack is one screen where the telematics feed, the job list and the time promised to the customer all line up. We pull those sources together and settle which one is right when they disagree, so a planner stops opening four tabs to answer one question. That same view feeds the tracking page your customer sees, which means the office and the customer are reading the same information.
Coverage drops in loading bays, on rural routes and inside industrial estates. An app that needs a connection to save a signature will lose one sooner or later. We build the driver app to work offline by default. The job list, the scan, the photograph and the signature all save on the handset and upload when the phone finds a network again. The driver never has to know which state it is in, and the office sees the delivery land as soon as the van comes back into coverage.
A booking system that is down through a loading window costs you the rest of the day. We monitor the platforms your operation runs on and cover the hours the operation actually runs, which is rarely nine to five. Depot links get a second path so a cut fibre does not stop dispatch. Enough runs locally at the depot that scanning continues when head office is unreachable, and spare handhelds sit on a shelf in the depot rather than arriving by courier tomorrow.
Every record on this page is created by somebody standing at a door in the rain, holding a parcel, with the engine running and twenty drops still to make. That is the design constraint, and it beats every opinion formed in an office. A form with twelve mandatory fields gets the same answer typed into all of them by Thursday. A photograph screen that hands off to the phone camera and comes back having lost the job is the reason a driver keeps a paper sheet in the cab. So we build for one thumb and one hand: scan, photograph, signature, done, with a normal stop closing in three taps and the exceptions behind one clearly labelled button. Anything a planner wants captured has to earn its place against the drop the driver is now late for.
Proof of delivery is worth what your customer's claims department will accept, so it is worth deciding early what that is. In practice it means a photograph where the door number or the pallet label is legible rather than a picture of a wall, a timestamp taken on the device and stamped again on arrival so a drifting handset clock cannot be argued with, a location fix with its accuracy recorded rather than implied, and a printed name as well as a scribble on glass. All of it attaches to the consignment rather than to a media folder somebody has to go and search. Then it has to survive, because claims arrive months later, which makes retention a contract question rather than a storage setting.
The manifest, the stops and the forms travel with the van. Work is recorded on the handset where it happens and the sync resolves on the way back into coverage, without the driver ever needing to know which state it is in.
Signature, photograph, timestamp and location captured at the door and attached to the consignment, so a dispute that used to take a day of phone calls is answered while the customer is still on the line.
A page per consignment showing the state, the promised window and the delivery record. Most of the value is measured in calls the office no longer takes rather than in anything on the screen.
Goods in, sortation, loading and trunking scans that move a consignment when the barcode is read, with enough running locally that a head office outage does not stop the bay.
Vehicles, jobs, remaining driver hours and the time promised in one view, so a planner stops opening four tabs to answer one question and can see what moving a drop does before moving it.
Bookings, status and invoicing moving over EDI, an API or a file drop, chosen for what your customer's system can actually do rather than for what its brochure claims it does.
We build against the TMS rather than around it, using the API where there is one and an export, a database view or a file drop where there is not, with the integration kept in one place.
Where a WMS owns stock and location it stays the owner and everything else reads from it. Two systems each believing they own a pallet is how a trailer leaves without one.
Position, engine data and remaining driver hours from the vehicle side of the operation, joined to the job, so a planner sees one truth rather than a map in one window and a job list in another.
Bookings and status messages exchanged in whatever your customers run, including the ones still sending flat files. Larger shippers set the format, and their onboarding queue usually sets your timeline too.
Rugged units and phones, with the hardware trigger and barcode engine used as such rather than emulating a keyboard, and a spare on a shelf in the depot rather than arriving by courier tomorrow.
Rate cards, surcharges and self-billing reconciled against what was actually delivered, because the gap between the job record and the invoice is where margin quietly leaves a haulage business.
Not the whole fleet. One depot, one set of drivers, four weeks. It settles the question of whether drivers will use it faster than any amount of specification.
Usually asked for by whoever answers the phone. It is a small build against data you already hold, and it is the change customers notice first.
Both feeds normally exist already and disagree. Deciding which one wins when they do is most of the work, and it is a decision your operation has to make rather than us.
A second path for the depot link, and enough running locally that scanning continues when head office is unreachable. Rarely urgent until the morning it is.
It has to, so it is built offline first. The manifest, the stops and the forms come down with the driver, the work is recorded on the device where it happens, and the sync resolves when coverage returns. Anything else produces the outcome we are usually called in to fix, which is drivers keeping a paper copy because they do not trust the app.
That is normally the first thing built. A signature, a photograph, a timestamp and a location captured at the door, attached to the consignment and available to whoever answers the phone when a customer disputes it. The value is not the technology, it is that the argument ends in seconds instead of a day of phone calls.
We build against what you run rather than around it. Where the system has an API we use it; where it does not, there is nearly always an export, a database or a file drop that can be worked with. The integration layer is kept in one place so that changing or replacing that system later is a contained piece of work rather than a rebuild.
By sampling deliberately rather than continuously. Location is captured at the events that matter, at a frequency chosen for the route length, with the collection stopping when the shift ends. A tracking app that flattens a phone by lunchtime gets switched off by the person carrying it, which loses you the data entirely.
Possibly not, and it is oversold. Optimisation pays when you have dense multi-drop rounds, service windows that hold, and a planner willing to accept the output. It pays badly when half the work is booked the same morning, when three sites have gate curfews the system does not know about, and when the planner overrides it anyway because he knows which yard needs the smaller vehicle. In those operations the money is in giving the planner better information rather than a new algorithm to argue with. If you want to test it, run an optimiser against last month's real rounds and compare the result with what your planner actually did, before anybody buys anything. We will tell you if the answer is no.
Both work, and the decision is about breakage and control rather than software. Rugged units survive a tail lift, hold charge through a long shift and can be locked to the app, but they cost several times what a phone costs and somebody has to own the spares. Personal phones cost nothing to buy and remove the spares problem, at the price of inconsistent camera quality, battery levels you do not control, and a leaver walking out with the app and the data still on the device. If you go that way, insist on device management and a clean removal process for leavers. For subcontractors it is usually the only realistic answer, because nobody is issuing hardware to a haulier who works for four other people.
Longer than most operators plan for, because the claim arrives long after the delivery did. Set the period from your customer contracts and your insurers rather than from whatever default the software shipped with, then design for the storage that implies. Photographs are the bulk of the volume, so they get sized sensibly, stored once, and moved to cheaper storage after the window where they are looked at daily. Retrieval matters more than retention, because a record nobody can find is the same as no record. The search has to work by consignment number, by date, by customer reference and by postcode, and it has to be usable by whoever happens to pick up the phone.
Yes, and they should, because the consignments you cannot see are the ones that generate the complaints. The difficulties are commercial rather than technical. A subcontractor already carrying two other customers' apps will not welcome a third, their drivers turn over, and nobody can make them charge a device overnight. So the version they get is deliberately thinner, runs on their own phones, and needs no training beyond a scan and a photograph. Where a pallet network or a partner runs its own system, we take their status messages and translate them into your states rather than asking them to change, which is the only version of this that survives contact with a busy operation.
We are happy to answer any questions you have and help you work out which of our services fit your needs.
