Before anything else, one honest statement of where things stand.
Glovebox does not have an RCM-specific importer. It has one for VEVS, built around a known export format. For RCM you use Glovebox's general CSV booking importer, which is genuinely capable, but it means you map your columns once yourself rather than having them recognised automatically.
That is a small extra step, not a blocker. The importer is built for exactly this: arbitrary CSV in, mapped, previewed, then imported.
[REVIEW] Every statement in this guide about what RCM itself does, what it can export, and in what format, is unverified. Nobody has run an RCM export against this importer. Before publishing, do one real RCM export and rewrite the RCM-side specifics from what actually comes out. Until then treat the RCM-side detail here as assumption, not fact.
What transfers
This describes Glovebox's CSV booking importer. Provided your RCM export contains the field, the importer can bring it in.
Required for every booking. The importer needs these mapped before it will run:
- customer first name;
- customer email;
- pickup date and time;
- return date and time;
- vehicle, as free text (matched to your fleet in a later step);
- total in NZD, GST inclusive; and
- an external reference, used as the deduplication key.
That external reference matters more than it looks. It is what stops a second import run creating duplicates, and what lets you trace a Glovebox booking back to its RCM record. Map your RCM booking number or reservation id to it.
Optional, imported when present.
- customer last name;
- customer phone;
- pickup location;
- return location;
- booking status;
- notes; and
- extras, which are appended to the booking's notes rather than recreated as priced line items.
Customers are matched on email address, so a repeat customer becomes one customer record with several bookings rather than several duplicates.
Your fleet is imported separately from a vehicle CSV. The fleet importer accepts a registration column named registration, rego, plate, number_plate or reg.
Dates in whatever format RCM gives you. The importer auto-detects the date format and lets you override it. DD/MM/YYYY, YYYY-MM-DD and MM/DD/YYYY are all supported, with or without times. If your export is American-ordered, set the override rather than editing the file.
Vehicle and location matching. Every distinct vehicle and location value in your file is listed with a suggested match against your Glovebox fleet and branches. You approve them in bulk instead of confirming row by row.
Saved mappings. Once you have mapped your RCM export, save the mapping. A second import of the same export shape reuses it.
What does not transfer
Anything not in your export. The importer reads a CSV. If RCM will not export a field, it cannot come across.
[REVIEW] Confirm what RCM's export actually includes, whether it exports bookings and customers in one file or several, and whether an export is self-serve or has to be requested from RCM. All three change the shape of step 5 below.
Uploaded documents and images. Licence scans, signed agreements and damage photos are not part of a CSV import.
Payment history, unless you handle it separately. The VEVS importer has purpose-built handling that records historical payments against the imported booking. The general CSV importer does not have an equivalent field, so payments taken in RCM will not appear as payment records against imported bookings by default.
This matters for balances: without payment history, an imported booking will look like it has its full total still owing. Read the section on existing bookings below before you import.
[REVIEW] Decide and document the intended approach for RCM payment history. Options include importing bookings with adjusted totals, recording historical payments manually for the small number of bookings still in flight, or extending the importer. Until that is decided, an RCM operator with lots of deposit-paid future bookings needs a person to talk to, not this page.
Extras as priced items. Extras come across as text in the notes, not as configured, priced extras. Set your extras up properly in Glovebox before you go live so new bookings price correctly.
Pricing rules, terms and settings. Rates, seasonal loadings, minimum hire lengths and terms are configured fresh in Glovebox.
Your RCM website content. Glovebox has its own booking site themes and an embeddable widget; page content is not migrated.
Xero history. Imported bookings are excluded from the Xero sync so your migrated back-catalogue does not raise duplicate invoices for money already in your books. Bookings created after cutover sync normally.
The cutover sequence
Same order as any migration: the things bookings refer to have to exist before the bookings do.
1. Set up your workspace. Team, business details.
2. Add your locations, named as they are named in RCM. Matching the names makes step 6 quicker.
3. Import your fleet. Vehicle CSV, then check regos, types and daily rates.
4. Set up pricing and extras. Base rates, seasonal loadings, length rules, minimum hire lengths and extras. Quote some test dates and compare against RCM.
5. Export from RCM. You want bookings with, at minimum, the seven required fields above, plus your RCM booking reference.
[REVIEW] Fill in the actual RCM export path here, with menu names, once someone has done one.
6. Map and preview. Upload under Settings → Import & migrate → Import bookings. Map each required field to a column, approve the vehicle and location matches, then save the mapping.
Then read the preview carefully. This is the step that catches a date format read the wrong way round, which is much easier to fix now than after import.
7. Run the import. It runs in the background and reports what it created.
8. Reconcile. Compare counts and upcoming pickups against RCM. Spot-check bookings. Check deposits and balances specifically, given the payment-history gap above.
9. Point bookings at Glovebox. Publish a Glovebox booking site or embed the booking widget on your existing site. Stop taking new bookings through RCM.
10. Switch over once you are confident.
If something is wrong, fix the file and re-import: bookings deduplicate on the external reference, so the same booking will not be created twice.
What happens to bookings that are already on the books
Future bookings import as live bookings you run from Glovebox.
Bookings currently on hire can be imported and returned in Glovebox, provided the status maps sensibly.
[REVIEW] Confirm how RCM status values map onto Glovebox's booking statuses, and what the importer does with an unrecognised status value. The importer accepts an optional status column; what it accepts as valid input needs stating here.
Past bookings import as customer history.
Balances and deposits need attention. Because the CSV importer does not carry payment history, an imported RCM booking will show its full total as owing even where a deposit has been paid. Before you go live:
- work out which future bookings have money already paid against them;
- decide how you are reflecting that in Glovebox; and
- do that before any automated payment reminders are enabled, so nobody gets chased for money they have already paid.
Glovebox's payment automation defaults to a review queue rather than sending automatically, so nothing goes out without approval on day one. That default is your safety net during a migration. Leave it alone until reconciliation is finished.
Saved cards do not migrate. A customer's stored card lives with your old provider's gateway. Remaining balances are collected through a fresh Glovebox payment link, or at the counter.
Expected timeline
[REVIEW] Estimates written from the shape of the work, not from an observed RCM migration. Replace with real figures after the first one, or remove.
For a single-branch operator with a fleet under about 30 vehicles:
- Workspace, locations and fleet import: half a day.
- Pricing and extras setup: half a day to a day.
- Export, mapping, preview and import: half a day. Expect the mapping step to take longer than the VEVS equivalent, since nothing is pre-filled, but you only do it once.
- Payment and balance reconciliation: depends entirely on how many future bookings have deposits against them. This is the part most likely to take longer than you expect.
- Website or widget: an hour for the embed widget, longer for a new booking site.
Call it two to three working days of actual work, spread across a week or two, with both systems running in parallel until you have reconciled.
Getting help with it
Since there is no RCM preset, the first RCM migration for any given export shape is the one worth asking for help with. Send us a sample export and we will tell you how it maps, or map it with you. If the shape is common we would rather build a preset for it than have every operator work it out again.