Lucid: Making Every After-Sales Promise Owned and Visible

01

The challenge

After-sales service is where a premium car brand keeps or loses its owner's trust. A car can spend days in the workshop waiting for diagnosis, parts or approval, and in that time the owner's questions are simple: when will someone call me, and when do I get my car back?

The Blueprint named the risk precisely. When the next contact and the promised return are held in someone's memory or spread across separate screens, a missed call does not look like a failure. Nobody sees it until the customer calls in. And a return date that quietly moves does more damage than one that was never given.

The scope came with firm boundaries. The new workspace had to stand on its own, with no connection to the CRM, and calls would still be made by people, outside the platform. Whatever we designed had to make follow-up dependable inside those limits.

02

Our approach

1. 01

   One record from booking to handover. The owner chooses the car, describes the concern, picks a service centre and an available slot, and confirms once. That request is the same record the service advisor opens, with nothing typed twice.

2. 02

   A deadline for every promise. Each active case carries an owned next-contact deadline with a reason. A rule-based queue sorts the advisor's day into overdue, due now and upcoming, and escalates to a manager when a promise is at risk. Advisors can override a deadline, but only with a reason.

3. 03

   Return promises with a history. Expected completion and handover are recorded separately, every change keeps its previous date and reason, and a changed date creates an obligation to tell the owner.

4. 04

   A status page the owner can trust. A secure page shows only reviewed, customer-safe updates. Private advisor notes never publish.

5. 05

   A concept the team could walk through. Before any production commitment, Ting built the front end in Arabic and English on fictional data and recorded the full journey: booking, advisor workspace, the recontact queue and customer status.

03

What was delivered, and how it will be judged

A Blueprint and a concept prototype, handed over for review. How a pilot would be judged is set out below; no result is claimed yet.

1. Handed overOctober 2026

   For stakeholder review: the solution Blueprint, with the workflow, data model, architecture, requirements and acceptance measures. Alongside it, the bilingual concept prototype and a recorded walkthrough of the whole journey.

2. How a pilot will be judged

   On three measures: contact made successfully and on time, the overdue backlog, and handover against the promised date. No improvement percentage is promised before a two-week baseline exists; targets are set from that baseline.

3. Optional later additions

   Approved customer messaging, and parts or fleet integration, each documented with its own approval.

The concept runs on fictional data in the browser: it shows the journey, it does not prove a result.