JollyDrivers

A booking platform built for the operator who wants to stay out of the way

JollyDrivers (JD) is booking and back-office software for small, hands-off rideshare operators in Australia and the drivers who work for them. It takes the booking, lets the driver run the job, and does the operator's invoicing in the operator's own Xero. The operator only steps in when something needs them.

Most rideshare software is built for a dispatcher who treats drivers as interchangeable. JD is built for the other half of the industry: chauffeur and executive transport, airport and regional transfers, fleets of about 3 to 15 vehicles where the owner knows every driver, and single-driver operators who are both the business and the driver. In that world the relationship between a rider and a driver they trust is what keeps the business going, and JD is built around it.

What makes it different

Booking by conversation

Riders book by talking to an AI assistant (Anthropic's Claude) instead of filling in a long form. It collects pickups, stops, times, flights and passengers, checks the addresses against Google Maps, and hands a finished booking to the operator. The same assistant handles goods deliveries and "attendance" jobs, such as walking a dog or watering a garden, where the job is a description rather than a route.

One door into the booking record

Whether a booking arrives through the chat, an operator's own form or a rider's public booking page, it goes in through one shared path that checks the same rules every time. Every change to a booking is recorded as an event, and the rider's, driver's and operator's screens update live from that record. Nobody has to refresh, and there is always a history of who did what.

The operator's books stay the operator's

JD raises, approves, amends and voids invoices and records payments directly in the operator's own Xero organisation, in the operator's name, under the operator's numbering. JD does not have its own ledger for the operator to reconcile against. The operator's accountant sees normal Xero invoices.

One workspace for a driver, however many operators they drive for

A driver who works for three operators sees one calendar and one set of trips. Each job carries its own operator's context. Because JD can see the driver's whole week, it flags schedule conflicts across operators, including overlapping jobs and not enough travel time between them. Each operator is only ever shown its own bookings. The warnings are advisory: JD never declines or reassigns a job on its own.

Compliance evidence, not compliance theatre

JD keeps the records operators need when an auditor calls: trip records, driver hours and fatigue signals, compliance documents with expiry tracking, training completions and published safety management plans. It exports them as an audit-ready pack. JD produces the evidence. The operator and the driver stay accountable, as the law says they are.

No surge, and a fee that never rises with the fare

Fares come from the operator's own fare book: flat suburb-to-suburb prices, plus per-kilometre and waiting rates they set themselves. Nothing in JD changes price with demand, and JD works out no share of a fare for itself. Its charge is a flat fee to the operator on each settled booking — never to the passenger, and it never rises with the fare. The FAQ gives the amount.

What JD deliberately is not

Who it is for

Connect your AI

An AI assistant that speaks MCP can ask JollyDrivers directly, instead of only reading these pages. Add https://jollydrivers.com.au/mcp to Claude, ChatGPT, Gemini or any other assistant that supports MCP. That endpoint needs no account, every tool on it is read-only, and its answers come from files that shipped with the release, plus JollyDrivers' own published contact address — it reads no bookings and no personal data. The account endpoint below is a different thing: it acts for one signed-in person, and some of its tools write.

How it works, role by role