Franchise rental groups and multi-depot operators have a unique problem with vehicle-reporting software. Every customer-facing inspection report and rental agreement needs to look like it came from the local brand. Head-office software that stamps every report with the parent company logo undermines the franchise relationship; depot-level software that doesn't roll up to head office means no central oversight. The right answer is multi-tenant white-labelling — one parent account, multiple branded sub-businesses, strict data isolation, central reporting.
This post explains how that architecture works in practice for UK rental, leasing and fleet groups.
The franchise problem in one paragraph
A franchise group runs 12 depots across the UK under one brand banner, but each depot is operated by a different franchisee with their own books, their own customer base, their own local relationships. When a customer hires a van from the Manchester depot, the rental agreement they sign should say "Acme Rentals Manchester" with the local depot's logo, address, T&Cs and contact details — not "Acme Rentals Limited Head Office." The customer's relationship is with the local depot. The franchisee owns it.
But the head office also needs visibility. They need to know how many rentals went out from each depot this month, how many disputes are being handled, how the credit usage rolls up, what the quality scores look like across the network. Without that, the central brand can't manage consistency.
Multi-tenant white-labelling solves this by giving each depot its own branded "tenant" inside one parent account.
What multi-tenant white-labelling actually does
The parent account hosts the brand at the network level: shared rental templates, shared inspection diagrams, central billing, network-wide dashboards. Each depot (or franchise, or sub-brand) is a "tenant" within that parent account, with their own:
- Logo and brand colours on customer-facing PDF reports and rental agreements
- Local address, phone number and T&Cs
- Users — depot staff log in to their tenant, see only their tenant's vehicles, customers and reports
- Branding on emails sent to customers — signing links, ticket replies, lead-magnet downloads
- Reporting scoped to the depot
The data isolation is strict. A Manchester depot user cannot see Birmingham depot's customers, vehicles, or reports. A Manchester customer disputing a charge interacts with the Manchester team, against the Manchester record, signed off by Manchester management. The fact that 11 other depots exist on the same platform is invisible to them.
Three operating models that work
Franchise group, central billing. Head office buys credits centrally and allocates them to depots monthly. Depots focus on operations, not billing. Head office sees who's heavy-usage and adjusts allocations.
Franchise group, per-depot billing. Each depot has its own Stripe subscription and its own credit balance. Bills are paid by the franchisee, not the head office. Head office still sees usage but doesn't carry the credit cost. This is the model most franchise groups end up running.
Reseller / agency, per-client billing. A reseller manages 10–15 client accounts as sub-tenants. Each client is billed separately, each is white-labelled to their own brand, the reseller handles support and onboarding. Head office (the reseller) takes a margin.
What this looks like at handover
A customer walks into the Birmingham depot. The yard manager opens the platform on their tablet. The screen they see has the Birmingham logo, Birmingham address, Birmingham staff list. They run the inspection, capture the customer signature, email the agreement. The PDF the customer receives has the Birmingham logo, Birmingham T&Cs, Birmingham contact details for any follow-up.
The customer has no idea (and no need to know) that the underlying platform also runs 11 other depots. The local brand is intact.
Meanwhile, head office's dashboard shows the rental was issued, the credit was consumed, and the depot's quality score is on track. No data leaks across depots; everything rolls up to the network view.
A worked example: a 12-depot franchise rollout
A franchise group decided to consolidate from 6 different depot-level tools to one multi-tenant platform. Rollout took 6 weeks:
- Week 1: head office set up the parent account, defined the brand-wide rental template, configured the inspection diagrams.
- Weeks 2–4: each depot was created as a sub-tenant, with the franchisee uploading their depot logo, address, T&Cs, and inviting their staff. Each depot ran a one-day training session.
- Weeks 5–6: paper records continued to run in parallel for safety. By end of week 6, all 12 depots had migrated.
Total cost of migration: head office's project manager time plus a half-day per depot. No per-seat licensing dispute (the platform is per-report, not per-seat). No data migration headache (each depot started fresh; historic records stayed in the old systems for retrieval as needed).
Six months in: handover times across the network averaged 4 minutes (down from 9 on paper), damage disputes had dropped by half, and the head-office quality dashboard surfaced two depots with sub-standard photo coverage that the central team coached up.
Frequently asked questions
Can a customer's data move between depots if they hire from multiple locations? Only by explicit invitation. If the customer hires from Birmingham and then from Manchester, the two records sit in two tenants. Sharing the customer record across tenants is a deliberate action the customer can authorise, not a default.
What happens to a sub-tenant if a depot leaves the franchise network? The sub-tenant can be spun out as a standalone account. The depot keeps its data, its customer relationships and its history. Head office stops seeing the data.
Can the parent account override a depot's actions? Yes — parent admins have read access across all tenants and can intervene where needed (e.g. settling a dispute that's escalated). The audit log records who did what.
Is there a limit on number of sub-tenants? On vehReports there is no hard limit. Operators with 50+ sub-tenants exist; the platform is designed for that scale.
Sources
- Related feature: Multi-tenancy
- Related feature: Rental agreements
- Related: Credits & billing
