Wave Ride — Replacing a 3-coordinator dispatch desk with one AI booking agent

The problem we were solving

Wave Ride is a multi-tenant rideshare and delivery platform serving Duke University, the Charlotte Hornets, healthcare partners, universities, and corporate fleets. Before the rebuild, every ride request lived inside a manual coordination loop — three full-time dispatch coordinators answering phone calls, watching Slack channels, and routing orders into our dispatch system by hand.

That model didn't scale. The window where a rider's question goes from "I want a ride" to "I'm in the car" is short, and humans can't read four channels at once. Jobs were getting missed. Late-night requests went silent. New tenants with their own ops teams couldn't be onboarded without hiring more humans.

The brief was simple: replace the coordination layer with software that's awake 24/7, multi-tenant by default, and friendly enough that riders actually use it.

Wave AI: three messages to a confirmed ride

The headline product is Wave AI — a conversational booking agent that takes a rider from "I need a ride to the Hornets game" to a confirmed pickup in three exchanges. It runs natively across text, chat, and voice (RingCentral wires the phone side), so a rider doesn't need to download anything or learn a workflow.

Under the hood, the agent does a lot of unglamorous work most "AI chat" demos hand-wave past:

• Intent parsing with structured-output prompts that capture origin, destination, pickup window, party size, and special needs (wheelchair-accessible, child seat, pet)
• Geocoding via Google Maps with fallback heuristics for ambiguous landmarks ("the arena", "Duke East")
• Pricing against tenant-specific rate cards including AD-style mileage formulas and holiday surcharges
• Confirmation before submitting to the external dispatch system, with idempotent retry

The result: riders book in seconds, and the agent handles the entire happy path with no human in the loop.

The dispatch engine: VRP + Clarke-Wright + Google Route Optimization

Multi-stop routes — common in healthcare transport and corporate shuttle workloads — need real route optimization, not "as the crow flies" greedy assignment. Wave's dispatch engine combines a Clarke-Wright savings algorithm for initial cluster formation with Google's Route Optimization API for time-window-aware refinement.

The engine produces driver assignments that respect:

• Multi-leg pickups (one driver, multiple riders, sequenced stops)
• Time windows (pickup-by and arrive-by constraints from healthcare appointments)
• Vehicle capability (wheelchair-accessible, sedan, SUV)
• Driver-rider proximity via a GeoFire spatial index

Dispatch rounds run as part of a larger orchestration: when an order enters the system, an invite flow offers it to drivers in proximity tiers, with each tier given a short acceptance window before the system rolls forward. If nothing is accepted, the order falls back to a wider radius, then to the external AD dispatch system. All of it is observable through a Slack-based ops console.

Forty-two cron jobs holding the pipeline together

A platform like this lives or dies on its background work. Wave runs 42 Vercel cron jobs that handle the unglamorous parts of operations:

• Polling the AD dispatch system for trip state changes
• Reconciling tenant-specific orders against the upstream
• Refreshing driver locations into GeoFire for proximity queries
• Sending pre-pickup reminders via SMS and push
• Recomputing pricing for in-flight orders when surcharges shift
• Sweeping stale invites and re-queueing them

Each cron is small, idempotent, and observable. Together they're the central nervous system of the platform.

The Slack bot nobody else writes

One of the more unusual pieces of the Wave stack is a Slack bot that scrapes orders out of operations channels. Dispatchers and partner teams had years of muscle memory dropping ride requests into Slack as free text. Rather than retrain everyone, we taught the bot to listen — it extracts structured ride requests from messages, posts a confirmation back into the thread, and submits the order through the same pipeline the AI booking agent uses.

It's a quiet feature, but it's the difference between a platform that ops teams adopt and one they grudgingly tolerate.

Wave Bites: the catering platform riding on the same infra

Once the dispatch engine, pricing layer, and notification system were stable, we shipped Wave Bites — a consumer-facing catering marketplace — on top of the same core. Restaurants list menus, customers schedule orders, drivers from the Wave fleet handle delivery. The economic case for building it on the same platform was straightforward: every component except the menu surface was already running for ridesharing.

Architecture in one paragraph

Next.js 16 App Router on Vercel. Firebase Firestore + Realtime Database for the operational data (with a dual-project architecture that mirrors against the external AD dispatch system in real time). Stripe for payments. OpenAI GPT-4o powers the booking and admin agents. RingCentral handles the SMS and voice surface. Mapbox + Google Maps for geocoding and routing. Slack for ops. Subdomain-based multi-tenancy with middleware-level routing so each tenant gets its own branded surface and rate cards.

What changed for the business

• 3 full-time coordinators of work absorbed by one always-on agent
• 94% driver retention (per the public waveride.ai stats)
• $812 average weekly driver earnings
• Wheelchair-accessible routing in production for healthcare partners
• New tenants can be onboarded without hiring new coordinators

What I'm taking from this

Wave is the proof — for me, and for prospects evaluating Averything — that AI agents in service businesses aren't a demo. They're a coordination layer that runs alongside humans, gets dispatched alongside drivers, and absorbs the work that used to eat someone's day.

The same playbook ports almost directly: every service business has a coordination loop. Most of those loops can be automated. The interesting engineering is in the integrations, the cron orchestration, and the human-readable fallbacks — not in the LLM call itself.

If you're running a coordination-heavy operation and wondering if this pattern applies to you, let's talk.