Customer Success verbessert die Bindung, indem jede Anbindung läuft
Meldet ein Kunde, dass in seinem Buchhaltungssystem nichts mehr ankommt, ist das Teure die Suche nach System, Aufruf und Zeitpunkt. Maesn hält das in einem Datensatz fest, mit denselben Feldern, welches System auch geantwortet hat.
- targetSystemdas System des Kunden
- unifiedApiden Aufruf, der lief
- timestampden Zeitpunkt, zu dem er lief
- meta.warningsdas Feld, das übergangen wurde
Das Ticket ist billig, die Diagnose ist es nicht
Ein Kunde meldet ein Symptom. Alles Teure passiert zwischen dieser Meldung und dem Wissen, was schiefging.
Ohne eine Schicht dazwischen heißt eine einzige Meldung zu beantworten: wissen, welches der angebundenen Systeme dieser Kunde nutzt, wo dieses System seine Fehler ablegt und wie sein eigenes Vokabular diesen Fehler nennt. Die Arbeit fällt je System an und landet bei der Person, die den Kunden am Telefon hat, und das ist selten die Person, die die Anbindung geschrieben hat.
Der zweite Preis ist die Form der Antwort. Kann der Support eine Ratenbegrenzung nicht von einem abgelaufenen Zugang unterscheiden, wird jede Meldung zu einer Frage an die Entwicklung, und jeder Kunde hört dasselbe: jemand schaut es sich an.
Vier dokumentierte Felder, und jedes Mal dieselben vier
Der Datensatz beantwortet wer, was, wann und was übergangen wurde, welches System auch hinter dem Aufruf stand.
- Welches System?context.targetSystem
Das System des Kunden, am Datensatz benannt und nicht aus der Verbindung erschlossen.
- Welcher Aufruf?context.unifiedApi
Der vereinheitlichte Endpunkt, der lief, damit die Meldung auf etwas zeigt, das sich nachstellen lässt.
- Wann?context.timestamp
Ein Zeitpunkt, über Systeme hinweg vergleichbar, damit ein gescheiterter Abgleich zuzuordnen ist und nicht ungefähr bleibt.
- Etwas übergangen?meta.warnings
Ein Feld, das das Zielsystem stillschweigend verworfen hat, sichtbar gemacht statt Wochen später in einer Auswertung entdeckt.
- Unified Logging & Monitoring
Je Kunde eine andere Hersteller-Konsole zu öffnen, um herauszufinden, was passiert ist.
- Unified Error Handling
Ein Fehlervokabular je System, und ein Handbuch, das mit jeder Anbindung wächst.
- Unified Webhooks
Vom Kunden zu erfahren, dass sich auf seiner Seite etwas geändert hat.
- Asynchronous Processing
Den Monatsabschluss, der als Ticketwelle ankommt statt als Warteschlange.
Drei Ergebnisse statt einer Taxonomie je Hersteller, und eines davon braucht den Kunden
Ein Support-Prozess muss nicht wissen, welcher von sechs Statuscodes es war, sondern welche von drei Handlungen folgt. Weil der Rahmen, die Kategorien und die Wiederholungsregel zu Maesn gehören und nicht zu jedem einzelnen Hersteller, ist diese Liste drei Punkte lang und bleibt drei Punkte lang, wenn Systeme dazukommen.
Ratenbegrenzung, ein interner Fehler oder das Zielsystem ist nicht erreichbar. Wird auf unserer Seite mit Wartezeit wiederholt, und die Antwort an den Kunden lautet, dass es bereits läuft.
Die Zugangsdaten gelten nicht mehr, was vorkommt, wenn ein Kunde seinen Zugang ändert oder den Zugriff entzieht. Der einzige Fall in dieser Liste, in dem der Kunde etwas tun muss.
Die Nutzlast hat die Prüfung nicht bestanden oder der Datensatz existiert bereits. Das ist eine Fehlermeldung mit den fehlgeschlagenen Feldern im Klartext und kein Rätsel zum Nachstellen.
Drei Ergebnisse statt einer Taxonomie je Hersteller, und nur das mittlere braucht den Kunden. Die dokumentierte Wiederholungsanleitung dahinter steht Code für Code auf der Seite zum Fehler-Handling.
Eine Inkasso-Plattform darüber, was geschah, als Kunden ihre eigenen Werkzeuge anbinden konnten
“Seit der Anbindung an Maesn haben wir die Nutzung unserer Plattform deutlich gesteigert und unterstützen in einem Zug eine große Bandbreite an Buchhaltungssystemen. Unsere Kunden können ihre vorhandenen Werkzeuge sofort verbinden, das erhöht die Nutzung und macht Maesn zu einem wesentlichen Teil unserer Erfolgsstrategie.”
Wir machen den Fehler lesbar, das Gespräch bleibt Ihres
Eine Schicht, die Ihre Kundenbeziehung zu steuern behauptet, würde zu weit greifen und wäre leicht zu widerlegen.
- System, Aufruf und Zeitpunkt, am Datensatz selbst
- Ein Fehlervokabular und eine Wiederholungsregel über alle Systeme
- Eine Warnung, wo ein Zielsystem ein Feld stillschweigend übergangen hat
- Wiederholungen für die Fehler, die unsere sind, bevor jemand davon erfährt
- Was dem Kunden gesagt wird und wann
- Ob eine neue Verbindung einen Anruf oder eine E-Mail wert ist
- Welche Anbindungen ein Kunde überhaupt nutzen sollte
- Die Verlängerung, die sich keine Integrationsschicht zuschreiben kann
Der Ablauf, nach dem ein Support-Team meist gefragt wird, ist Zahlungsabgleich, denn dort fällt einem Kunden eine Lücke zuerst auf. Welche Systeme ein Kunde überhaupt anbinden kann, steht im Integrationsverzeichnis, und was unterwegs gespeichert wird, also die Frage, die das Sicherheitsteam des Kunden stellen wird, steht auf der Sicherheitsseite.
Häufige Fragen
Ein Kunde meldet, der Abgleich steht. Wo beginnt der Support?
Kann der Support erkennen, ob es unser Problem ist oder das des Zielsystems?
Worum muss der Support den Kunden bitten?
Erfahren wir von einem Problem, bevor der Kunde es tut?
Taucht ein Feld, das das Zielsystem übergeht, irgendwo auf?
Was passiert zum Monatsende, wenn alles gleichzeitig läuft?
Senkt das die Abwanderung?
Lassen sich Anbindungen je Kunde nach dem Livegang aktivieren?
Einmal bauen, auf der Unified API.
Sehen Sie, wie ein Fehler, der sich mit einem Blick zuordnen lässt für Ihre Integration funktioniert, oder steigen Sie in die technische Referenz ein.