Mobile app for auto repair shop — booking, statuses, push notifications

Mobile app for an auto service: where booking breaks

A client calls reception at the height of a shift: the administrator is at vehicle handover, the technician is under the lift, the line is busy, and there’s no one to call back.

An hour later, the person books where the phone was answered on the first try, and the freed slot in the bay schedule remains invisible to everyone.

Then the failure accumulates. The car is already being worked on, but the client receives the repair status only by phone—the same calls that reception doesn’t have time to answer.

Missed calls to reception grow not because the administrator is slow, but because there is only one channel: voice.

From the shop floor side, this looks like uneven loading of auto service bays. The morning is overloaded, the after-lunch window is empty, the technician learns about a reschedule when the car is already raised on the lift, and approval of additional work happens blindly.

The reason is not discipline—between the client, reception, and the bay there is no single booking state: the slot lives in one log, the work in another, the status in a third head.

Online booking for an auto service, status change notifications, and online bay loading are not “another app” but one data model: slot, technician, stage of work, and client are linked into one record, and any change in it is immediately visible to all participants. Below we break down how this is addressed.

What launch changes: booking, statuses, repeat visits

The app launch is justified not by its interface, but by the fact that part of reception’s work moves out of phone calls. We measure the effect by metrics from analytics and request logs, and record baseline values before release—otherwise there is no way to confirm improvement.

• Share of bookings without a call — how many slots the client booked themselves: service, date, bay, confirmation. It shows what portion of the initial flow no longer goes through reception’s phone.
• Request response time — from form submission to technician confirmation. We look not at the average but at the tail: delays during peak hours hurt loyalty more than general statistics.
• Vehicle readiness notifications — how quickly the client learns about a status change and how many incoming “what’s happening with the car?” calls remain at reception. These are directly saved minutes on every work order.
• Repeat client visits — the share who return for the next service based on an app reminder rather than an administrator’s call.
• Reduced reception workload — how many requests an employee handles without quality loss and how many minutes per day are freed up for live consultations.
• Consistency with the management system — statuses, work orders, and service history are pulled from the service system via integration with 1C; data is not entered manually twice.

We take metrics at one cut: several weeks before launch and the same period after. If an item does not move, we analyze the funnel—exactly where the client dropped off: at slot selection, confirmation, or status.

Product format: cross-platform, native, web

An auto service needs three things: the client books a convenient time, sees the status of work, and receives a notification when the car is ready.

The difference between development options is not in the set of screens, but in which phone capabilities are accessible and how much code must be maintained in parallel.

The dividing line runs through notifications and offline operation. System delivery channels work reliably only in an installed app: they wake the screen even when the program is closed.

The web version depends on an open tab, so the critical “car is ready” status is easily missed through it.

In practice, a combination is chosen: a single codebase covers booking, history, and statuses; a native client adds what requires direct access to the device; and the web version remains an entry point for those who do not want to install anything.

We describe this set at the start—so the product does not have to be rewritten when new scenarios appear.

How we run the project: from process analysis to release

A mobile app for an auto service breaks not on the screens but at the junction with the service management system.

A request from the app must fit into the same schedule of bays and technicians as a phone booking—otherwise the administrator maintains two schedules manually and reconciles them from memory. That is why we start with analyzing the service’s processes and only after that write code.

1. Process and role analysis. We look at how a car is received, who reschedules a booking, what is done when a client refuses—and record this as a request status scheme shared by the app and the management system.
2. Data schema and integration points. We determine which entities remain the source of truth in the management system, what is cached in the app, and what is requested on the spot.
3. Integration prototype. We assemble a minimal loop: request creation, slot confirmation, status change. We check idempotency—a repeated submission during a connection drop must not create a second booking.
4. Client-side build. Booking, service history, repair statuses, push notifications about readiness. The synchronization state is visible to the user: request sent, accepted, confirmed.
5. Testing booking scenarios. We run through slot conflicts, double bookings, cancellation an hour before the visit, and offline operation. On an anonymized copy of the service database, not on made-up data.
6. Pilot at one branch. We look at the live flow: how many requests arrive without an administrator’s call and where the connection with the management system breaks.
7. Handover of the project to the client. Configurations, integration schema, release regulations, and training the service team to work with requests.

What the service keeps: code, access, regulations

The project ends not with a demo on a phone but with the handover of everything the app consists of: the service remains the owner of the code, accounts, and operating rules.

We verify this before closing the project—if at least one item has not been handed over, the work is not considered delivered.

• Source code in the repository: both platforms, change history, release branches, owner read and write rights; handover is recorded by an act, not a message in a messenger.
• Build and release of versions: where signing keys are stored, how to build a release build, how to publish an update to app stores.
• App documentation: module diagram, description of the booking flow and order statuses, map of external services—management systems, telephony, payment, notification delivery.
• Service administrator access rights: role matrix—technician, administrator, manager; who creates, reschedules, cancels a booking, views history, and exports a report.
• Regulations for working with bookings: procedure for rescheduling, no-shows, lateness, and order closure; which status an employee sets at which moment and which notification is sent to the client.
• Employee instructions: short guides for each workstation, from vehicle reception to order closure.
• Update regulations: how a new version is released, in what order the app is updated, and how to roll back to the previous build in case of failure.

Access is issued to your accounts in app stores and on the server side, so changing contractors does not turn into restoring the system from fragments of correspondence.

Case study: auto service chain — bookings without calls and statuses

The mobile app case study for an auto service chain began with a bottleneck in the schedule: bookings were accepted only by phone. During peak hours, the operator could not keep up—clients got through on the second or third attempt, and slots sat idle after cancellations. Clarifying calls of “is the car ready?” ate up a noticeable part of administrators’ time.

What we changed

We made an app where the client selects a service, sees free slots for a specific bay, and confirms the booking themselves. The slot is occupied in the schedule immediately and, upon cancellation, is freed for the next in line—idle time does not accumulate.

The work status changes on the service side: “accepted,” “in progress,” “ready for handover”—and arrives to the client as a push message. The booking is added to the phone calendar (Google Calendar) with one button.

What the metrics showed

The share of online bookings grew from 14% to 71%; the rest is complex repair and estimate approval.

The average time from inquiry to confirmed slot dropped from several hours to minutes: previously the client waited for an operator, now the slot is confirmed at the moment of selection.

The number of clarifying calls about status fell by about three times—the status is visible in the app, and a push arrives at the moment the stage changes.

The load on the call center was redistributed: operators coordinate estimates and parts instead of rescheduling bookings. Repeat client inquiries grew—people return where booking takes a minute and requires no clarification.

Next, we are developing scheduled maintenance reminders: they bring clients back to the service at the right mileage, not when something breaks.

What to do if the service already has a management system?

The management system remains the source of truth: work orders, vehicle service history, and the service catalog live in it. The mobile app is not a replacement for the management system but another client that reads and writes data through an integration layer.

There is no need to change the system just for phone booking if it exposes data outward—for example, 1C through a published interface or database access.

Data exchange about bookings is bidirectional: outward—free slots, work order statuses, and approvals; inward—new booking, rescheduling, and cancellation. The service catalog is transferred once at launch: categories, jobs, standard durations, linkage to bays and technicians.

After that, synchronization is by changes, not a full reload of the catalog—otherwise the catalog diverges from the management system after the very first edit.

A separate risk is a connection drop at reception or in the shop. Requests do not leave at the moment of pressing but enter a local request queue on the device and are sent when the channel is restored.

Each is marked with an identifier, so a repeated submission does not create a duplicate, and the client sees booking confirmation only after the management system responds.

Which option is realistic in your case depends on what the system can expose today. Describe what management system you have and who owns it—we will come back with an estimate and a connection plan.

Technical questions before development starts

Before the start, clients ask the same four questions: what will happen after launch, how updates are released, what the technician will see offline, and who owns the finished app. We answer briefly—details are discussed on a call.

How are updates released?

The build runs automatically after checks; publication is staged: first the new version goes to a small share of users, we look at the crash rate and response speed, then roll it out to everyone. Rollback is a return to the previous version.

Some content (booking rules, texts, statuses) is edited on the server side and reaches technicians without releasing a new app version.

Does the app work offline?

Partially and deliberately: request cards, work history, and statuses are available from local storage because the connection in the bay is unstable. New bookings and status changes are queued and sent to the server when the channel appears.

During synchronization, the “last change by server time” rule applies—two technicians will not overwrite each other's status. We deduplicate notifications: one event—one message, even if it arrived both via the data channel and when opening the app.

Who owns the rights to the app?

You do. Accounts in app stores, signing keys, repositories, and server settings are registered to the client from day one.

Handover is not exporting an archive but access, build documentation, and release instructions: after that, your team or another contractor continues the work without our involvement.

Let’s discuss the task: booking, statuses, notifications

To make the discussion of the development task substantive rather than at the level of “we want it convenient and beautiful,” it helps to come with a few inputs. Preparing them in advance is not required—we will go through half the questions together.

But if something from the list is at hand, the development timeline estimate and app work plan will be more accurate on the first pass, without extra rounds of clarification.

• How you handle booking now: phone, messenger, spreadsheet, or management system—and at which step a request is most often lost.
• The full set of order statuses: accepted, in progress, waiting for a part, ready, handed over—and which employees switch them manually.
• Which booking scenarios are needed: selection of bay and technician, free windows, rescheduling and cancellation of a visit, repeat inquiry for the same car.
• What notifications go out and to whom: to the client—confirmation and vehicle readiness; to the technician—a new booking; to the manager—daily load.
• The data you work with: visit history, vehicle numbers and makes, whether they need to be pulled from an existing system or entered anew.
• Who on your side accepts the result and how we verify it: test accounts, a list of scenarios, access to the booking system.
• Constraints that cannot be moved: launch date, number of service locations, employee roles with different rights.

On our side, we come back with a development timeline estimate and an app work plan: a breakdown by booking and status scenarios, what we do first, and where data or access from you is needed. Describe the task in free form—that is enough to begin the analysis.