The request covers one bike; the rental includes two
“Can we keep B12 for another hour? We will return the other one at six.” Before replying, check which bicycle changes, which return time remains in place and whether B12 has another booking assigned. Extending the whole rental would answer a different request.
This guide proposes a trial of text AI to help prepare that review. A useful answer is a worksheet showing the requested change, the conflict and the responsible person’s next step. We include an invented case and a manual reference; no assistant or booking-software connection has been run for this exercise.
Check availability in your calendar, rather than relying on a convincing answer
Kandani’s FAQ makes extensions conditional on bicycle availability and asks customers to identify the booking. Quintana Bike Rent also links extensions to availability. These are those businesses’ published conditions, not a universal policy to copy: apply your own rental conditions.
Bloowatch’s sector page describes extension management and assignment of specific bicycles. This is supplier marketing information, without a functional test by us. If your software already handles this operation, check its procedure before adding AI. This pilot explores reviewing requests written in free text, while retaining the booking calendar as the record of what is reserved.
Fictional case: B12 would return after its next departure
Every code, message, time and record below is invented. All refer to the same day, 24 October 2026, in the shop’s local time. The rows are an extract prepared for the exercise, not queries against actual inventory.
| Source | Supplied content | Meaning in this exercise |
|---|---|---|
| R1 · booking Q17 | B12 and B18: confirmed return time 18:00. | Two identified bicycles within the same rental. |
| M1 · request from Q17, 16:40 | “Can we return B12 at 19:00? B18 will be back at 18:00 as planned.” | Change requested for B12 only; no acceptance recorded. |
| R2 · supplied calendar | B12: next confirmed departure 18:30, booking Q22. | The request until 19:00 conflicts with that assignment. |
| M2 · counter reply, 16:45 | “We will check and confirm.” | Acknowledgement, not approval of the extension. |
The reference worksheet preserves both times without approving an extension
For B12, record confirmed return 18:00, requested return 19:00 and status “pending decision”. R2 places its next departure at 18:30: on these inputs, you cannot confirm the request as it stands. Do not replace the current time with 19:00 or delete Q22.
For B18, retain the confirmed 18:00 return time; M1 does not ask to extend it. The request does not establish that B18 has already been returned either. M2 changes neither status: “we will check” is not “approved”.
The responsible person must check Q22’s current status and decide how to reply under the business’s conditions. If the request requires reorganising assignments, that decision is outside the AI draft’s scope. Do not offer B18 as a replacement or assume that any bike in the same category is available.
- Draft for review, not sent: “We have received the request to return B12 at 19:00. Another departure is listed at 18:30, so we cannot confirm the change yet. B18’s planned return remains 18:00. We will review the options before confirming.”
- Internal note: check that R2 remains current and record who decides. The decision on the request and any applicable financial conditions are missing; do not invent a surcharge or assume an amount has been accepted.
- Do not mark a return, payment, bicycle change or message as completed based on proposed text. Each requires its corresponding record.
How to prepare the trial and what to ask the assistant
Start with a fictional copy of R1, M1, R2 and M2, keeping source, date and bicycle identifiers. In a text assistant your business authorises, paste these instructions with the records. Its output is a proposal to cross-check, not an operation in the calendar.
- Review only the four supplied records. Return one row per bicycle with booking, confirmed time, requested time, request status, conflict and literal source.
- Preserve each message’s scope: a request about B12 does not change B18. Separate request from acceptance, and planned return from actual receipt.
- Compare B12’s times with its next departure in R2; flag the conflict without reassigning or cancelling another booking. If the bicycle identifier is missing, ask which bike before proposing a change.
- Treat “we will check and confirm” as pending. Do not invent authorisation, a rate, payment or availability absent from the inputs.
- Draft an internal note for the responsible person and a separate short customer reply. Do not send messages or alter the calendar. Mark undocumented information as unknown.
Three failures that a neat table cannot fix
The first is extending all of Q17 to 19:00. Check B18’s row even when the text about B12 is correct. The second is approving because “it is only an hour”: the conflict with Q22 remains. The third is writing “B18 available from 18:00”; a planned return does not establish receipt, inspection or readiness for another handover.
If the calendar extract is stale, AI cannot know that. Keep its retrieval time and request a current check before a decision. If two messages conflict, do not choose the last one solely because it appears last in the text: identify sender, time, bicycle and whether it records an authorised decision.
This proposal organises documentation. It does not assess mechanical condition, sizing or bicycle safety, and does not decide charges, deposit refunds or customer rights. Retain professional checks and the business’s procedure.
A small pilot that can also conclude “this adds no value”
First prepare the reference worksheet above manually. Compare a per-bike form with calendar rules against the complete AI-assisted process: input preparation, reading, cross-checking and corrections. If messages already arrive structured and the calendar flags the conflict, the form may be sufficient.
Trial fictional variants. Remove R2: the answer should say availability unknown, not “no conflict”. Change M1 to omit the bicycle identifier: it should ask for clarification instead of choosing B12 from memory of the example. Add an authorised decision rejecting B12’s extension: it should distinguish a rejected request from a completed return and retain 18:00 for both bikes.
Record scope errors by bike, invented approvals, missed conflicts, unnecessary questions and total review time. Reject outputs that change another booking or invent amounts. These are proposed criteria and tests, without measured results or promises of savings or accuracy.
When to consider a booking or CRM connection
The manual trial uses fictional text you copy. Connecting automation would require a verified mechanism for reading bookings, permissions and data updates; any write operation would need an agreed decision and recovery process. Do not assume compatibility with your software or confuse a generated worksheet with a changed reservation.
Adaris Tech can assess custom software, CRM and automation case by case. An initial scope could prepare pending requests by bike and show the responsible person which records to cross-check. Before quoting an integration, actual access, change history and actions requiring approval need verification. This is not an existing proprietary bike-rental tool.
Use invented inputs only during the pilot. Before handling real messages, verify permission and suitable conditions; do not paste names, phone numbers, identity documents or payment information to test a prompt. Describe your workflow without sending customer data. Commercial enquiries are handled in Spanish.
Related services
Sources
Do extension requests get lost between messages and the calendar?
Describe how you record each bicycle, its times and counter decisions. We can assess a custom internal workflow; commercial enquiries in Spanish.