? Learn / Pricing, risk & operations for modern rental fleets

A practical guide to modern rental operations.

This is where we write down what we’ve seen in the real world: risky card flows, messy deposits, “DM to book” chaos, and how to move to a transparent, Stripe-backed booking experience your clients actually trust.

Use these guides to pressure-test your current process, sharpen your pricing model, and decide whether a system like Dromium makes sense for your fleet.

Built from real rental experiences Focus: pricing, risk, deposits & operations

Start here

Why card photos over email are a problem (and what to do instead)

The story that started Dromium: high-value cars, card photos sent over email, and clients hoping nothing goes wrong. We’ll break down the risks and the Stripe-backed alternative.

~7 min read · Full guide below

Talk to us

Want to walk through your current process—spreadsheets, inbox, deposit rules, owner splits—and see where a system could help?

Book a 30-minute session

Pricing & revenue

How to charge in a way that makes sense to clients and still protects your margins: rental length, km allowances, extras, seasons and penalty fees.

Guide

Designing pricing that matches how people actually rent

How to combine base rates, day/km bundles, weekend vs weekday pricing and premium add-ons —without creating a pricing table nobody understands.

Covers: seat-of-the-pants pricing vs. model-based pricing · Full guide below

Framework

The “minimum booking” you actually want

Short, cheap bookings look good on a busy calendar—but often destroy margins. A simple way to reason about minimum days, pricing and utilization.

Includes: a simple back-of-the-envelope calculation

Checklist

Extras, penalties and the fine print

Additional km, tolls, cleaning, late returns and damage. How to make them clear up front so clients don’t feel surprised later.

Good input for your T&Cs and checkout copy

Deposits, holds & risk

Security deposits are where trust can either break or deepen. These guides look at how to structure holds, communicate clearly and handle edge cases.

Deep dive

Card photos vs. Stripe holds: what changes

The difference between emailing card photos, manual pre-auths and automated Stripe holds—with examples of what your client sees in each case.

From “just trust us” to bank-backed clarity

Template

A simple deposit policy you can actually explain

A plain-language structure you can adapt: when the hold is placed, how long it stays, when you charge vs. release, and what happens if there’s an incident.

Written for both your T&Cs and your staff

Playbook

Notes, photos and timelines: documenting the boring parts

How to combine checklists, photos and internal notes to de-risk high-value bookings—and make disputes easier to resolve.

Pairs naturally with Dromium’s booking timeline

Operations & workflows

What it looks like to move from “DM to book”, scattered spreadsheets and gut feel—to a shared system that operations, risk and finance all trust.

Guide

Why “DM to book” quietly kills your calendar

The hidden cost of taking bookings across WhatsApp, Instagram and email, and how a widget + dashboard combo changes the shape of your day.

Good to share with owners and partners

Pattern

One source of truth for each booking

Everything in one place: payments, holds, notes, documents, handover photos and status. What that does for handovers and hand-backs.

Exactly what Dromium’s booking view is built around

Checklist

Questions to ask any rental software vendor

A vendor-agnostic list: pricing flexibility, deposit control, Stripe integration, audit trails, export options and support expectations.

Use it with us—or to compare alternatives

Start here · Card photos & trust

Why card photos over email are a problem (and what to do instead)

The story that started Dromium: high-value cars, card photos sent over email, and clients hoping nothing goes wrong. Here’s why that flow is risky for everyone and what a Stripe-backed alternative looks like.

How card photos became the default

Many fleets grew up on email, phone and messaging apps. When you need a quick way to “lock in” a booking, asking guests to send a photo of their card feels faster than rebuilding the whole process.

It works—until something goes wrong: a dispute, a fraud attempt, or just a nervous client who realises their card details live in someone’s inbox.

Why this flow is risky for everyone

Card numbers and security codes sit in inboxes and chat history.
Your team has to retype those numbers into terminals or portals.
If a dispute happens, there’s no clean audit trail—just screenshots and email threads.

The higher the value of the car, the more this erodes trust. Clients become more cautious; your team spends more time reassuring them that everything is safe.

What a modern flow looks like

Instead of emailing photos, clients move through a secure online checkout: they see the car, dates, full price breakdown, deposit and terms, then pay through a provider they recognise, like Stripe.

They get a confirmation email; you get a confirmed booking with payment and security-hold status in one place.

Where Dromium fits in

Dromium plugs into your existing website and replaces card photos with a Stripe-backed booking flow. Clients book, sign and pay online; your team sees every booking, payment and hold in the dashboard—without ever handling raw card data.

The result: renters feel safer, and your team spends less time chasing payments, checking inboxes and explaining how deposits work.

Framework · Minimum booking

The “minimum booking” you actually want

A full calendar doesn’t always mean a healthy business. Short, cheap bookings eat up handover time, mileage and risk—without leaving much margin. This guide gives you a practical way to think about the minimum booking that actually makes sense for your fleet.

1. Start with the real cost of saying “yes”

Every booking has a fixed cost, no matter how short it is: prep and cleaning, staff time, payment fees, wear and tear, risk of incidents and the opportunity cost of having the car unavailable for a better booking. If your minimum booking doesn’t comfortably cover these, the calendar looks busy but profit stays thin.

2. A simple back-of-the-envelope calculation

Take one car and run this rough calculation:

Estimate your fixed cost per booking (staff time, prep, average wear, admin).
Add the variable cost per day / per km that you’re comfortable with.
Decide the minimum margin you want per booking (for example, €200).

If a 1-day booking at your current prices doesn’t hit that margin, your real minimum booking might be 2 or 3 days, or a higher day rate for short rentals.

3. Turn it into clear rules your team can follow

Once you know your numbers, write them down as simple rules:

Minimum X days for this category of car.
Higher day rate for weekend-only or last-minute bookings.
Optional extras (delivery, extra km, insurance) that protect your margin.

The goal isn’t to squeeze every client—it’s to avoid saying “yes” to bookings that look good on paper but quietly lose money.

4. How Dromium helps

In Dromium, these rules become concrete: minimum days per car, different prices for different seasons, and clear extras instead of ad-hoc discounts. Your team sees the same structure the client sees at checkout, so there’s less room for confusion—and fewer “can we do it for less?” conversations.

Guide · Operations

Why “DM to book” quietly kills your calendar

~7 min read · Good to share with owners and partners

“DM to book” feels friendly and flexible. Clients can message you on WhatsApp or Instagram, you send a price, they say yes, and a booking is “in the calendar”. But as the fleet grows, this flow quietly starts to eat your time and leak money.

This guide walks through what actually happens behind the scenes when bookings live in chats instead of a system, and why a simple combo—a booking widget on your site and a shared dashboard—changes the shape of your day.

What “DM to book” looks like from the inside

When bookings live in DMs, every reservation is a mini-project:

You scroll back through long threads just to find dates and price.
You copy details into a spreadsheet or calendar by hand.
Changes (time, car, driver) are scattered across multiple messages.
Handovers depend on whoever last spoke to the client remembering everything.

It works while volume is low and the team is tiny. As soon as you add more cars, locations or staff, you end up with a calendar that looks full—but no one fully trusts what’s in it.

What it feels like for the client

On the client side, DMs also create friction, even if people don’t say it out loud:

They’re not sure if the car is really reserved or “pencilled in”.
Prices can change if the conversation spans days or weeks.
Payment is often a separate step—bank transfer, card photo, or link in another app.
There’s no single email or page that summarises dates, price, and conditions.

For a high-value booking, that uncertainty makes people nervous. They might still book—but they don’t feel the calm confidence they get from a modern, end-to-end checkout.

The hidden cost: fragmented information

The real cost of “DM to book” isn’t just time. It’s fragmented information:

Operations and risk teams see different versions of the same booking.
Finance has to piece together what was agreed, what was paid and what’s outstanding.
There’s no clean timeline you can point to if something goes wrong.

That fragmentation makes it harder to defend your position in disputes, harder to train new staff, and harder to spot patterns in cancellations, damage or fraud.

What changes with a widget + dashboard

Moving from DMs to a widget and dashboard doesn’t mean losing the personal touch. It means the heavy lifting happens in a system, and your team can focus on judgement calls and service.

A typical flow with Dromium looks like this:

The client starts on your website, sees real availability and pricing.
They select dates, extras and location, and see the full price up front.
They pay a deposit or full amount and place a security hold via Stripe.
You and your team see one booking in the dashboard with a complete timeline.

You can still send a friendly message on WhatsApp or Instagram—but instead of negotiating and tracking everything there, you share a link to a proper checkout flow that locks in the booking.

How to transition away from “DM to book”

You don’t have to switch everything at once. Many fleets start with a simple rule:

DMs are for questions and service.
Actual bookings are created through the widget.

Over a few weeks, more and more bookings move into the system. The calendar becomes something everyone can trust, and your team spends less time scrolling through chat history and more time looking after guests.

Deep dive · Deposits & risk

Why card photos over email are a problem (and what to do instead)

~7 min read · The story that started Dromium

The whole reason Dromium exists is simple: a high-value rental, a company that was hard to vet, and a request to send card photos—front and back—over email. The booking went through, but it didn’t feel good. Too much trust, too little structure.

If you run a fleet, you’ve probably done something similar: card photos on file, manual pre-authorizations, deposits tracked in a spreadsheet. It works—until it doesn’t. This guide explains why those flows are risky, what Stripe holds change, and how to move from “just trust us” to something your clients and team actually trust.

What actually happens when you ask for card photos

On the surface, asking for card photos feels straightforward. You send an email or message, the client replies with pictures, and you “have the card” in case something goes wrong. In reality:

Card data is now sitting in inboxes and chat apps—potentially forever.
Multiple staff members might have access to those messages.
There’s no clear log of who used which card, for what and when.
From the client’s perspective, it feels like a step back in time.

Even if your team is careful, the pattern itself is fragile and hard to justify to a nervous client. “Please email us both sides of your card” is a red flag for a lot of people in 2025.

Manual pre-auths and spreadsheets aren’t much better

A step up from card photos is running manual pre-authorizations in a terminal or virtual POS, then tracking deposits in a spreadsheet or notebook. Better, but still:

Someone has to remember to place the hold at the right time.
Someone has to remember to release or capture it later.
If there’s a dispute, you’re piecing together slips, screenshots and calendar entries.
Clients often don’t know what happened on their card or when it will clear.

All of this adds cognitive load on your team and quietly erodes client confidence, especially for high-ticket bookings.

What Stripe holds change in practice

Stripe-based holds don’t magically remove all risk. But they do change the shape of it. Instead of card photos and manual notes, you get:

A proper authorization, placed through Stripe, tied to a specific booking.
A clear record of the amount, currency, time and outcome of each hold.
A predictable lifecycle: placed, expired, released or captured—with timestamps.
A client experience that matches what they’re used to from other online services.

With Dromium, those holds are not abstract. They’re visible directly in the booking view, alongside payments, notes and documents—so operations, risk and finance are all looking at the same source of truth.

How it feels for the client

From the client’s side, the difference is night and day. Instead of:

“Send us photos of your card and we’ll handle the rest.”
“We’ll hold something, don’t worry—it will be released after.”

They see a clear, modern flow:

A checkout page with the rental price, deposit and total clearly separated.
Card details entered into a Stripe-backed payment form, not sent by email.
A confirmation email that shows what was charged now, what’s held and under which conditions.

That doesn’t just feel safer—it also makes it easier for them to explain the transaction to their bank, partner or accountant if needed.

Moving from card photos to structured holds

You don’t have to flip a switch overnight. A practical transition often looks like:

Pick a subset of bookings (for example, cars above a certain value or new clients) where you will only use Stripe-based payments and holds.
Update your emails and DMs: instead of asking for card photos, you send a link to the booking widget.
Use your dashboard as the source of truth for what’s on hold, what’s captured and what’s released.
Gradually expand the rule until card photos and ad-hoc pre-auths disappear from your process.

As more bookings flow through the system, patterns around damage, disputes and no-shows become visible—and easier to act on.

Guide · Pricing & revenue

Designing pricing that matches how people actually rent

~8 min read · From “what feels right” to a simple model

Most rental pricing starts from a feeling: “this car should be at least X per day”. Then reality shows up—weekend peaks, off-season dips, long rentals that eat mileage, extras that staff forget to charge, and owners asking why the account looks thin.

This guide won’t give you a one-size-fits-all price list. Instead, it gives you a simple way to think about pricing across four dimensions: base rates, rental length, km allowances and extras. The goal is not perfection—the goal is a model you can explain to clients and staff without opening a spreadsheet.

Start with the “minimum viable booking” you actually want

Before you tweak day rates, decide what a healthy booking looks like for each car. Not the shortest booking you’ll accept, but the shortest booking that makes sense.

For a high-value car, that might be 2–3 days with a reasonable km allowance. For a daily workhorse, it might be 1 day with tighter mileage. If your calendar is full of short, low-margin bookings, it’s usually a sign that your minimum booking isn’t set where it should be.

A good rule of thumb: if you look at a booking and feel “this is barely worth the effort” more than a few times per week, your pricing model is telling you something.

Base rates are the story you tell; the model is the math behind it

Your base rate is what clients anchor on—“€490 per day” or “€1,400 for a long weekend”. Behind that single number there should be a simple mental model:

What it costs you to have the car available (insurance, storage, capital).
What a typical rental really costs you in wear, mileage and time.
What you want to earn for that unit of risk.

You don’t need a full-blown finance model. You do need a clear answer to “why this rate?” that you can explain to an owner, partner or team lead in 2–3 sentences.

Use rental length and km bundles instead of tiny surcharges

Clients understand bundles much more easily than a forest of surcharges. Instead of micromanaging every scenario, it’s often cleaner to define a few patterns:

“Daily” bookings: 1–2 days with a modest km allowance.
“Weekend / short break”: 3–4 days with slightly better per-day value.
“Trips / holidays”: 5+ days where you protect margins with km limits.

Inside Dromium, these become clear rules: minimum days, km per day, extra-km price and seasonal adjustments. For the client, it still feels like simple choices: “weekend package” vs “full week”.

Seasonal pricing should follow reality, not just the calendar

Most fleets know when the high season is. The question is: are you charging in a way that reflects demand— or did you just copy last year’s numbers?

A practical approach:

Pick 2–3 true peak periods (not 12 “micro seasons”).
Adjust base rates and minimum days up in those windows.
Make at least one off-peak period visibly cheaper to encourage bookings when cars would otherwise sit.

In Dromium, that means seasonal rules layered on top of your base pricing. In your client’s mind, it’s: “Summer is more expensive, early spring and late autumn are a good deal.”

Extras and penalties: clear before, consistent after

Extras and penalties are where trust breaks if you’re not careful. The rule is simple: if a reasonable client would say “I didn’t know that”, the pricing wasn’t clear enough.

Extras should be visible as line items at checkout, not surprises later.
Penalty rules (late return, extra km, smoking, cleaning) should be in plain language.
The same scenarios should be charged the same way—otherwise staff will quietly stop enforcing them.

Dromium’s pricing model is built to reflect that: extras and penalty fees show up as structured items tied to a booking, so nobody is guessing what to charge.

A quick test for your current pricing model

If you want to pressure-test your current pricing, grab three recent bookings:

One short booking that felt too cheap.
One “perfect” booking that felt just right.
One long booking where you worried about mileage or wear.

For each one, ask:

Would I take this same booking again at the same price?
Did the client understand what they were paying for?
Did my team know exactly how to price it without asking for help?

If any answer is “no”, that’s a sign your model needs tightening—not just the price itself.

Checklist · Extras, penalties and the fine print

Extras, penalties and the fine print—without ugly surprises

~7–9 min read · Good input for your T&Cs, checkout copy and internal playbooks

Most bad rental stories don’t start with the base price. They start with what wasn’t clear: extra kilometres, cleaning fees, tolls, late returns, damage, “admin fees”. The client feels surprised, you feel defensive, and nobody leaves happy.

The goal of this guide is simple: make all of that predictable and boring. Clear up front for the client, repeatable for your staff, and easy to apply inside a system like Dromium.

1. List the real ways people end up paying more

Start with reality, not theory. For the last 3–6 months of bookings, what actually triggered extra charges?

Additional kilometres beyond the included allowance
Tolls, congestion charges or tickets
Fuel not returned at the agreed level
Cleaning after smoking, animals or extreme dirt
Late returns that affect the next booking
Minor damage vs. major incidents

Put them all in one list. This is the raw material for both your fine print and your checkout copy.

2. Turn each item into a simple rule clients can understand

For each extra or penalty, write one sentence that passes the “read out loud” test. If your staff can’t say it on the phone without stumbling, it’s too complicated.

Extra km: “Includes 150 km per day. Extra km are charged at €X per km.”
Late return: “If you’re more than 60 minutes late and we haven’t agreed in advance, we may charge an extra half-day.”
Cleaning: “Normal use is fine. Smoking, pets or heavy dirt may incur a €Y deep-clean fee.”
Fuel: “Cars must be returned with the same fuel level. If not, we refuel and charge at local pump prices plus a small service fee.”

You can always keep a more formal version in your T&Cs. But this short, human version is what your clients will actually remember.

3. Decide what you want to discourage vs. simply price in

Not all extras are equal. Some behaviours you just want to price fairly. Others you actively want to discourage because they put stress on your team or risk on your cars.

Price in: toll processing, small admin work, minor schedule drift.
Discourage: repeat last-minute changes, heavy smoking, chronically late returns, ignoring fuel rules.

The more you’re trying to discourage something, the more important it is that the rule is visible at booking time—not just buried in a PDF.

4. Where to surface these rules so they actually work

A good rule, in the wrong place, might as well not exist. We see four places where extras and penalties should show up:

On the website: a short “What to know before you book” section near pricing.
In the booking flow: inline notes next to price breakdown and deposit information.
In the confirmation email: a clear summary of key rules and how extras are calculated.
In your internal checklist: so staff give the same explanation every time.

Consistency is what builds trust. The client sees the same story on the site, in the widget, in the email and when they talk to your team.

5. Encoding the rules inside Dromium

Once you’re happy with your rules, you don’t want to rely on memory. In Dromium, the pricing engine and checkout flow can reflect:

Included km per day and per booking, plus clear extra-km rates
Cleaning and late-return rules that map to real fees
Seasonal or weekend adjustments that are applied automatically
Notes and internal fields that help your team explain charges confidently, with a timeline to back them up

The aim isn’t to nickel-and-dime clients. It’s to make sure that when you do need to charge extra, it feels fair, predictable and already agreed.

Template · A simple deposit policy you can actually explain

A deposit policy your clients understand—and your team can stick to

~6–8 min read · Written for both your T&Cs and your staff

Security deposits are where a lot of trust is lost. Clients don’t know when the hold happens, how much it is, when it’s released, or what really happens if there’s an incident. Staff improvise explanations, and you end up with different stories in email, on the phone and at the counter.

This guide gives you a plain-language structure you can copy, tweak and use in three places: your website, your T&Cs and your internal playbooks.

1. Start with one clear sentence

Before the details, you want one simple line that frames the whole thing. For example:

“For every booking we place a temporary security hold on your card. If the car is returned as agreed, the hold is released and you are not charged.”

That sentence does three things: explains that it’s a hold, says when it happens, and makes the “no surprise charge” outcome explicit.

2. Define the core pieces in human language

A good deposit policy answers the same core questions every time:

When is the hold placed? At booking, before handover, or at pickup?
How much is it? Fixed amount, or based on car / booking value?
How long does it stay? Number of days, and what happens on weekends / holidays?
When do you charge vs. release? Clear conditions for each.
What happens if there’s an incident? Process, not just “we decide”.

Each answer should fit in one or two sentences your team can say out loud without needing legal training.

3. A basic template you can adapt

Here’s a simple structure you can paste into your own docs and customise:

Deposit amount

For this booking, we place a security hold of €[AMOUNT] on your card. This is not a charge.

When the hold is placed

The hold is placed [at booking / X days before pickup / at pickup] once your booking is confirmed.

How long the hold stays

The hold normally stays in place for [N days]. Your bank controls exactly when the pending hold disappears from your statement, but in most cases it is released within [N+M days] after we release it.

When we charge vs. release

If the car is returned on time and in the agreed condition, we release the hold and you are not charged. If there are extra charges (for example additional km, fuel or damage), we will discuss them with you first and may use part of the deposit to cover them.

If there is an incident

In case of damage or other incidents, we document everything (photos, notes, invoices) and share this with you. If we need to use all or part of the deposit, we explain the calculation and provide supporting documentation.

You can keep a more detailed, legal version in your T&Cs—but this template should be the one your team actually uses with clients.

4. Make sure your staff and your Stripe setup match the policy

A clear policy is only useful if your tools and routines support it. In practice, that means:

Using consistent hold amounts for similar cars and booking values
Placing and releasing holds from a single system (not ad-hoc in the terminal)
Documenting why a hold was used, partially used or fully released
Making sure emails and SMS copy match what staff say at pickup

If you ever end up in a dispute, the combination of a clear written policy plus a Stripe-backed timeline is much stronger than “we usually do X”.

5. How this maps into Dromium

In Dromium, your deposit policy lives in three places:

In the widget checkout, next to the price breakdown and deposit information.
In the booking view, where staff can see deposit amount, status and timeline.
In the Stripe-backed payment & hold history, so finance and risk see the same data.

The goal is to remove improvisation. Your staff follow a clear policy, your clients see the same story everywhere, and the software quietly keeps the record straight.

Playbook · Notes, photos and timelines: documenting the boring parts

Notes, photos and timelines: documenting the boring parts

~7 min read · Pairs naturally with Dromium’s booking timeline

The most expensive mistakes rarely come from “big” events. They come from the quiet middle: a scratch nobody wrote down, a late return nobody noted, a call that never made it into the system. When something goes wrong, everyone is left piecing together what happened from memory, emails and WhatsApp threads.

This playbook is about documenting the boring parts—notes, photos and timestamps—in a way that your team will actually use, and that stands up when a client, bank or insurer asks “what really happened here?”.

1. Why the boring parts decide how disputes end

When there’s a disagreement—damage, extra km, late return—three questions usually decide the outcome:

What was agreed up front?
What was the state of the car at handover and return?
What was communicated in between—and when?

If your answer is “we remember that…” you’re already on the back foot. If you can say “here’s the timeline, notes and photos attached to this booking”, the conversation changes completely.

2. A simple structure: before, during, after

You don’t need a huge process. You need a small, repeatable checklist that maps to the natural life of a booking:

Before handover – booking details confirmed, deposit explained, key documents received.
At handover – photos of the car, fuel level, mileage and any existing damage.
During the rental – any incidents, extension requests, extra drivers, location changes.
At return – photos again, mileage, fuel, new damage, extra fees agreed.
Afterwards – invoices, refunds, partial use of deposit, follow-up emails.

Each step wants a tiny amount of structure: a few required fields and a place to drop photos—not a separate spreadsheet per car.

3. What to capture in practice (without slowing the team down)

For most fleets, a good baseline looks like this:

At pickup

4–8 quick photos around the car (corners, wheels, interior)
Odometer and fuel level photos
Short note on anything pre-existing (“small scratch front left bumper”)

During the booking

Notes on any calls/emails that change the booking
Photos if there’s an incident or warning light

At return

New set of photos (same angles as pickup)
Odometer and fuel again
Short note for any extra charges and whether the client agreed on-site

In total, that’s a handful of photos and two or three short notes per high-value booking—measured in minutes, not in extra paperwork.

4. Turn evidence into a clear timeline

Evidence is only useful if you can replay it. That means everything should line up on a single timeline for each booking:

Messages and internal notes
Photos and documents
Payment and deposit events
Status changes (confirmed, picked up, returned, disputed, closed)

When a client asks a question, or a chargeback appears, you don’t want to hunt across chats and folders. You want to scroll one timeline and say “here’s exactly what happened, with dates and photos.”.

5. How this looks inside Dromium

Dromium is built around this idea of a single story per booking:

A booking timeline where notes, status changes, payments and holds all show up in order.
Photos and documents attached directly to the booking, not in a shared drive nobody opens.
Internal-only notes so your team can record sensitive details without sending them to the client.

The goal isn’t to create more work. It’s to make sure the 2–3 minutes of extra documentation you already do has somewhere to live—and actually protects you when it matters.

Pattern · One source of truth for each booking

One source of truth for each booking

~6 min read · Exactly what Dromium’s booking view is built around

When something goes wrong with a booking—a disagreement about damage, an unexpected extra charge, a no-show—everyone goes hunting for the story. Operations checks WhatsApp, finance opens Stripe, someone else digs through email. Ten minutes later, you still don’t have a clean answer.

“One source of truth” means the opposite: for each booking, there is a single place that tells the story—payments, holds, notes, photos, documents, status changes. This guide looks at what that actually means in practice for a rental fleet.

1. The problem with scattered bookings

Most fleets don’t lack information. They lack cohesion. For any given booking, data is usually spread across:

WhatsApp and SMS threads with the client
Emails with photos of passports, licences and cards
A spreadsheet with dates, prices and plate numbers
Stripe or another processor for payments and refunds
Paper contracts, annotated by hand

None of these systems is wrong on its own—but every time a booking spans five different tools, the chance of inconsistent information jumps. Two people can look at the “same” booking and see different realities.

2. What “one source of truth” actually means

“Source of truth” is a fancy way of saying: if there’s a question about this booking, this is where we look first, and this is what we trust.

For a rental booking, that source should contain at least:

Who the client is (with verified contact and ID details)
Which car was booked, when, and for how long
What was agreed on price, extras, km allowance and penalties
What was paid, what is held, and what is still owed
Notes, photos and documents from handover and hand-back
Status and timeline: when it was confirmed, picked up, returned, closed

If this is clear in one place, everything else—operations, risk, finance, customer support—gets easier.

3. Handovers and hand-backs when the story is clean

The real test of your system is not when you create the booking. It’s at pickup and return, when the client is in front of you and time is tight.

At pickup

The team sees exactly which car, booking terms and deposit apply.
Existing notes and damage are visible in one view.
Any last-minute changes (extensions, location tweaks) are logged as notes.

At return

New damage, extra km or late fees are recorded against the booking.
Photos and notes are saved where finance will later see them.
The decision to charge or release the deposit is documented.

Instead of “ask Ana, she was on the phone with them”, you have a visible trail: anyone opening the booking can see what happened.

4. How this helps operations, risk and finance share one reality

Different teams care about different angles of the same booking:

Operations wants dates, times, car availability and any special handling.
Risk cares about deposits, notes, past incidents and whether policies were followed.
Finance needs clean numbers: what was invoiced, what was collected, what is refunded or written off.

A single booking record lets each team filter and view the same underlying truth, instead of maintaining parallel spreadsheets that slowly drift apart.

5. How Dromium models “one booking, one story”

Dromium’s booking view is built on this pattern. For each booking, you get:

A linked car and client with their own history and details.
Stripe-backed payments and holds visible alongside booking details.
Notes and internal comments recorded with timestamps and authors.
Documents and photos attached directly to the booking, not hidden in a shared drive.
A status timeline that shows when the booking was created, confirmed, picked up, returned and closed.

The goal is simple: when someone asks “what’s going on with this booking?”, you open one screen and you’re done—no more cross-checking five tools to reconstruct the story.

Checklist · Questions to ask any rental software vendor

Questions to ask any rental software vendor

~6–7 min read · Use this list with us — or to compare alternatives

Demos are designed to be impressive. The real test of any rental platform is what happens three months in—when you’re in peak season, staff are tired, and a tricky booking lands on the calendar. This checklist is meant to cut through the pitch and get to how a vendor will behave in those moments.

You can use these questions with Dromium, with other vendors, or when you’re comparing a “DIY” stack against an integrated platform.

1. Pricing & business model

You’re not just buying software—you’re buying a set of incentives. Make sure you understand exactly how they get paid.

Do you charge per car, per booking, or a flat platform fee?
Are payment processing fees separate from your own fees, or bundled?
Are there onboarding, “implementation” or support fees?
What happens to our pricing if we double in size? What about if we shrink?
Is there a minimum contract length or term, and what’s the exit process?

The goal is simple, predictable economics. If you can’t explain the vendor’s pricing to your business partner in one paragraph, it’s probably too complex.

2. Payments, deposits & risk control

For high-value cars, payment flows and security holds are where trust is won or lost. Ask specifically about how this works in their product.

Which payment processor(s) do you integrate with? Stripe, others, custom?
Can we configure deposits as holds, charges, or a mix—per car or per product?
How long can a hold stay in place, and how do we extend or re-place it?
Can operations release a hold safely without logging into the payment gateway?
What audit trail exists when we charge a deposit or keep part of it?

Be wary of any answer that sounds like “it depends, we’ll figure it out later” for deposits and holds. That’s where disputes and bad reviews live.

3. Pricing flexibility: does it match how you actually rent?

Many systems look fine until you try to model real-world pricing: weekends vs weekdays, seasonal rates, km bundles, extras, penalties.

Can we define different base rates by car, season, and day of week?
Can we mix “per day” and “per km” logic, with included km and overage fees?
How are extras (delivery, child seat, insurance tiers) structured and priced?
Can we handle special dates (holidays, events) with their own pricing rules?
Can you show us a booking in your system that reflects our real price sheet?

If a vendor can’t easily mirror one of your real pricing examples in the demo, assume it will be harder—not easier—once you sign.

4. Operations, workflows & user roles

Your team will be living in this tool every day. Make sure it reflects how you actually work, not how a slide deck imagines you work.

Can we assign bookings to team members and see who owns what?
How are roles and permissions handled for operations, risk and finance?
Where do internal notes, tasks and comments live for each booking?
What does a busy day view look like for the front desk? For dispatch?
Can we filter bookings by risk status, payment status and location?

Ask them to show an example of a “messy” booking: changed dates, changed car, partial payment, notes and photos. That’s closer to reality.

5. Data, exports & avoiding lock-in

Your booking history is an asset. You should never feel trapped because your data is hard to get out.

Can we export bookings, clients, cars and payments in a usable format?
Is there an API, and is it documented?
What happens to our data if we leave the platform?
Can we pull reports for accounting without manual copy/paste?
Do you have customers who have migrated in from spreadsheets or other tools?

A confident vendor will be relaxed about exports and migration—they know that staying with them should be the obvious choice, not a forced one.

6. Support, response times & actual humans

Software issues always show up at the least convenient moment—weekends, busy seasons, VIP bookings. You want to know what support looks like then.

How do we reach you when something breaks—email, chat, phone?
What are your typical response times during business hours? Weekends?
Will we have a named contact during onboarding?
Do you help us adjust pricing and policies, or just the software settings?
How often do you ship updates, and how are changes communicated?

You’re looking for signs of a partnership, not just a login: vendors who are curious about your business, not just their own roadmap.

7. How to use this checklist with Dromium

If you decide to talk to us, bring this checklist. We’re happy to walk through it line by line, using your real fleet, pricing and current process as the example.

Even if you end up choosing a different tool—or building your own stack—you should walk away with more clarity on what you need from any system: clean pricing, Stripe-backed payments and holds, one source of truth for each booking, and a vendor who understands that a Lamborghini or G-Wagon booking is not “just another transaction”.

Want to see these ideas applied to your fleet?

On a 30-minute call, we’ll map your current workflow, plug in a sample Stripe account, mirror a few of your pricing rules, and show what it would look like in Dromium.

Book a live demo

Or email hello@dromium.com with a short description of your setup. We’ll reply within one business day.