Moving off Dever Software: what comes across, what doesn't

Dever's DISPATCH product is a broad system. It covers chauffeur work alongside private hire, airport, cruise, ferry and courier jobs, and it produces driver payslips inside the dispatch tool. Kairo is narrower. It keeps one live record for a pre-booked chauffeur job from enquiry to invoice. If you are moving between the two, the honest question is not whether every feature has a twin. It is which of your records survive the move, and which you have to rebuild.

This post answers that from the importer code. Where Kairo does not carry something across, it says so.

How Kairo recognises a Dever export

Kairo's importer accepts CSV and Excel files. It reads the header row and looks for a column called Booking Class. That column is the marker for a Dever bookings export, and it switches the importer into Dever mode. The practical difference is the Vehicle column: in a Dever file it holds registrations, so Kairo treats it as a registration and creates fleet vehicles from it. In most other systems a "Vehicle" column holds a class name like "S-Class", and Kairo deliberately does not turn those into vehicles.

The columns that map without any work

These Dever headers map straight to a Kairo field, exact match, no guessing:

• Date-Time, Booking Ref and Status
• Account Number and Account Name
• Main Passenger / Contact, Telephone, Email and Num. Passengers
• Itinerary, Flight Details, Mileage and Duration (mins)
• Driver, Driver Tel, Booking Class and Vehicle
• Fare, Total and Payment Type
• Driver's Instructions and Booking Notes

Itinerary needs one note. Dever writes the whole route into that one column. Kairo reads it as the pickup and, where the text contains " to ", splits the remainder off as the drop-off. A multi-stop itinerary written in prose stays as text on the job for a person to tidy. It does not become structured via stops on its own.

Any column outside that list goes through a second, fuzzy pass that matches common header wording (a column called "Drop Off" or "Reg", for example). Whatever is still unplaced after that shows up as Skip on the mapping step, and you can pick a field for it by hand or leave it out.

What Kairo builds from those rows

One import run creates or matches five kinds of record for your tenant. Contacts come from the passenger name, phone and email. Clients come from the account name, matched on name so a repeat import does not duplicate an account. Partner companies come from drivers whose row names a subcontracting company, and those drivers are marked as subcontractors. Drivers are matched by name; an existing driver's phone is filled in only if it was blank, never overwritten. Vehicles are keyed on registration, with the booking class attached. Then the jobs themselves, one per row.

Two behaviours matter on the day. Matching is by name or registration, so run the import from one clean export rather than several overlapping ones. And imported drivers are created inactive until they sign in to the driver app, so nothing is dispatched to a phone that has not been set up.

What does not come across

Invoices do not. Kairo does not build invoices from a bookings export. Your historic invoices stay in Dever, or in whatever read-only export you keep of it, and Kairo raises new invoices from the date you switch.

Payment state mostly does not. A standard Dever bookings export has no paid, amount-paid or invoice number columns, and the importer is written on that assumption. If your export does carry one of those columns (Paid, Payment Status, Amount Paid, Invoice No and a few variants), Kairo reads it as evidence for its settlement reconciliation, but it does not mark jobs as paid on the strength of a single row.

Rate cards do not. There is no tariff column in a bookings export, so per-mile and per-minute rates are rebuilt in Kairo and checked against a sample of historic jobs. That check is the part of a switch that catches most surprises, and it is why the switching page asks for a rate-card sample before anything else.

Driver payslips do not. Kairo does not produce them, and the Dever comparison says plainly that an operator who relies on that feature should stay put.

The import weekend, in order

Export bookings from Dever on the Friday evening after the last amendment. Upload the file to Kairo, confirm the mapping step (the Dever headers should already be placed), and review the preview. Import, then let the enrichment pass run. Check the counts: clients, drivers, vehicles and forward bookings should agree with Dever's own totals. Rebuild the rate card and price five or six historic jobs to confirm they return the figures you actually charged. From Monday, key new bookings in Kairo only and reconcile each day's sheet against Dever for a week before you cancel.

If you would rather Kairo ran that checklist for you, the Managed Launch service does it for a fixed £495. It comes with a written guarantee: if Kairo misses the agreed checklist, you choose between a refund of that fee and continued work at no further charge. The DIY route has no setup charge and no such guarantee; the software subscription is the same either way, priced by fleet size on the pricing page.

Two things to know before you start

Kairo has a purpose-built importer for Dever exports today. It does not yet have one for Limo Anywhere or iCabbi. Exports from those systems go through the generic header matching described above, which works for well-labelled files but needs more hand mapping. The Limo Anywhere comparison covers where that system differs for a UK operator.

And bring a real file. One historic booking and a rate-card sample tell you more about your migration than any feature table. Send them through the founding pilot route and Kairo will return a written scope and exception list, or open a free trial and run the export through the importer yourself.