Skip to Content
FeaturesCustomer-safe states

Customer-safe states

Customer pages should explain what is happening next without exposing internal staff notes, provider internals, private document links, or role handoff internals.

In the customer portal, Book is a vehicle-first flow: search or page through every owned vehicle, choose a plate, branch, service, and an API-supplied available time before adding optional notes. Availability is loaded in one bounded batch; a temporary failure for one branch/service pair leaves the remaining verified times usable and explains the partial state. A successful request opens the new booking detail with Requested status, and returning to Book creates a fresh request intent. Your profile keeps contact and address editing separate from workshop service records. Opening an active service shows the plate, current stage, the next expected step, customer-visible timeline entries, and visit facts; refresh the page for the latest server-confirmed state. A stage label describes workflow state, not a measured completion percentage. Expand About the service stages for explanations and Notes and vehicle details for optional visit facts. A malformed or unavailable response shows a fixed safe state instead of a partial booking, profile, or service record.

Use Bookings to review every authorized booking and open its detail. A requested booking can be cancelled from either the list or detail after the server rechecks customer ownership and current state; confirmed, completed, cancelled, or otherwise progressed bookings remain read-only. Use Services for the complete paginated active-work queue and Approvals for every current estimate awaiting a decision. Previous and Next belong to the current queue and page size, so do not treat the home-page summary card as the complete record. Home puts vehicle and recent-service counts beside their destinations, and shows balances by currency in Invoices. Recent services are an overview; open the destination for the complete queue.

The service overview chooses one returned pending approval or active service as the primary vehicle card. It does not guess permissions or workflow transitions. The approval page confirms the plate, vehicle, service, total, and current estimate version before showing decisions. Historical, superseded, already-submitted, empty, unauthorized, or malformed responses remain read-only or fail closed. A PDF may be unavailable while the customer-visible line items remain usable.

Private document and generated-PDF links are created only after an authorization check and expire after 30 seconds. Open them immediately; if a link expires, return to the protected page and request a new one. Access is checked again before every replacement link is issued.

Customers can add another vehicle from My vehicles when it is missing from their garage. Garage search and pagination cover the complete current-owner set instead of stopping at a fixed list cap. Customers can also edit their own vehicle identity, mileage, ownership label, and nickname. Identity changes to an approved vehicle return it to the workshop’s verification policy; a transferred, stale, or guessed vehicle cannot be changed, and a failed audit saves nothing. New vehicle records follow the workshop’s verification settings: some are ready immediately, while others remain pending until staff verify the details.

The portal home calculates outstanding invoices across the complete owned-customer invoice set and shows a separate balance for every currency. It never adds unlike currencies together or treats the first invoice page as a complete total.

The garage uses the registration plate as the main recognition label. Open a vehicle to review its identity, mileage, verification state, private documents, and vehicle-specific history. A document section can be temporarily unavailable without hiding the vehicle or its history. Uploads and every view/download request are authorized again by the server; Motornauts never displays storage links.

History is paginated newest first. History shows every service record currently available to the customer, while Garage → vehicle → Vehicle history limits the same protected history to one currently owned vehicle. Use Previous and Next rather than treating the first page as the complete record. Pagination is omitted when all results fit on one page. The plate, not an internal repair-order identifier, identifies each row.

Vehicle entry uses a Motornauts maker list instead of open make text. Customers and public registration visitors choose the closest listed maker, enter the model as guarded text, and use letters, digits, spaces, or hyphens for the registration number. If the maker is missing, contact the workshop so staff can route the request for review instead of entering an invented make.

Customer self-registration can remain provider-not-ready when bot protection, external email/SMS delivery, or Motornauts support review is not ready.

Tenant Admins configure this under Settings → Customer registration. Enabling the module does not automatically accept public requests: public intake has its own control, default active branch, and public terms copy. A settings change cannot approve an applicant, create a customer or vehicle, grant portal access, or replace consent and Turnstile checks. Those actions remain in the guarded review and public-submission flows.

Back to Customer Workflow

Last updated on