Support et assistance
Un support qui voit le même grand livre et les mêmes événements que vous, pour qu’une réponse soit lue dans le registre plutôt que devinée — et qui ne peut pas modifier votre solde pour faire disparaître un problème.
Tout client dont un paiement a mal tourné, et tout exploitant qui doit répondre de ce que son équipe de support a fait.
Activé sur ce déploiement.
Le problème
On donne aux équipes de support sous pression des outils pour faire disparaître les problèmes. Un conseiller qui peut ajuster un solde peut être manipulé, peut se tromper, et laisse une plateforme incapable de prouver ce qui s’est réellement passé.
Comment cela fonctionne
- Ouvrez un ticket, ou discutez là où c’est disponible.
- Le conseiller peut voir le paiement, ses tentatives, ses événements et son état.
- La réponse est lue dans le registre plutôt qu’estimée.
- Lorsque de l’argent doit réellement bouger, c’est une écriture sous les contrôles ordinaires — pas une modification.
Ce que vous pouvez vérifier
Des faits sur la plateforme en fonctionnement, pas des adjectifs. Chacun est visible dans le produit, dans la référence de l’API ou dans le grand livre.
- Les conseillers lisent le grand livre et le journal d’événements chaîné par empreinte ; ils ne peuvent pas fixer un solde, parce que les soldes sont déduits des écritures au lieu d’être stockés.
- Une correction est une écriture sous les règles ordinaires d’autorité et de quatre yeux : un correctif est aussi auditable que l’original.
- Chaque paiement porte ses tentatives et ses changements d’état : un conseiller peut dire ce qui s’est passé plutôt que ce qui s’est probablement passé.
- Les actions administratives sont écrites dans la piste d’audit sous le nom propre du conseiller.
Ce que cela coûte
Le support est inclus. Il n’existe pas de file prioritaire payante qui ferait passer un client au paiement cassé derrière un client qui a payé davantage.
Questions
Pourquoi le support ne peut-il pas simplement remettre l’argent ?
Parce qu’un conseiller qui peut fixer un solde peut être convaincu de le fixer par quelqu’un qui n’est pas vous, et parce qu’une plateforme dont les soldes sont modifiables ne peut pas prouver ce qu’elle doit à qui que ce soit. Une vraie correction est une écriture, sous les mêmes contrôles que tout autre mouvement.
Saura-t-il réellement ce qui est arrivé à mon paiement ?
Il peut voir le paiement, chaque tentative, chaque changement d’état et les événements autour. La réponse vient du registre. Lorsque le registre ne le dit vraiment pas, il vous le dira au lieu d’inventer une raison.
Y a-t-il une file plus rapide si je paie ?
Non. Un paiement cassé est plus urgent qu’un gros compte, et une file prioritaire qui inverse ces deux-là vend la mauvaise chose.
À lire ensuite
Le grand livre
Un grand livre en partie double où les soldes sont déduits des écritures au lieu d’être stockés, où les corrections sont des écritures en sens inverse et non des modifications, et où les invariants sont appliqués à l’écriture au lieu d’être vérifiés par une tâche nocturne.
Remboursements et litiges
Un remboursement qui réserve l’argent de façon atomique avant d’être promis, et un litige qui est un objet avec un calendrier plutôt qu’un fil d’e-mails que quelqu’un est censé se rappeler.
Risque et conformité
Un filtrage des sanctions qui tourne à l’intérieur de l’écriture, avant que l’argent ne bouge, pour qu’un paiement bloqué soit refusé plutôt que rappelé — et chaque alerte devient un dossier avec une décision et un nom en face.