About
Built by people who dispatch
GreetrOne came out of running airport ground transportation in Atlanta — coordinating arrivals for events where flights slip, gate assignments move, and a client's manifest is revised the night before.
The tools available were either decades-old reservation software that treats dispatch as an afterthought, or a rideshare-shaped app that has no concept of a flight, a greeter, or a client who books on behalf of forty people. So we built the thing we needed: one live trip record that clients, dispatchers, drivers and passengers all work from.
It runs real operations every week. Features land because a shift needed them, not because they filled a slot on a comparison chart.
How we build it
One record, many views
A trip is a trip whether a client submitted it, a dispatcher created it or a driver added it on the road. Every surface reads and writes the same record, so there is never a second version of the truth to reconcile.
Built for the bad night
Software is easy to demo and hard to run at 11pm when three flights land late and a driver's phone dies. Offline GPS buffering, audit trails, soft deletes and rate-limited sessions exist because those nights happen.
Meet operators where they are
Nobody is going to abandon the spreadsheet their biggest client sends them. So we read the spreadsheet — and the PDF, and the pasted email — rather than asking anyone to change how they work first.
Everyone sees only their slice
Clients see their organization. Drivers see their trips, and only the passenger details their permissions allow. Dispatch sees the fleet. That boundary is enforced in the database, not in the UI.
Where it's going
Airport work is the hardest timing problem in ground transportation, which makes it a good place to start — but the model underneath (passengers, stops, drivers, live status) isn't airport-specific. Chauffeured and executive work, event shuttles, and adjacent markets all run on the same rails.