Managed services
What our teams take on, and where the boundary sits.
TheHubb runs three parts of a delivery operation with its own people: hiring, dispatch and fleet. This page is what each team does, what stays with yours, where the software sits underneath it, and how an engagement is actually run.
Why software alone was never enough
This is not an argument against software; we sell that too. It is the four places where a system finishes its part and a person has to start, which is the reason this company runs operations as well as building them.
Software tells you a driver did not show. It does not find another one.
The record is accurate within seconds and the route still has to go out. Between those two facts is a person making calls at six in the morning, and no amount of reporting removes that step.
Most of the day is exceptions, and exceptions are judgement.
A system can show that a route is running long. Whether to send a rescue, pull someone off another block or let it land late depends on things no system holds — who is close, who is already over hours, and what was promised to the station.
A tool adds a job before it removes one.
Somebody has to operate it, keep it current and act on what it says. On a management team of three, that somebody is usually the person whose actual job is running the operation.
The work does not wait for the software to be finished.
StaffFlo is not released. The hiring and scheduling work it will eventually hold still happens every morning, and today the teams below are how it gets done.
So the split is not software against services. It is that one part of an operation can be made into a system, one part cannot, and both still have to be run by someone.
The three services
Each one is a team of our people doing named work inside your operation. For each: the problem it exists for, what the team takes on, what stays with yours, and what should actually change.
Hiring and onboarding
End-to-end DSP HR & recruiting
We source, screen, onboard and keep your drivers — and we own the outcome, not just the pipeline.
The problem
Driver hiring is continuous, not seasonal. Stop sourcing for two weeks and the board feels it a month later, by which point the fix is overtime. The work itself — sourcing, screening, chasing documents, getting someone actually road-ready — is a full job, and on most operations it sits with whoever has an hour spare.
We take on
- Sourcing through to day-one readiness
- Background, licence and compliance checks
- Onboarding paperwork and records
- Retention and exit handling
You keep
- The hiring bar, and the final yes
- Pay rates and what you offer
- The headcount you carry
What to expect
Hiring stops being something that happens when someone finds time. The pipeline, the paperwork and the chasing belong to a team whose whole week is filling your seats, and when a start date moves there is one place to ask why.
Daily board and exceptions
DSP dispatch services
A dispatch team that runs your board — rescues, reassignments and exceptions handled before they cost you the day.
The problem
The board is built the night before and starts being wrong at six in the morning. Callouts, rescues and reassignments are not interruptions to the work — they are the work, and each one is a phone call, a decision made on incomplete information, and a record that has to be corrected afterwards.
We take on
- Daily board build and driver assignment
- Live exception handling and rescues
- Station and driver communication
- End-of-day reconciliation
You keep
- The commitments the board is built against
- When we escalate, and to whom
- Anything that changes what the day costs
What to expect
The day is run by people whose only job that day is running it. Exceptions, calls and the end-of-day reconciliation stop being handled by your managers in the gaps between everything else they are doing.
Vehicles and uptime
Fleet management services
Vans kept road-ready and accounted for, so you are never paying for capacity you cannot dispatch.
The problem
A grounded van is not a maintenance problem, it is a capacity problem: you are paying for a vehicle you cannot dispatch and holding a driver you have to put somewhere. Inspections, damage records and repair follow-up are administrative work that no day has room for, so it stays quiet until the morning it costs you a route.
We take on
- Inspection scheduling and records
- Damage, repair and downtime tracking
- Grounded-vehicle follow-through
- Utilisation against authorised count
You keep
- The vehicles and the leases
- Repair and replacement spend
- How much capacity you want on the road
What to expect
Vehicle status becomes one team's responsibility instead of everyone's assumption. The follow-up actually happens, and the vans you are paying for are accounted for against the count you are authorised to run.
These three are what exists today. There is no fourth service, and we do not take on work outside them.
Where the software fits, and where it does not
Software and services are sold separately, so none of this is a requirement. But the teams work on the same platform the products are built on, and that changes what the arrangement looks like from your side.
MileMargin
The station day our dispatch and fleet teams work from is the record MileMargin reconciles — the same record, not a copy of it. If you use the product, you are reading what we are reading, which is why there is no weekly summary to wait for and nothing to reconcile between your view and ours.
Explore MileMarginStaffFlo
Not released. The hiring, scheduling and attendance work it will eventually hold is done by people today, which is what the hiring team and the dispatch team are for. When it ships, part of what a person does now becomes something the software does — and we will say which part, rather than quietly reducing what a team covers.
Explore StaffFloThe part that stays human
Nothing on the platform makes a phone call, decides which route to rescue first, or tells a driver their van is grounded. Work that involves persuading someone, deciding under time pressure, or being answerable to a person is a person's job, and it will stay one however good the software gets.
Software makes an operation legible. It does not run it.
How an engagement works
Four things worth knowing before signing anything: how it starts, how the boundary is agreed, how we communicate while the work is running, and what gets reviewed. Where something varies with the scope it says so, because a number invented for a website would be the easiest thing on this page to write and the first thing to break.
How it starts
The same way any engagement here does — a conversation, then a scope, then a quote — and that process is written out in full elsewhere rather than repeated here. What is specific to services is what the scoping produces: not a licence, but a written boundary.
What happens when you get in touchHow responsibilities are agreed
The two columns above are the shape of the boundary, not its contents. Yours are written per service and per station, and they are what you sign: the work we run, named, and the decisions that stay with your team. If it is not in that document, it is not ours. Escalation is one of the things you keep — when we escalate and to whom is your decision, written into the scope rather than set by us.
How communication works
You can name the people doing the work; a managed service here is not an anonymous queue. There is no separate service portal, because none exists — the work happens through your operation's own channels and on the shared record. How often we meet and with whom is agreed when the work is scoped: a dispatch team is in the day with you and a fleet team is not, so a single cadence quoted on a website would fit neither.
What gets reviewed
The scope, because it is the only thing both sides agreed to. There is no published service level, no response-time commitment and no coverage figure attached to any of these teams. A review covers whether the work in the scope is being done, what has changed about the operation, and whether the boundary is still in the right place — boundaries move, and one that never moves is one nobody is checking. How often that review happens is part of the agreement, and it varies with what is in scope.
Who gets the most out of this
The shape of an operation decides this more than its size does.
The work is already being done by someone too senior for it
If the person who should be running the station is also the one chasing van repairs and screening applicants, this is the case the services were built around.
More than one station
The same exception happens at every station and is currently being solved separately at each one. One team answering for all of them is a different arrangement from three managers each meeting it fresh.
You want the outcome owned, not the seat filled
We answer for the work, including when it goes wrong. That is the difference from hiring someone to sit in the chair, and it is most of what the arrangement is actually for.
Growth is outrunning the management layer
Stations and vans can be added in weeks. A manager who understands your operation cannot. Services are the layer you can extend without making that hire first.
Who this is not for
Said here rather than discovered on a call.
You want extra hands under your own direction
That is a staffing agency. It is cheaper, and for that requirement it is the better answer. We take work on with the decisions attached to it, so if every call has to come back to you first, you are paying for accountability you are not using.
The function does not exist yet
A managed service takes over work you already run. If nobody at your operation does this today, we would be defining the job as well as doing it — a longer conversation, and a different one. Ask anyway, but expect that answer.
You need something other than these three
Hiring, dispatch and fleet is what exists. Adjacent work — payroll, safety, driver coaching — is not something we run today, and stretching a scope to cover it would be the first broken promise rather than the last.
Three more disqualifiers apply to any engagement rather than to services specifically: certification requirements, operations outside Amazon DSP work, and needing to buy without talking to anyone. They are answered where the first conversation is described.
Who this is not for, todayBefore you engage
Four questions that come up specifically about handing work over.
Whose employees are these — yours or ours?
Both, and the split is the point. Drivers are yours: you carry the headcount, set the pay and make the final hiring decision, whoever did the sourcing. The recruiting, dispatch or fleet team doing the work is ours — our people, managed by us, not subcontracted on to anyone else. That is why there is one company to hold responsible instead of two.
Can we start with one service?
Yes, and it is often the recommendation. Each is scoped and priced on its own. There is no bundle that requires the other two, and taking one does not commit you to the rest.
How many of your people will be working on our operation?
That depends on the scope, and you will get a number once there is a scope to base it on. Anything said before we know how many stations and which services are involved would be a guess, and it would arrive looking like a commitment.
What if the scope turns out to be wrong?
Then it changes deliberately rather than drifting. If work we do not run keeps landing on us, or something we do run should go back to your team, that is a scope change and a revised agreement — not something that happens quietly and gets discovered in month four.
What a quote is built on, what the agreement covers, and how an engagement ends are all answered on the page that owns them.
What a quote is built onThe useful version of this conversation is not whether managed services are a good idea in general. It is which of the three you would actually hand over, and what you would want to keep.
Book a demo