Prendre rendez-vous en ligne

Avant ce projet, prendre rendez-vous passait par un appel, une attente, puis un rappel quand un créneau se libérait. J'ai conçu un service qui permet aux clients de réserver 24h/24, en choisissant eux-mêmes le sujet, le canal et le créneau.

Rôle
Product Designer · Lead
Contexte
App mobile + web
Période
En production depuis 2024
Objectif

Réduire la charge du service client en permettant aux clients de prendre rendez-vous en autonomie, tout en qualifiant automatiquement le bon interlocuteur et le bon canal.

Interface desktop de prise de rendez-vous Interface mobile de prise de rendez-vous
Impact mesuré, 6 mois après mise en production

-35%

Appels service client

sur les objets concernés

40%

Taux de complétion

sur le MVP

Données générées

Motifs demandés

La banque dispose pour la première fois de stats automatiques sur les motifs de rendez-vous les plus demandés

Le problème

Les utilisateurs avaient deux options : appeler ou demander à être rappelés. Dans les deux cas, c'est le service client qui rappelait quand un créneau se libérait. Aucun choix de créneau, aucun choix de canal, et pas toujours le bon interlocuteur.

Côté banque, la gestion manuelle consommait beaucoup de temps opérationnel et ne remontait pas automatiquement de données sur les motifs de rendez-vous les plus demandés.

L'enjeu allait au-delà de l'interface : il fallait qualifier précisément l'objet du rendez-vous pour interroger les bons agendas, gérer des règles métier spécifiques (canal imposé selon le motif, délai minimum de 48h sur certains cas, limite de 2 rendez-vous actifs, exclusion des mineurs et personnes sous tutelle), et couvrir des cas particuliers comme le retrait en devises étrangères, le tout sans exposer cette complexité à l'utilisateur.

Approche

Benchmarker l'effort utilisateur chez les concurrents.

J'ai analysé les patterns de prise de rendez-vous chez plusieurs banques concurrentes, en mesurant l'effort utilisateur de chacune, avant de concevoir.

Extrait du benchmark
Extrait du benchmark sur l’effort utilisateur chez chaque concurrent.

Cadrer les règles métier avec le service client, les conseillers agence et l'IT.

Cadrage réalisé avec CP, BA, IT, service client, conseillers agence. Chaque motif de rendez-vous a ses propres règles : canal imposé (téléphone ou agence), délai minimum, interlocuteur cible. Ce cadrage a directement alimenté le wireflow.

Prototyper le parcours mobile.

Le wireflow et les wireframes ont été construits en parallèle, mobile-first. Une fois validé, le parcours a servi de base de référence pour la suite du projet.

Wireflow du parcours
Wireflow du parcours.

Co-construire l'affichage desktop avec le développeur.

Pendant le développement desktop, le dev web a remonté un problème que je n'avais pas anticipé : le volume de créneaux possibles rendait l'interface ingérable. On a co-construit la solution ensemble, un affichage progressif avec un bouton "voir plus d'horaires", une approche qui n'aurait pas émergé sans cette collaboration directe.

Affichage des créneaux sur desktop
Affichage de première plages horaire. Un bouton “voir plus” pour voir les suivantes.

Livrer et suivre les premiers résultats.

Traductions transmises avec liens textes/écrans pour les développeurs, Design Quality Check réalisé.

Décisions clés

Qualifier l'objet en premier

Délai de 48h, aucun créneau disponible, limite de 2 rendez-vous actifs : chaque cas a un message précis et une sortie de parcours claire, plutôt qu'un renvoi générique vers le service client.

Rendez-vous affiché
Rendez-vous affiché
Maximum 2 rendez-vous
Maximum 2 rendez-vous
Un carrousel d’affichage des rendez-vous pris, limité à 2 maximum.

Cas particulier : retrait en devises

À la sélection de ce motif, une zone d'information s'affiche immédiatement (les retraits inférieurs à 5 000 € en euros ne nécessitent pas de rendez-vous). Le champ montant bloque la progression tant que les conditions ne sont pas réunies. L'utilisateur reçoit ensuite une date de disponibilité des fonds : pas un créneau strict, mais le moment à partir duquel il peut venir retirer.

Ecran pour les retraits
Etape bloquée si le montant est inférieur à 5.000 EUR
Ecran de confirmation du retrait
Indication du créneau pour venir retirer les fonds en agence

Création du composant bottom sheet contextuel

Pour afficher les cas d’erreur, les créneaux réservés au même moment ou les confirmations de suppression, j’ai mis en place un composant bottom sheet contextuel.

Conçu pour remplacer les anciennes pop-ups héritées du web, je l’ai documenté et il a pu être réutilisé sur d'autres projets, notamment la refonte du parcours de connexion.

4 variantes selon le contexte : succès (vert), info (bleu), warning (orange), erreur/suppression (rouge).

Annotation pour création du composant bottom sheet
Annotation pour création du composant bottom sheet.

Détails qui comptent

Agence habituelle du client remontée en priorité dans le sélecteur. Jours fériés affichés comme désactivés dans le calendrier. Barre de progression et récapitulatif avant confirmation, pour que l'utilisateur garde le contrôle à chaque étape.

Résultats et preuves

Le MVP a réduit de 35% les appels au service client sur les motifs concernés, avec 40% de taux de complétion dès la mise en production.

La banque dispose désormais de statistiques automatiques sur les motifs les plus demandés, une donnée inexistante avant ce projet, et qui alimente directement la priorisation du lot 2.

Les données de production ont aussi révélé un taux d'abandon sur l'étape de sélection du motif. L'analyse pointe deux causes : une zone de friction réelle sur la liste, et une curiosité utilisateur, des clients qui exploraient sans intention de réserver immédiatement.

Ce signal, et les fondations techniques posées par ce projet, définissent clairement le périmètre du lot 2 : simplification de la liste des motifs, regroupement, meilleure signalétique d'entrée.

Ce que j'en retiens

"L'affichage progressif des créneaux n'est pas né d'un brief, il est né d'un problème remonté par un dev en cours d'intégration. Les meilleures solutions viennent souvent de cette collaboration au-delà du handover."

"La bottom sheet conçue pour ce projet a été reprise sur la refonte de la connexion, puis sur chaque nouveau projet. Penser réutilisabilité dès le départ, c'est contribuer au design system, pas juste au livrable."

Prochain case study

J'ai simplifié un parcours B2B de commande de cartes bancaires en naviguant 3 changements de PM et des contraintes réglementaires lourdes.