Picture a rider standing in the rain next to a scooter that won't unlock. That person doesn't want a ticket number. They want the ride stopped, the charge fixed, and either a working vehicle or a way off the street. Your customer support playbook is the one document that tells every agent how to deliver that without improvising on the spot.
Do you need a thick binder? No.
A status-first ticket, a few scripts, one named person who can refund or force-end a ride, and a short list of metrics will do the job. That's the actual work. Everything else is decoration.
What belongs in a rental support playbook
Keep the file short enough that a new hire can work from it on day one. Hunt-and-peck for the refund rule means the file ran long.
Write any process that crosses several people or systems as an SOP with a named owner, not as a vague flowchart. Named owners get followed. Pretty diagrams often don't.
For bike, e-bike, and scooter rentals, a working playbook usually covers:
- Intake fields that tie the rider, reservation, vehicle, and location together
- Channel rules, including who actually staffs each channel
- Scripts for stuck rides, billing errors, damage, and cancellations
- A hard escalation path covering refunds, force-end, and safety pulls
Shop rentals and dockless fleets don't share the same hours. A storefront that closes in the evening can let after-hours mail sit in a morning queue. A free-floating scooter fleet that bills by the minute cannot. Match coverage to how people actually get stranded.
Build the ticket before you type a reply
Most teams answer the rider first because it feels polite. Then they find out the scooter was already in the shop, or the reservation never started, or the app charged a ghost ride. Now they've promised a fix they can't keep. Don't work that way.
Thing is, the first 30 seconds belong to the record, not the chat box. A useful support record answers four questions fast: who is riding, which vehicle is involved, where the problem is, and who owns the next action. Put those four fields in the template and give each one a name.
- Identify the rider and the reservation.
- Pull vehicle ID, last GPS ping, battery state, and lock status.
- Decide whether the issue sits on the reservation, the vehicle, or the software.
- Assign an owner before anything gets sent.
- Only then reply with a verified instruction.
Never tell someone to try the lock again if the unit is already marked out of service. Check the status first.
Pick channels that match the ride
Riders in motion use the app or SMS. Email is for deposits, invoices, and damage photos after the fact. Phone still matters when a lock fails at night and the rider is stuck, because a stranded person can't wait on an email thread.
Publish a 24/7 number only if someone with actual authority picks it up. A ringing line with no owner and no escalation path just creates a second problem on top of the first. Small shops can be honest about their hours. Dockless operators usually need an after-hours path for force-end and refunds, even if that path is just an on-call manager plus a templated in-app reply.
Fleets that run in public right-of-way also inherit city permit rules that a hotel or campus amenity fleet often doesn't. Confirm those locally rather than copying another city's playbook. This is not legal advice.
Scripts you can paste tonight
Keep the tone calm in all of these. Confirm the policy you already published, not a new one you invented mid-chat.
Stuck ride / lock failure (in-app or SMS)
Hi [Name] - I see vehicle [ID] at [location]. I'm ending this ride on our side so you aren't billed while we sort the lock. Stay put if it's safe. I'll confirm the fare in this thread.Billing correction
Hi [Name] - the ride on [date] was ended at [time]. We corrected the fare from [old] to [new] and recorded it against that reservation. You should see the update on your statement in [timeframe].Log the correction against the ride itself so accounting and any partner payout stay accurate. Then close the loop with a message confirming the ride ended and the fare changed.
Damage or missing accessory (email)
Subject: Rental [ID] - damage review
Hi [Name],
We compared checkout and return photos for [vehicle ID]. Here's what we see: [specific item]. Per the rental agreement you accepted, the next step is [inspect / quote / hold]. Reply with any photos from your side and we'll finish the review by [date].Compare like with like when you do this: similar angles, the same known marks, the same accessory count. A clear starting record makes that conversation less of a fight.
Cancellation before pickup
Hi [Name] - your booking for [date/time] is cancelled. Refund timing follows the policy shown at checkout: [policy]. You'll see the refund on the original payment method.Don't paste a policy the website never showed.
Escalation that actually moves
A playbook fails when every hard ticket sits in "waiting on manager" limbo. Name the people who can act. Give them tools.
| Tier | Who | What they can do | Typical trigger |
|---|---|---|---|
| 1 | Self-serve / bot | FAQs, trip history, how to lock | "How do I end a ride?" |
| 2 | Agent with templates | Verified instructions, standard refunds, force-end within policy | Stuck lock, double charge |
| 3 | Named human | Out-of-policy refund, vehicle recovery, safety pull | Injury, heat/smoke, repeat failures |
Self-serve first, then a templated response, then a named human with authority to issue a refund or force-end a ride. Fill in your own names on that last row.
Set a clock you can actually keep, and split it in two. First reply on a live ride is measured in minutes, not business days. Shop email about a scratched fender can wait until morning. Don't mix the two clocks.
If the rider is still on the vehicle, the next action is operational, not conversational. Give a verified instruction, arrange a staff inspection, move the unit out of rental inventory, or escalate to the platform or manufacturer.
When the ticket is a safety issue
Billing scripts do not belong on a heat or smoke report.
Say a rider messages that the deck is warm, or the pack smells like plastic, or they heard a pop and they're standing on a sidewalk with a live ticket still running. You can't drop that person into the same refund macro you use for a double charge, even when the instinct is to keep things light and keep the chat rolling.
Stop the ride in software. Tell them to get away from the vehicle if they can do it safely. Take the unit out of the rental pool. Charging and storage advice varies by model and battery pack, so don't invent a generic overnight-charging fix. Follow the manufacturer's steps for that product.
Lithium-ion fires on e-bikes and similar products are a documented hazard that U.S. safety regulators have been working to address. Your job in support is simpler than rulemaking. Don't send a compromised pack back into service. Don't coach a rider through a repair you can't verify.
Crash and injury reports go to the named human on Tier 3. Capture location, vehicle ID, time, and what the rider already did. Then stop. Support is not the claims department, and city crash-reporting rules are not the same in every jurisdiction.
Most playbooks skip this section. It's also the one that will hurt you if you skip it.
KPIs that change how you staff
Vanity ticket counts hide the real load. A sunny Saturday can spike contacts without anyone actually getting slower.
Turns out the useful number is contacts per 100 rides, not tickets per day. Drive that figure down with deflection first (help center, in-app lock help, clearer pricing) before you obsess over agent speed.
| Metric | How to read it |
|---|---|
| Contacts per 100 rides | Volume relative to actual usage, not calendar days |
| First contact resolution | Share of issues closed without a second touch. If 80 of 100 close first time, FCR is 80%. |
| Time to first reply | Split live-ride tickets from back-office email |
| Resolution time | Average time to a closed ticket, same split |
| CSAT | Share of survey respondents who say they were satisfied |
| Self-service usage | Help-center or bot sessions vs total contacts |
Help-desk formulas like FCR and CSAT only help if you tag tickets by type: lock, billing, damage, app, safety. Otherwise you average a 2-minute lock code into the same bucket as a 3-day insurance claim.
You don't need a dozen charts. Review the mix weekly. If your software can forecast busy areas over the next few hours, staff support before the first warm weekend, not after the queue explodes.
Train on the playbook you actually use
Handing someone a PDF is not training. Run one live shadow on a stuck-ride ticket, one damage photo comparison, and one out-of-policy refund. Keep each exercise small. Then drop the screenshots and a review date back into the playbook so the file stays the source of truth.
FAQ
Does a small bike shop need 24/7 support? Not if you don't run overnight rentals. Publish your hours. Route lockouts during open hours to a person who can walk to the rack. After hours, a recorded message plus a next-morning callback beats a phone that rings into a void.
How should we handle damage disputes? Start from checkout photos, not memory, and compare the same angles, marks, and accessory count. If the evidence is mixed, say so and follow the agreement the rider already accepted. Don't invent a new fee on the call.
What if someone reports a battery that feels hot? Treat it as a safety pull, not a troubleshooting chat. End the ride, keep people away from the pack if they can move safely, and leave charging advice to the model's own instructions.
Open your last 20 tickets and tag each one as reservation, vehicle, or software. Name the one person who can force-end a ride and issue a refund after hours. Then put those four intake questions at the top of the playbook and use them on the next live ride.