Études de cas / Bureau d’opérations CRM

Implémentation de référence

Un CRM contre lequel
la finance peut clôturer

Ce texte décrit le bureau d’opérations que nous livrons aux équipes ventes et finance sorties du tableur et du défaut éditeur. L’interface ci-dessous est un simulateur déterministe — pas un compte client nommé.

Six sections

Ce que ce cas couvre vraiment

Les textes clients nommés attendent une validation. Cette page est la référence : les six mêmes sections, écrites contre un bureau cliquable.

Contexte et contraintes

Huit sièges commerciaux, pipeline dans un tableur, factures dans un autre grand livre, pas d’identifiant de compte partagé. La contrainte n’est pas « plus de champs », c’est un modèle contre lequel ventes et finance clôturent, avec RBAC plutôt qu’un login partagé.

Ce qui a été construit

Un bureau à quatre surfaces : KPI et activité, board à cinq étapes, registre des deals et vieillissement des factures. Une fiche deal montre owner, source, probabilité et prochaine action. Les deals gagnés restent sur le même compte que leurs factures.

Décisions d’architecture

Une entité compte pour société, deal et facture — pas un job de sync CRM vers ERP. Les changements d’étape sont des événements. La démo publique est un simulateur déterministe, crawlable et cliquable sans backend.

Stack technique

React 19, TypeScript et les mêmes primitives : Card, Table, Tabs, Dialog, Badge, Progress. En livraison s’ajoutent une couche d’intégration Node.js, PostgreSQL et un journal d’événements. La démo n’appelle pas ces services.

Résultat vérifiable

Aucun résultat client nommé ici. Vous pouvez vérifier l’interface : valeur de pipeline, win rate, relances en retard et créances bougent sur un tick de 20 minutes.

Ce que nous changerions

La démo laisse encore le RBAC au niveau champ et les adaptateurs mail/téléphonie dans le texte. En livraison, nous les sortirions en écrans dédiés — matrice de droits et journal d’intégration rejouable.

Démo en direct

Le bureau en marche

Paramètres : 8 sièges, 18 slots de deals ouverts, objectif trimestriel 420 k€, ticks de 20 minutes. Aucune donnée client, aucun grand livre live, aucun mail sortant.

Démo interactive. Les chiffres sont synthétiques et ne représentent aucun compte client nommé.
Bureau d’opérations Northwind8 sièges · 18 slots de deals ouverts · €420.0k objectif trimestriel
7 relances en retardLiveLun 09:00
Pipeline ouvert100%
€460.3ksur €420.0k
Win rate
67%€70.1k gagné sur le cycle
Deals ouverts
15Opportunités actives hors won et lost
CréancesEn retard
€42.6kFactures envoyées et en retard
CA clos, 8 semaines

Bookings hebdomadaires synthétiques pour la densité du graphique, pas un grand livre live.

W-8W-7W-6W-5W-4W-3W-2W-1
Activité récente

Appels, mails, réunions et changements d’étape générés par le simulateur.

  • Mail de relance envoyé
    Helios Grid
    −1h
  • Session de travail planifiée
    Nordic Charge
    −1h
  • Appel consigné
    Vistula Media
    −2h
  • Session de travail planifiée
    Rhine Storage
    −3h
  • Mail de relance envoyé
    Baltic Ports
    −4h
  • Session de travail planifiée
    Atlas Fleet
    −5h
  • Mail de relance envoyé
    Lumen Labs
    −6h
  • Session de travail planifiée
    Silesia Steel
    −7h
FAQ

Lire ce cas

Non. Une implémentation de référence du bureau CRM. Les textes nommés ne sortent qu’après validation de chaque phrase par le client.
Non. Paramètres de simulation : huit sièges, objectif 420 k€, tick de 20 minutes. Le but est la mise en page et le comportement de mise à jour.
Une couche d’intégration au-dessus de l’e-mail, de la téléphonie et du grand livre existant, un RBAC au niveau champ, un journal d’audit et un basculement hors tableur.
Oui. Le premier livrable habituel est le modèle de compte et les quatre surfaces visibles ici, câblées sur vos étapes plutôt que sur un défaut éditeur.

Le tableur ne tient plus ?

Décrivez le pipeline, le grand livre auquel il ne parle pas, et où les passages cassent. Sous 24 h, nous le ramenons à un modèle de compte concret.