Mobile app for car wash: booking, queue, subscriptions

Mobile app for car wash: where booking and queue break down

The flow of cars breaks down not at the wash itself, but at the entrance — where a request turns into an occupied slot. While car wash booking lives in calls and messages, the administrator keeps three schedules in their head at once: phone, messengers, and the yard. As soon as a client without a reservation arrives, the order is reassembled manually.

Here the live queue also kicks in, which has no shared state with the booking. A client with a confirmed reservation arrives at their time, but the bay is occupied by a car from the yard accepted 'for five minutes'. The slot shifts, the next one after it too, and the evening peak turns into accumulation.

Lost bookings are not the administrator's forgetfulness, but the absence of a single log.

A request from a chat does not create a calendar event, does not block a bay, and does not send a reminder, so the client does not show up, and the window between arrivals can no longer be filled. Thus, idle bays are paid for by the shift's revenue.

Subscriptions add a second layer: the remaining washes, expiration date, and binding to the car number live separately from the schedule. Write-offs are done manually, discrepancies surface during reconciliation.

We analyze exactly where controllability is lost and what the system must hold: a single slot, confirmation, reminder.

What launching online booking changes: bay utilization and repeat visits

Online booking changes not the interface, but the flow itself: the client chooses not 'I'll come in an hour', but a specific slot of fixed duration for their body type.

The grid step and separate windows for express washing and comprehensive washing provide even bay utilization — the operator stops manually distributing cars during the morning peak, and the spread of occupancy between bays is reduced by about three times.

Client no-shows drop with the 'deposit — confirmation — reminder' bundle.

Prepayment for a slot cuts off random bookings, a reminder a couple of hours before collects confirmation in one tap, and an unconfirmed slot automatically returns to the grid and goes to the first person on the waiting list.

The no-show rate decreases from a quarter of bookings to single-digit values — these are freed-up hours that do not need to be compensated by overtime shifts.

The car wash subscription moves into the app and is issued as a pass in Apple Wallet: the remaining visits are visible on the lock screen, the write-off is tied to the actual arrival, the administrator does not call and does not keep a paper ticket.

The visible 'two washes left' itself encourages returning earlier, so the share of clients with a subscription grows, and the average interval between visits decreases.

Repeat visits are supported not by a 'wash your car' newsletter, but by a fact-based trigger: the interval since the last arrival plus a seasonal coefficient.

In the report, this is visible as two independent curves — slot occupancy and the share of returns within a month; they are used to configure the booking grid and subscription terms.

Launch options: ready-made solution, accounting system customization, custom product

The choice between the three paths is rarely made by taste — it follows from what already works in the car wash.

If bookings are kept in a messenger or notebook, and there are two or three bays, it is faster to connect a ready-made booking service: it covers booking, reminders, and repeat visits without modifications.

If accounting is already kept in a system with client cards and a cash register, it is more logical to customize the accounting system — the app becomes its continuation, not a second data island.

A custom product is chosen when the logic is non-standard: several locations, washer shifts with order distribution, subscription tariffs by number of washes and body type.

The common bottleneck for all three options is the same: migrating the client base and integrating with the cash register.

Migration is not just phone numbers and names, but the history of visits, binding to the car by license plate, and the balance of paid washes in the subscription, otherwise a client arrives with an invalid subscription and leaves.

Integration with the cash register determines whether the order will be closed upon completion, whether a receipt will be issued, and whether funds will be returned correctly upon cancellation — it is these two areas that determine the real launch timeline, not the choice of option. Below we analyze how migration and the cash register link are handled on each path.

How implementation goes: from shift analysis to handover to support

The order of work is the same for a two-bay car wash and for a network: first we analyze how the shift actually works, and only then we write code.

An app breaks not on the screens, but on the discrepancy between how booking is set up in the system and how the operator manages it, standing by a car with wet hands. Therefore, we look at the shift as a whole — from opening to evening cash register closing.

1. Analysis of car wash processes. We count the flow: how many cars in the peak window, what share arrives without a booking, how manual washing differs from self-service in duration. We record where clients are currently lost and how much time the operator spends on phone calls.
2. Designing the booking scheme and bay schedule. We determine what is booked to a bay and what to an employee, how the duration is selected by body type and service, where we place a buffer between cars. The bay schedule gets rules: working window, breaks, equipment maintenance, seasonal load.
3. Subscriptions and queue. We define trip write-offs, binding to the car number, limits, and freezing; the live queue — with a clear status «booked / arrived / in bay / done», so the operator does not keep it separately on paper.
4. Assembly and configuration. We implement the client app, operator panel, and integration with the car wash accounting system: services, bays, employees, subscription tariffs. We separately design behavior for weak network — the booking must not be lost if the connection drops.
5. Testing on a live shift. We go out to the real flow: two engineers stand at the bays during peak, watch for booking overlaps, double taps, operator errors. Fixes go in the same day, not to the backlog for the next month.
6. Handover to support. We provide regulations for the administrator and operator, instructions for typical failures, accesses, and the update procedure. Then we run the app on an agreed release rhythm.

What you keep: settings, diagrams, shift regulations

The app does not remain a 'black box': along with the release, you receive documents according to which your team and a new administrator work without contacting us. Everything is stored in your environment and updated with every configuration change.

• Configuration passport: service durations, number of bays, slot rules, breaks, online booking limits, and promo periods — with a note on what each parameter affects.
• Integration diagram: which systems exchange data, in which direction the flows go, and what happens to a booking if payment or the loyalty program is unavailable.
• Roles and accesses: a rights matrix for the owner, manager, operator, and washer — who edits the schedule, who sees revenue, who processes refunds and subscriptions.
• Shift regulations: opening and closing, handling a late client, rescheduling a booking, manual queue management during peak hours.
• Administrator instructions: step-by-step scenarios with references to screens, typical errors, and the procedure if a booking was not created.
• Update and rollback procedure: how a new version is released, where to find the previous build, and how to revert to it without losing bookings.

Handover is done through review, not an archive: we go through the documents together with the administrator, check accesses on a test bench, and record responsible persons. After that, you change settings yourself, and we get involved where code modifications are needed.

Car wash network case: booking, queue, and subscriptions

The АкваРитм network — 14 locations with six bays each. Before the project, booking lived in the operator's phone and in the window at the entrance: during Saturday peak, bay idle time reached 22%, and a queue of cars waiting for a bay lined up in the yard.

The administrator spent the shift on callbacks and manual slot reconciliation instead of working with the flow.

Measurements were taken from the same set of sources — the booking log, bay accounting data, and app login logs — before launch and a quarter after.

What was changed in the booking core

The bay slot was made a transactional resource: a reservation is held for 7 minutes and released automatically, so two clients do not occupy the same bay even with poor connectivity.

The subscription became a separate entity with a wash limit and write-off upon completion — the log at the counter is gone, and the balance is visible in the app.

What it gave

Repeat bookings grew due to a reminder an hour before the slot and an offer of a free window at the same location.

The administrator's load shifted from coordination to the floor, and bay idle time during peak decreased threefold — the queue in the yard stopped blocking the entrance.

How does online booking differ from calling the administrator?

Online booking wins in template scenarios: the client chooses the day, free slot, wash type, and bay, and booking confirmation comes immediately.

A call has three weak points at this moment — a busy line, a slot that the administrator holds in memory, and the absence of a written record. An error or delay then has to be investigated anew.

The live queue shifts into the app. An occupied slot is instantly closed for others, so two clients do not end up at the same time.

In a log during busy hours, this happens regularly, and the conflict has to be resolved in front of the client when there is nothing left to rearrange.

The administrator's load drops predictably: typical booking, confirmation, reminder, and rescheduling go into automation, leaving exceptions to the human. The client reschedules themselves in a couple of taps, the freed slot goes back on sale — without 'couldn't get through'.

The administrator does not disappear, however. Complex work — polishing, interior dry cleaning, restoration — requires on-site assessment, and doing it by voice is faster than a form.

There remain slot conflicts, regular clients with personal terms, and subscriptions: it is convenient to keep the card in Apple Wallet, but extension and write-off using it are sometimes easier to agree in a conversation.

The working scheme is 'and', not 'or': the app covers mass booking and subscriptions, the phone remains a channel for the complex. Below we analyze how this is assembled — schedule, slot rules, and confirmations.

Common technical concerns: payment, queue, equipment

Before launch, the client asks the same set of questions: how to accept payment, what to do with subscriptions, how the app will survive connectivity interruptions, and how it is connected to the bay equipment. Below are short answers for each node.

How is the subscription written off?

The balance is stored on the server and written off upon order closure, not at booking. If there is no connection, the operation is queued and applied exactly once.

A client arrived without a booking — will they get into the system?

The operator creates the order in the admin panel, the client receives a notification, the history is linked to the phone number. After that, they book themselves.

What happens during connectivity interruptions?

The app shows the last loaded data, new operations accumulate locally and go to the server when the connection returns. The bay does not sit idle.

How is the app connected to the bay equipment?

We exchange commands with the bay controller or accounting system: starting the wash program, occupancy status. Old equipment is connected via an intermediate module.

What notifications does the client receive?

A reminder before the booking, a message when the bay is ready, a warning about subscription expiration. Channels — push notifications and SMS, enabled in settings.

Let's discuss the task: we'll show how booking will work at your car wash

So that the project estimate is based on facts, not average market figures, we start with an analysis of your car flow: how a client gets to the wash today — call, messenger, administrator's desk; how many bays and shifts; how subscriptions are calculated; what happens to a booking when a car is late. This is enough to propose a queue scheme and cancellation rules without guesswork.

• Discuss the task — a 40–60 minute analysis: bays, shifts, service types, share of repeat clients, where bookings are currently lost.
• Project estimate — scope of work by stages, team composition, timelines, what we cover with our own resources, and what remains on your side.
• Implementation plan — order of steps: booking and live queue, subscriptions and their write-off, administrator and owner dashboards, client notifications.
• Pilot at one car wash — we launch at one location, look at the real load of morning and evening windows, and adjust queue rules based on facts, not assumptions.
• Post-launch support — on-call for failures, updates for new system versions, improvements based on feedback from the car wash.
• What is required from you — access to current accounting, list of services and subscription terms, one person for rule approval and acceptance.

Describe the task in a convenient format — we will return with a project estimate and implementation plan, and specify timelines and scope of work.