When you outsource dispatch, agents see the booking data they need to do the job — names, pickup and drop-off details, phone numbers, account references — usually inside your own software under their own logins. What they should not have is unrestricted export access, stored card numbers, or your data leaving your systems for theirs. The safeguards to require are access control, your-software working, a data-ownership clause, and deletion on exit.
An operator paused halfway through signing an outsourcing agreement and asked the question he should have asked first: "So a stranger is going to see every customer I have?" It is the right instinct. Your booking history and customer list are among the most valuable things your business owns, and handing anyone access to them deserves more scrutiny than the coverage hours usually get.
The reassuring part is that "who sees your data" has a precise, checkable answer when a provider is run properly. The worrying part is that some providers are vague exactly here, and vagueness about data is the one place you should never accept a shrug.
What agents actually need to see
Start with the honest baseline: agents cannot dispatch blind. To book a job and send a car, an agent has to see the customer’s name, the pickup and drop-off, a contact number, and any account reference the booking runs against. That is the working minimum, and pretending otherwise would mean the agent could not do the job you hired them for.
What matters is that access stops at the working minimum. An agent needs to see the booking in front of them; they do not need the ability to export your entire customer database, browse historical bookings unrelated to the call they are handling, or reach data that has nothing to do with dispatch. The line between "enough to work" and "everything you have" is the whole security question.
Access control: least privilege, named logins
The first safeguard to require is that agents work under their own named logins inside your dispatch software, with permissions set to what the role needs and no more. Shared generic logins are a red flag — they make it impossible to know who did what, and they usually mean access is broader than it should be.
- Individual named accounts, so every action is attributable to a person.
- Role-based permissions limited to dispatch functions, not admin or export.
- Access that can be revoked immediately when an agent leaves the provider.
- No standing ability to bulk-export your customer list.
Your software, not their spreadsheet
The single biggest data-handling decision is where the work happens. When agents book directly into your existing dispatch platform, your data never leaves your systems — it stays under your control, your logins, your audit trail. That is the setup you want.
The alternative is the one to avoid: a provider who takes bookings in their own system and forwards them to you. That copies your customer data onto their infrastructure, outside your control, governed by their security rather than yours. It also introduces a re-keying step and its errors. If a provider cannot work inside your software, ask hard questions about where your data ends up and who is responsible for it there.
Real-time driver coordination and routing around the clock — overnight, weekends, holidays, and peak surges covered.
Payment references: what should never be stored
Payment is the most sensitive category and deserves its own rule. Agents may need to see that a booking is on account, or reference a payment method a customer has on file, but they should not be handling or storing raw card numbers. Card data belongs in a compliant payment system, not in a booking note or an agent’s reach.
Ask a provider directly how payment information is handled. The right answer involves tokenized or referenced payments where the agent sees "card on file" rather than the number itself, and no card details written into free-text fields. A provider who is casual about card data is a provider you should not give card data to.
Data ownership and deletion on exit
Get it in writing that the data stays yours. The contract should state plainly that your booking history, customer details and account information belong to you, not the provider, and that the provider has no right to use them for anything beyond running your account. This is the clause that stops your customer list becoming someone else’s asset.
Equally important is what happens when you leave. Confirm that on exit your data is returned to you in a usable form and deleted from the provider’s side, with confirmation that it is gone. A provider confident in their model has no problem with this; one who gets cagey about deletion is telling you where your data would live after you walked away.
What to require before you sign
You do not need to be a security expert to protect yourself here — you need a short list of non-negotiables and the willingness to walk if a provider will not meet them. Require named logins with least-privilege access inside your own software, a clear rule that raw card data is never stored by agents, a written data-ownership clause, and deletion on exit. Ask how access is granted and revoked, and who is accountable when something goes wrong.
Every one of these has a clean answer from a provider who takes data seriously, because they have been asked before and their model holds up. If the answers are vague during the sales conversation, when they are trying to win you, assume the handling is no tighter once your customers’ details are already on their systems.
Common questions
Where this guide fits: it is part of the operator guide library. Next step: try the desk free for your first week.
Daniel Okoro is TransportBPO's Content Editor and Dispatcher — a former dispatcher who moved into editorial after years running live boards for taxi, NEMT and trucking accounts. He writes from dispatch-floor experience, not the marketing department, on what actually keeps a 24/7 desk running.
Connect on LinkedIn