What does white-label dispatch software actually include?

White-label means the software carries your brand rather than the vendor's. On AtoZ that is your logo and colours, your own domain, your own passenger and driver apps published under your own App Store and Google Play accounts, and your name on every booking confirmation. Your customer never sees the software company's name.

Key Points

White-label is not a logo in a corner. It is your brand on everything the customer touches.
Your own domain for the booking site, not a shared address with your name in the path.
Your own App Store and Google Play accounts, so the apps are genuinely yours.
Your logo and colours across the booking site, the passenger app and the driver app.
Your name on confirmations, receipts and notifications.
Ask any vendor which app-store account the app is published under. The answer is revealing.

White-label is a word vendors use loosely. Some mean your logo in the corner of their app. Others mean something closer to the whole product being yours. The two are sold with the same sentence and they are not remotely the same purchase.

Here is a test that cuts through it in one question: whose name is on the driver's app in the store, and whose developer account published it?

The Three Surfaces Your Customers Touch

Before anything else, work out where your brand actually needs to appear. For a transportation operator there are three places a customer or a driver looks at a screen, and each one is a separate piece of work for the vendor.

The booking website. Where a passenger goes to get a price and make a reservation. This is the easiest to brand and the one every vendor will show you.

The passenger app. What a repeat customer installs. It carries a name in the app store, an icon on a home screen, and a publisher underneath.

The driver app. What your chauffeurs open at the start of a shift. It is the surface most often left carrying the vendor's brand, on the reasoning that drivers are not customers.

A vendor offering white-label should be branding all three. If the answer is "the booking page, and the apps are ours", that is a legitimate product but it is not white-label, and the price should reflect the difference.

Your Own Developer Accounts

This is the detail that separates the two products, and it is the one most likely to be skipped in a demo.

Mobile apps are published to the Apple App Store and Google Play by a developer account. That account belongs to somebody. If the apps carrying your brand were published under the vendor's account, then the vendor owns the listing, the reviews, the install base and the ability to push an update.

On AtoZ the apps are published under your developer accounts. You hold the credentials. The listing is yours, the reviews accumulate to you, and if you ever leave, the app your customers have on their phones does not disappear with the contract.

It sounds like a technicality until the day it matters, at which point it is the whole thing.

Ask any vendor directly: whose developer account will these be published under? The answer is a fact, not an opinion, and it takes them two seconds to give.

Your Fares, Your Way

Branding is the visible half of white-label. The other half is whether the system can actually price the way you already price, rather than making you price the way it prefers.

Real operators do not use one pricing method. A typical rate card mixes several:

Fixed — a set price for a named journey.
Distance-based — a rate per mile or kilometre, usually with a minimum.
Per passenger — for shared or shuttle work.
Zone to zone — a matrix of areas with a price for each pair.
Hourly — as-directed and chauffeur-by-the-hour work.

On top of those sit the charges that make up the difference between a quoted price and a profitable one: airport pickup and drop-off fees, waiting time, child seats, meet-and-greet, and whatever else your market expects.

Then there are the windows where the price is different: peak hours, public holidays, night rates. These need to be their own rules rather than a manual override you have to remember at one in the morning.

If a system cannot express your existing rate card, you will end up either changing your prices to suit the software or working around it with manual quotes. Both are worse than the software you have now.

Your Dispatching, Your Way

The same principle applies to how a job gets to a driver. Different operations dispatch differently, and often the same operation dispatches differently depending on the job.

Company drivers on your own payroll, assigned directly.

An operator network — other companies you pass work to, and who pass work to you.

Freelancers brought in for peaks.

And three ways of getting the job out: direct assign when you know exactly who should take it, auto-dispatch when the system should decide by rule, and broadcast when you want the first available driver to accept.

A platform that supports only one of these will quietly reshape how you run your business.

Test the Rate Card Before It Goes Live

One practical point that saves more grief than it should. Every tab in the Rate Manager carries an inline calculator, so you can enter a sample journey and see the fare the system would quote before any customer sees it.

Use it properly during setup. Put in the ten journeys you actually do most, including the awkward ones — the late-night airport run with waiting time, the hourly job that goes over, the zone crossing you always have to think about.

If those ten come out right, the rate card is right. If one comes out wrong, you have found it in configuration rather than in front of a customer.

Six Questions to Ask in Any Demo

Take these to every vendor you evaluate, including us. They are all answerable in a sentence, and the ones that are not tell you something.

Are all three surfaces branded — booking site, passenger app and driver app?
Whose developer accounts publish the apps? Mine or yours?
Can the system price the way I price today? Show me my most awkward journey.
What commission do you take on a booking?
Who owns the customer database, and can I export it myself without asking?
What is the total first-year cost — monthly, setup, migration, training, support?

What This Costs, Plainly

White-label in the full sense described above starts at Team 5: $149 a month plus a one-time $499 setup, covering up to five chauffeurs.

Team 25 is $299 a month plus $699 setup.

Team 50 is $399 a month plus $799 setup.

Larger fleets are priced directly.

Setup, onboarding, migration and training are included in those figures, and no plan takes a commission on bookings.

A Team plan is fully live in 21 working days — not a week, and we would rather say the real number than a comfortable one.

The setup fee is published rather than negotiated, so you can see it before you talk to anyone.

Where to Start

The useful next step is a demo run on your own rate card, because that is the only way to answer question three above for your business rather than in general.

If you would rather see the system working before you book time with anyone, there is a short walkthrough available first.

Book a demo · See a quick demonstration

Frequently Asked Questions

Q: What does white-label dispatch software actually include?

A: Your logo and colours, your own domain, passenger and driver apps published under your own app-store accounts, and your name on every confirmation and receipt.

Q: Whose App Store account is the app published under?

A: On AtoZ, yours. This is worth asking every vendor, because an app published under the vendor's account is not really your app.

Q: Does the customer ever see the software vendor's name?

A: Not on AtoZ. The passenger sees your brand throughout.

Q: Is white-label just a logo swap?

A: It should not be. A logo on somebody else's domain, in somebody else's app, is branding rather than white-label.

Q: Does white-label cost extra?

A: Not on AtoZ. Branding is applied as part of setup, which is included in the plan.

What White Label Actually Means