Das Support-Modell hinter Rexfin: Ehrliche SLAs statt Wunschdenken

Die meisten Support-Seiten von Anbietern lesen sich gleich: 24/7-Abdeckung, formale Uptime-Garantien, eine gestaffelte Eskalationsmatrix, die ein großes Team hinter jedem Ticket suggeriert. Rexfins Support-Seite liest sich bewusst anders. Wir veröffentlichen lieber Zahlen, die wir tatsächlich einhalten können, als Zahlen, die sich in einem Sales-Deck besser anhören.

Jede Zahl ist an der tatsächlichen Verfügbarkeit bemessen

Ein Support-Ticket landet, wo auch immer es eingeht, am Ende bei einem kleinen Team – Triage, Antwort und Eskalation laufen nacheinander ab, nicht über eine rotierende Mannschaft. Die Grundregel hinter jeder SLA-Zahl, die wir veröffentlichen, ist deshalb einfach: nie etwas zusagen, das die operative Realität nicht decken kann.

Das prägt zwei Entscheidungen. Erstens das Werkzeug: Eine schwergewichtige, workflow-automatisierte Helpdesk-Plattform ist Overhead, solange kein Ticketvolumen sie rechtfertigt – Support beginnt deshalb als gemeinsames, beschriftetes Postfach und wechselt erst zu einem richtigen Shared-Inbox-Tool, wenn das Volumen es verlangt. Zweitens die SLA-Stufen. Unsere Pilot-Stufe verzichtet komplett auf Uptime-Formulierungen – Antwort am selben Tag bei gewöhnlichen Anliegen, Best-Effort unter vier Stunden bei abschlussblockierenden Fällen, keine Service-Gutschriften, klar so benannt statt nur angedeutet. Die kostenpflichtige Stufe veröffentlicht ausschließlich Zusagen, hinter die wir heute wirklich stehen können, mit einem expliziten Hinweis dort, wo unser eigenes Mess-Tooling eine bekannte Lücke hat. Fragt man, warum es in der Pilotphase kein formales SLA gibt, lautet die ehrliche Antwort: Wir sagen keine Zahl zu, die wir noch nicht verlässlich messen können.

Der GCC-Kalender, präzise definiert

Die Support-Zeiten folgen der Arbeitswoche und den Feiertagen Ihrer eigenen Jurisdiktion, nicht einer generischen Annahme. Kunden in den VAE und in Saudi-Arabien liegen in unterschiedlichen Zeitzonen, und die Arbeitswoche selbst hat sich in beiden Märkten in den letzten Jahren unterschiedlich verschoben – deshalb bestätigen wir die tatsächliche Wochenform pro Kunde, statt eine fest einzuprogrammieren. Der Ramadan erhält eine benannte, kommunizierte Ausnahme mit reduzierten Zeiten statt einer stillen Verlangsamung, und Feiertage richten sich nach dem tatsächlichen, amtlich veröffentlichten Kalender Ihrer Jurisdiktion statt nach einer festen Datumsliste, die binnen eines Jahres falsch wäre.

Jedes Ticket wird in eine von vier Kategorien einsortiert, bevor eine Antwort rausgeht: ein technisches Problem, das den Dienst betrifft, eine falsche oder verdächtige Zahl in einer Antwort, eine gewöhnliche Wie-geht-das-Frage, oder ein Feature-Wunsch. Diese Sortierung zählt mehr, als es zunächst klingt.

Warum „eine falsche Zahl” kein gewöhnliches Support-Ticket ist

Ein Ausfall ist verzeihlich. Jedes SaaS-Produkt hat irgendwann einen, und Kunden akzeptieren das größtenteils. Eine falsche Zahl, die still in das unterschriebene Board-Pack eines Kunden gerutscht ist, ist eine völlig andere Kategorie von Problem, weil sie genau das trifft, wofür Rexfin überhaupt existiert: dass sich jede Zahl bis zu ihrer Quelle zurückverfolgen lässt. Diese Meldung wie ein „die Seite lädt langsam”-Ticket zu behandeln, wäre der schädlichste Fehler, den unser Support-Prozess machen könnte.

Eine Meldung über eine falsche Zahl landet deshalb nie in der gewöhnlichen Incident-Warteschlange. Sie läuft über ein eigenes Datenintegritäts-Protokoll: den Fehler erkennen, vor jeder Aussage klären, ob er auf einen Workspace begrenzt ist oder überall dort wieder auftreten könnte, wo dieselbe Mapping-Regel oder derselbe Connector verwendet wird, den Kunden proaktiv informieren – wo möglich, bevor er es selbst bemerkt –, die Zahl korrigieren und jeden betroffenen Export mit einem sichtbaren Revisionsvermerk neu ausstellen statt still zu überschreiben, und die Ursache in unsere Verifizierungstests zurückspeisen, damit dieselbe Fehlerklasse künftig automatisch abgefangen wird. Stellt sich der Fehler als systemisch heraus, wird jeder betroffene Kunde informiert, auch die, die es noch gar nicht bemerkt haben – „niemand sonst hat sich beschwert” wird nie mit „niemand sonst war betroffen” gleichgesetzt. Siehe wie Verifizierung funktioniert für die Prüfungen, die solche Fehler abfangen, bevor sie ausgeliefert werden, und das Antwort-Audit-Log dafür, wie jede zitierte Zahl eine Spur zu ihrer Quelle behält.

Auch hier sind wir ehrlich über die aktuelle Lücke: zu bestätigen, welche anderen Kunden dieselbe betroffene Mapping-Regel oder denselben Connector teilen könnten, ist heute noch eine manuelle Prüfung, keine automatisierte Abfrage – unser Offenlegungsziel bündelt also zwei unterschiedliche Aufgaben in einer Zahl. Das sagen wir Ihnen lieber, als ein Tooling anzudeuten, das es noch nicht gibt.

Was das bedeutet, wenn Sie uns evaluieren

Wenn Sie von Tag eins an eine formale 24/7-Support-Zusage mit vertraglichen Uptime-Gutschriften brauchen, sind wir dieser Anbieter noch nicht, und wir tun nicht so als ob. Was wir bieten, ist ein Support-Modell, bei dem die veröffentlichten Antwortzeiten die sind, die wir tatsächlich einhalten, und ein klarer, eigener Pfad für den einen Fehlerfall, der Ihr Vertrauen in unsere Zahlen wirklich beschädigen würde. Für die Verifizierungs- und Herkunftsschicht, die jede zitierte Zahl durchläuft, siehe Überblick über die Sicherheitsarchitektur und den umfassenderen Pillar Inside the Rexfin Platform.

Wenn eine falsche Zahl teuer genug ist, um ein ganzes Protokoll darum zu bauen, lohnt es sich, jeden Anbieter – auch uns – genau zu fragen, was an dem Tag passiert, an dem eine durchrutscht.