Digitalisation of the After-Sales Service Diagnostic flow

Digitising Customer Service within the allocated time to unify the App Artisans and Back Office to manage the flow of requests for re-interventions following a breakdown or incident during installation

The Customer Service process relied on numerous and heterogeneous documents, poorly guided pathways, and irregular re-interventions. As a Product Designer, I mapped out the key pathways, produced early wireframes, then developed a detailed design up to the final prototype ready for implementation. In 1.5 sprints, we aligned App Artisans and Back Office on a clear and 'standard' flow, understandable by the Craftspeople and relieving the customer relationship. So what: the Customer Service becomes manageable, predictable, and less costly in support.

Main screens functional pathways of Customer Service management in the App Artisans

Context

The project focuses on the digitalisation of Customer Service pathways through two complementary products: an App Artisans used in the field, and a Back Office operated by the customer relationship / operations teams. The core of Customer Service was heavily document-oriented (reports, photos, quotes, reports), with a heterogeneity that complicated reading and decision-making. At the same time, Customer Service cases were multiplying, and new types of documents were emerging, such as detailed quotes outlining the costs of items used for a repair.

The framework was also very constrained in terms of planning: the goal was to deliver a first functional version in one and a half sprints, which required a high level of pragmatism. Finally, a key point of the project was to digitise without disrupting the habits of the Craftspeople. In other words: aim for a clear and familiar experience, and avoid overly 'innovative' patterns that would increase the risk of misunderstanding or rejection.

Problem and objectives

The main problem stemmed from a significant volume of documents to decide upon, with decisions that could become slow and ambiguous when statuses and responsibilities were not sufficiently explicit. A second friction point concerned re-intervention: the process was not always smooth, leading to errors, delays, and sometimes 'ad hoc' rescheduling. Finally, the introduction of new types of documents (like quotes related to parts/items used) was not adequately integrated into the existing flow, creating a risk of circumventions or duplicates.

The project's goal was therefore to reunify the App and the Back Office around a clear flow, with understandable and explicit decision rules, and to make re-intervention actionable simply, in one or two steps from the Customer Service statuses. All of this should allow for the integration of these new documents without creating a 'second parallel system' and to remain consistent over time.

Role and strategic scope

In this project, I took on a end-to-end Product Designer role, from early wireframes to a detailed design of the pathways, then a final prototype ready for implementation. My scope covered, in particular, the definition of states, transitions, and rules related to documents, statuses, and re-interventions, as well as the synchronisation between the App and Back Office experience to ensure consistency of screens and responsibilities.

The project did not aim for a complete overhaul of product information; the effort was deliberately focused on critical Customer Service pathways, with a constant concern for implementability and delivery within the imposed window.

Approach

I first framed the issue by mapping the existing Customer Service flow, laying out the documents, actors, statuses, and identifying areas of ambiguity as well as re-intervention loops. This phase clarified where the blocking decisions were and what needed to be made more explicit.

Next, I produced wireframes to propose simple 'happy paths' and verify that the minimum steps were valid from both the Craftspeople's and Back Office's perspectives. From there, I detailed the pathways in the form of wireflows, describing states, transitions, prerequisites, and expected outputs, while focusing on the truly essential exceptions.

Finally, I consolidated everything into a final prototype, with key interactions, clear decision microcopy, and sufficient visual alignment between App and Back Office to serve as a direct basis for implementation. The bundling followed a sequencing logic compatible with the schedule: first the critical documents, then re-intervention, followed by the integration of new documents.

Key decisions

Several structural decisions guided the design. First, the standardisation of documentary statuses (to be provided, to be validated, validated, rejected) improved clarity at the cost of reduced flexibility in some rare cases. Then, I favoured an entry point by Customer Service intervention with a form of 'document requirements bar': the idea was to guide without overwhelming, even if it meant reducing total freedom in the order of actions to limit errors.

Re-intervention was made accessible from the Customer Service status with pre-filling, to prioritise speed of execution, accepting to defer very fine customisation of reasons. For 'used items quotes', the choice was made to integrate it as a quote type document (rather than a separate flow) to preserve system coherence while compensating for specific needs through dedicated fields.

Finally, the reuse of common components between App and Back Office (lists, timelines, viewers) improved maintainability and speed, even if it meant accepting a less 'bespoke' result. In terms of style, a pragmatic microcopy focused on actions was preferred rather than too much internal jargon, in connection with the customer relationship teams.

Solution and impact

Previously, the journey suffered from a lack of traceability and clarity: difficult-to-decide documents, re-interventions triggered by circumvention, and new documents managed too generically. Afterwards, the intervention becomes a readable unit, with a clear documentary checklist and explicit statuses, rapid actions (requesting a re-intervention, validating/rejecting, requesting supplements), specific integration of the used items quote, and a unified timeline linking documents, decisions, and re-interventions.

Regarding the impact, even without quantified metrics, the expected signals were clear: a better understanding of the journey by the Craftspeople without heavy training, fewer back-and-forth communications, and a more relieved customer relationship service thanks to quicker decisions and better visibility on the steps.

Learnings, artifacts, missing elements, and next steps

The project confirms that naming and limiting states immediately makes decisions clearer and the UI simpler. It also shows that staying close to field habits can be a lever for adoption, and that detailed wireflows accelerate product/business/tech alignment. Finally, adding value to the product through an iterative approach is a discipline that allows maintaining a short schedule without sacrificing coherence.

The missing elements mainly concern post-delivery verbatims, a measure of re-interventions avoided, the average time for document decisions, and comparative examples before/after. A realistic collection plan would include an in-app survey after two weeks, extraction and categorisation of customer relationship tickets over four weeks, a review of a sample of interventions before/after with timelines, a feedback session with Craftspeople and Back Office agents, and comparative captures of key screens. This was not done within the allotted time by choice.

Global wireflow of the final prototype:

Customer Service management from the Back Office:

Metrics

To evaluate the actual impact of the digitised Customer Service journey, we defined a base of metrics focused on adoption, execution quality, and operational load. The goal was not solely to 'digitise', but to verify that the new flow reduced field frictions, secured closures, and relieved the customer relationship. These indicators were designed as actionable signals right from V1, even in the absence of perfectly consolidated historical metrics.