Car rental lead routing is the rule for deciding which branch and which person owns a new inquiry, when that owner must act, and how the inquiry moves if the first branch cannot serve it. The first reply is only the beginning. The branch still needs the pickup window, vehicle class, availability context, quote owner, and next action in one record.
For a multi-branch rental company, “send it to the nearest location” is too thin a rule. The customer may land at one airport, return at another branch, need a category that is scarce locally, or come through a partner with a named account owner. Routing should assign responsibility without silently promising a car or a price.
This guide gives you an intake packet, a routing matrix, a handoff record, and a review rhythm. It is an operating method that a team can use with or without automated assignment. The existing car rental CRM and WhatsApp guide covers the broader inquiry-to-booking path; this article focuses on the moment an inquiry changes hands across branches.
Decide ownership before deciding availability
An inquiry has at least three different locations: where the customer first contacted you, where they want to pick up, and where a vehicle may be ready. Those locations can disagree. They also answer different questions.
Scroll to compare every column
| Question | Decision owner | What the record should say |
|---|---|---|
| Who replies now? | Sales queue lead or named agent | Person, branch, due time, and backup |
| Who can quote the requested pickup? | Pickup branch or approved central sales team | Branch, dates, category, rules to check, and quote owner |
| Who will prepare the rental? | Operations at the fulfillment branch | Accepted booking handoff, readiness work, and open items |
Do not use a vehicle's current parking location as proof that it can support a quote. Maintenance, return timing, cleaning, inspection, an existing hold, or a transfer may still change the answer. The branch availability guide explains the capacity check in detail.
Capture the seven facts needed to route an inquiry
The initial packet should be small enough for a real conversation. It should also let a second person understand the request without rereading a whole chat.
- Source and first contact: WhatsApp, site form, call, partner, walk-in, or another known channel, plus the first-contact time.
- Customer identity: a reliable way to recognize the same customer across messages, with any match still subject to staff review.
- Pickup branch or area: the place the customer actually wants to receive the vehicle, not merely the branch that saw the message.
- Pickup and return window: dates, times, and return branch if different.
- Vehicle need: requested category or practical need, such as seats or luggage, without promising a specific unit.
- Commercial context: partner or corporate agreement, existing quote, special request, or policy question that changes who must review the case.
- Current owner and next action: one person or queue, a due time set by your staffing policy, and what the customer is waiting for.
If a critical fact is missing, route the inquiry to someone who can ask for it. Do not mark it as lost and do not invent availability. A useful first response may simply confirm the requested branch and return time before a price is prepared.
Use a branch routing matrix, then name the exception
Start with the pickup location. Add checks only where they change the owner or the next step. This is a proposed policy template; each operator must set its own service area, hours, account rules, and approval rights.
Scroll to compare every column
| Trigger | Default owner | Check before replying with an offer | Exception path |
|---|---|---|---|
| Pickup at an open branch | That branch's sales owner | Rental window, category, local rules | Branch lead when no owner accepts the inquiry |
| Airport or delivery request | Branch responsible for that handoff area | Delivery capacity, timing, fees, and driver plan | Operations review when fulfillment is uncertain |
| Different return branch | Pickup-branch sales owner | One-way policy, return capacity, and fee | Both branches review before a promise |
| Partner or corporate source | Named account owner, then pickup branch | Agreement terms and attribution | Commercial manager if the agreement is unclear |
| Requested category unavailable locally | Current sales owner keeps the customer reply | Nearby capacity and feasible movement | Authorized operations review of an alternative |
| After-hours inquiry | Published coverage owner or next staffed queue | What can be acknowledged without a commitment | First staffed shift owns follow-up by a published deadline |
The rule should say who owns the customer reply while another team checks capacity. Otherwise the inquiry becomes “with operations” and nobody tells the customer what happens next. A transfer between branches may solve capacity, but it needs time, custody, preparation, and evidence; see the multi-branch operations playbook.
Move each inquiry through four ownership states
A simple queue works better when every state has an exit condition.
1. New, awaiting assignment
The record has a source and contact route. A queue lead sees it, checks for an existing customer or open inquiry, and assigns a named first responder. A duplicate check is a human review of available context, not a promise of automatic identity matching.
2. Assigned, awaiting first useful response
The owner acknowledges the request, asks for any missing routing fact, and records the next action. Define a deadline from your actual staffed hours and channel promise. A generic automatic greeting is not the same as a useful response.
3. In progress, awaiting a decision or customer action
The owner keeps the customer thread while sales, fleet, or another branch checks the requested category, rate, policy, or delivery plan. Record who must answer the internal question and when. If the quote is ready, preserve its version, expiry, and conditions using the car rental quote template.
4. Handed off or closed
The receiving branch accepts the handoff with its open items, or the original owner records a reason the inquiry did not progress. Do not close a case merely because it was forwarded. A customer acceptance also does not itself prove that booking confirmation conditions have been met.
Keep an explicit handoff packet
When another branch takes the lead, the sender should be able to answer five questions: What did the customer ask for? What did we tell them? What remains unverified? Who will reply next? By when?
Scroll to compare every column
| Packet field | Why the receiving branch needs it |
|---|---|
| Customer and contact channel | Continue the same conversation with appropriate access |
| Source and account context | Respect attribution and agreement terms |
| Pickup, return, category, and timing | Check the actual request against local capacity |
| Latest quote or proposed terms | Avoid two branches sending different prices |
| Promises and open questions | Separate confirmed facts from tentative options |
| Current owner, receiving owner, due time | Make responsibility visible through the transfer |
| Acceptance or rejection note | Show whether the handoff actually happened |
The sender remains responsible until the receiving owner accepts or the published escalation rule reassigns the work. A shared inbox can show the conversation; it does not by itself settle branch ownership.
Example: a request that crosses two branches
A customer writes to the downtown WhatsApp number on Monday for an airport pickup on Friday and a return downtown on Sunday. The downtown agent captures the dates, category need, customer contact, and requested locations. Under the operator's rule, the airport branch owns the quote for pickup; downtown remains the initial response owner until the airport agent accepts the transfer.
The airport agent checks category capacity and delivery timing. The downtown branch checks whether the one-way return is allowed and whether it has a receiving process on Sunday. The quote names the pickup branch, return branch, terms, expiry, and customer action. If the vehicle plan depends on a transfer, that dependency stays visible. Nobody describes the booking as confirmed while the agreed payment, policy, or approval condition is still open.
This case is illustrative. Your branches may assign one central sales owner instead. The control is the same: one current customer-response owner, one verified quote, and a receiving team that accepts the next stage.
Review the queue for lost ownership, not just slow replies
Set a daily review at shift change and a weekly manager review. Choose targets from your own coverage and demand patterns rather than borrowing an unsupported “industry standard” response time.
Scroll to compare every column
| Signal | Definition | Decision it supports |
|---|---|---|
| Unowned inquiry age | Time from receipt to named first owner | Fix queue coverage or assignment rules |
| First useful response time | Time to a relevant reply or a request for the missing fact | Fix staffing and lookup delays |
| Reassignment count | Times an inquiry changes owner before a quote | Identify confusing branch boundaries |
| Handoff acceptance lag | Time from sending to receiving-owner acceptance | Fix a branch or shift handoff |
| Quote disagreement | Cases with conflicting branch offers or terms | Review quote authority and version control |
| Booking handoff gaps | Confirmed bookings with unresolved sales context | Repair the transition to operations |
Break the signals down by source, branch, day, and staffed hours. A fast response can still be wrong if it quotes unready inventory. A slower response can still be avoidable if the owner had no way to ask another branch for a decision.
What Resvo supports today
Resvo is a Rental Management System (RMS) that keeps inquiry, quote, booking, vehicle, payment, contract, handoff, return, and follow-up connected. Its Unified Rental Inbox is Live for one-to-one WhatsApp and web chat. Permitted team members can read and reply from a shared workspace; the Sales Inbox shows linked customer, opportunity, quote, and booking context where available. The sales pipeline and customer records are also Live.
The operator still defines branch coverage, assignments, response deadlines, quote authority, and the conditions for a booking. The shared inbox does not promise automatic lead routing, universal customer matching, collision prevention, or automatic sales-to-support transfer. The current lightweight WhatsApp connection requires setup with the operator's number; the official Meta Business Platform API is planned. Confirm the channel and branch workflow in a demo rather than assuming every routing rule is already automated.
See Sales & Distribution for the sales record and Customer Experience for the shared inbox. To map your own branches, book a demo with one inquiry that has a pickup, return, and quote exception.
Frequently asked questions
Should leads be assigned to the nearest branch?
Only when that branch also owns the requested pickup and can meet the operator's rules. Check the customer's pickup location, return plan, category, account terms, and staffed coverage before deciding who quotes.
Can one central team answer for every branch?
Yes, if that is your operating design. Give the central team clear quote authority and a reliable way to get branch capacity and readiness decisions. The central team should not promise a vehicle on incomplete information.
Does a shared WhatsApp inbox route leads automatically?
Not necessarily. A shared inbox makes conversations visible to permitted users. Assignment, acceptance, escalation, and customer-response ownership need explicit rules, whether staff apply them manually or a verified configuration supports them.
When should the first branch stop owning the inquiry?
When the receiving owner accepts the handoff, or when a published escalation rule names a replacement owner. Forwarding a message without acceptance leaves the customer between branches.