Short answer: A customer booking app can work with the workshop software you keep when there is a supported way to exchange the required records. Before commissioning the app, confirm what the workshop supplier allows, which system owns each record and what happens when a booking cannot be confirmed. A successful screen demonstration does not establish that the integration works.
This guide is for automotive service businesses considering a custom customer app or portal. If your current workshop product already provides the customer journey you need, check that option first. A custom project is useful when the gap is specific: several branches sharing customers, an Arabic-first experience, or booking and service history that need to connect to your existing operation. Our automotive customer portals and apps page explains that scope.
Check the workshop interface before designing the app
Ask the workshop supplier and the person who manages it for the current integration documentation. An API is a supported connection through which software can request records or submit changes. Having an API does not mean every operation is available.
Confirm the practical limits:
- Can it read branches, services and available slots, and can it create, change and cancel a booking?
- Can the app read the relevant customer, vehicle, service-history and job-stage records? Which fields may customers see?
- Is access included in your agreement, or does it need a separate licence or supplier approval?
- Is a test environment available, with representative records and a named supplier contact?
- What access controls, request limits and version-change notices apply?
If only scheduled file exports are available, agree what can be kept current and what must remain a request for staff to confirm. A nightly export of free slots cannot establish that a slot is still available now. Record this limit before quoting an instant-booking experience. Compatibility with a named workshop product must be checked on that product and version; the EVS project does not establish compatibility with yours.
Decide who owns each record
Write down which system holds the authoritative value and which system may change it. Otherwise, a customer update and a staff update can overwrite each other without either team knowing.
The table below is an illustrative scoping worksheet, not a description of the EVS implementation. Complete it with your workshop owner before development.
| Record | Decision to make | Evidence to request |
|---|---|---|
| Customer and vehicle | How is an app user linked to the correct workshop records? Who approves changes or shared access? | A documented matching and access rule, including transfers and duplicates |
| Branch, service and slot | Which system decides availability, including staff-created bookings? | A demonstrated availability and booking-confirmation flow |
| Booking | Which identifier joins the app request to the accepted workshop booking? | A retrievable workshop reference and an agreed pending or rejected state |
| Job stage | Which workshop stages are appropriate for customers, and how fresh is the display? | A stage mapping and a clear treatment of delayed updates |
| Service history | Which entries can customers see, and how are corrections handled? | An agreed field list, access rules and correction owner |
The app and staff portal should use these decisions consistently. Web application development covers the staff and integration side; mobile application development covers the customer experience on iOS and Android.
Test the booking that times out
One of the most useful acceptance scenarios is also a common source of duplicate bookings: the workshop accepts a booking, but the app does not receive the response.
In a test environment, ask the delivery team to demonstrate what happens next. The app should retain a way to identify the same request, check whether it was accepted and avoid creating another booking during a retry. Until confirmation is established, the customer should see an accurate pending state and a recovery route, rather than a success message based only on pressing Submit.
Also test two customers choosing the same slot, a member of staff booking it at the counter, and a change or cancellation arriving during confirmation. The authoritative booking system must decide the outcome. If it cannot reserve or validate a slot through its interface, agree a staff-confirmed request flow instead.
Microsoft's retry-pattern guidance explains why repeating an operation can have unintended effects when the first attempt may already have succeeded. The acceptance question for a buyer is simple: can the team show one accepted booking after the lost response, with the same reference in both systems?
Keep customer access separate from sign-in
Knowing who signed in is only the first step. The system also needs to decide which vehicles, bookings and history that person may access. A phone number or vehicle identifier alone does not establish every permission, particularly when vehicles change hands or a company manages a fleet.
Agree how records are linked, how shared access is approved and removed, and what each staff role can do. Test access with separate accounts and representative data before launch. OWASP's object-level authorization guidance explains why access must be checked for the specific record and action, even after a user has signed in.
Give failed syncs an owner
A connection needs an operating process as well as a build. Agree which failures can be retried, how attempts are limited and how staff see the items that still need attention. Repeating a permanent rejection will not repair a missing required field.
Ask for a way to compare records between the systems and investigate mismatches. Decide who may correct a record, how the correction is recorded and when the supplier needs to be involved. If job updates arrive late or out of order, the display should not silently move a vehicle back to an earlier stage. These are design and acceptance questions for your interface, not guarantees about every workshop product.
Support arrangements should name the owners of the app, integration and workshop software, along with release, monitoring and recovery responsibilities. Agree access, hosting, data retention and handover requirements for the engagement before launch.
Keep the first release small enough to verify
Define one customer journey through to its workshop result. For example: sign in, select a linked vehicle, choose a branch and service, request a slot, receive an authoritative confirmation, and see appropriate status information afterwards. Choose representative branch, language and failure scenarios for the first release.
Writing job cards, approving extra work, managing parts and issuing invoices are separate workflows. Include one only when it has its own owner, interface access and acceptance criteria. Adding every workshop function to the first app makes the result harder to verify and the proposal harder to compare.
The EVS Customer Portal case provides a delivered reference: Arabic-first iOS and Android customer apps, a staff web portal and two-way synchronisation with the workshop system EVS retained. Customers can book, access vehicle and service information, and see workshop job stages. Job-card authoring or approvals, parts, billing and an AI enquiry assistant were not part of that delivered scope. The case is evidence of that project, not a ready-made licence or a promise about another supplier's interface.
What should you bring to the first conversation?
Send a short business brief: the customer task you want to improve, the workshop system and version, the branches involved, your language needs and who can confirm the available interfaces. Note where customer, vehicle, slot and job records live, if known. Our software scoping guide can help structure it.
Keep customer records, registration documents, passwords and confidential files out of the initial enquiry. If a technical assessment needs samples or access, agree a suitable sharing method and scope first.
Discuss your customer app and workshop integration. We can review the workflow and available interfaces, then set out a proposed first release, responsibilities and price in writing.
