Support mit SLAs, die gemessen statt versprochen werden.
Tickets sind die Eingangstür. Anfragen und Aufgaben landen in einem Backlog, werden mit laufender SLA-Uhr in Sprints eingeplant, und jedes Ticket lässt sich an den Agenten übergeben.
So funktioniert es
Von der Anfrage zum gelösten Ticket.
Anlegen
Von Hand, aus einem gemeinsamen Postfach oder aus einem Signal in der Monitoring-Inbox. Typ, Priorität und Support-Level werden direkt beim Eingang gesetzt.
Zuordnen
Das Ticket gehört zu einem Team, das Team zu einer Abteilung, und es gilt die SLA-Richtlinie der Abteilung. Die automatische Zuweisung bestimmt den Bearbeiter.
Planen
Ziehen Sie es in einen Sprint. Die SLA-Uhr startet, und eigene Status können sie anhalten, während Sie auf jemand anderen warten.
Bearbeiten
Kommentare in Threads, Anhänge und Beobachter. Geben Sie ein Startdatum an, und der Agent schreibt einen Plan, den Sie genehmigen.
Lösen
Der Pull-Request des Agenten kommt mit Testzahlen zurück. Erfasste Stunden fließen ins Arbeitsprotokoll, und der Verlauf hält jede Änderung fest.
Was Sie bekommen
Alles in Tickets.
Typen, Prioritäten, Status
Eine Anfrage oder eine Aufgabe, erfasst als Issue oder Hardware, mit Priorität und Support-Level. Fünf Systemstatus plus eigene, die jeweils die SLA-Uhr anhalten können.
Kommentare in Threads
Rich Text, Anhänge und ein Eröffnungskommentar, dazu Beobachter, die auf dem Laufenden bleiben.
SLA-Richtlinien
Pro Abteilung und Priorität, mit Reaktionszeiten, Geschäftszeiten, automatischer Zuweisung und Eskalationsstufen per E-Mail oder SMS. Die Uhr startet, sobald ein Ticket in einen Sprint eingeplant wird.
Teams und Abteilungen
Tickets gehören zu Teams, Teams zu Abteilungen. So ist klar, wer für die Arbeit verantwortlich ist und welche Richtlinie gilt.
E-Mail-to-Ticket
Ein gemeinsames Postfach über eine Logic App. Antworten werden über die Ticketnummer zugeordnet.
Backlog, Sprints, Board
Ein Backlog als Liste oder nach Sprint gruppiert, ein Board, dessen Spalten Ihre Status sind, und Filter nach Status, Priorität, Typ und Tag.
Aus Signalen
Erstellen Sie ein Ticket aus einem Fehler, einem Sicherheitsbefund oder einer langsamen Seite in der Signals Inbox, verknüpft in beide Richtungen.
For you
Die eigene Seite jeder Person: zugewiesene Tickets, Erwähnungen, SLAs, die Aufmerksamkeit brauchen, Fixes des Agenten, die auf ein Review warten, und Aufgaben aus dem Arbeitsprotokoll.
Verlauf und Zeiterfassung
Jede Änderung wird festgehalten. Geschätzte und tatsächliche Stunden pro Ticket fließen ins Arbeitsprotokoll ein.
An den Agenten übergeben
Geben Sie einem Ticket ein Startdatum, und der Agent schreibt den Plan. Genehmigen Sie ihn, dann baut der Agent in einer Sandbox und öffnet einen Draft-Pull-Request.
Im Detail
Ein genauerer Blick.
SLA-Richtlinien
Reaktionszeiten, die Ihren Geschäftszeiten folgen.
Eine Richtlinie pro Abteilung legt Reaktions- und Lösungszeiten für jede Priorität fest. Die Uhr zählt nur Geschäftszeiten, startet, sobald ein Ticket in einen Sprint eingeplant wird, und pausiert bei Status, die Sie wählen, etwa „Wartet auf Kunde“. Ist ein Ziel gefährdet, laufen die von Ihnen festgelegten Eskalationsstufen per E-Mail oder SMS.
- Ziele pro Abteilung und Priorität
- Geschäftszeiten, damit ein Ticket vom Freitagabend am Montag nicht schon überfällig ist
- Automatische Zuweisung des Bearbeiters
- Eskalationsstufen per E-Mail oder SMS
Der Agent am Ticket
Startdatum setzen. Plan zur Freigabe erhalten.
Jedes Ticket kann an den Agenten übergeben werden. Geben Sie ihm ein Startdatum, und der Agent schreibt einen Plan: was er gefunden hat, welche Dateien er voraussichtlich ändert und welche Tests er hinzufügt. Gebaut wird erst, wenn ein Mensch zustimmt. Dann baut er in einer Sandbox, führt Ihre Tests vorher und nachher aus und öffnet einen Draft-Pull-Request, der mit dem Ticket verknüpft ist.
- Ein schriftlicher Plan vor jeder Zeile Code
- Gebaut in einer isolierten Sandbox
- Ihre Tests laufen vorher und nachher, mit den Zahlen im Pull-Request
- Nur ein Triage-Manager genehmigt und mergt
Verbindet sich mit
Woher Tickets kommen und wohin die Fixes gehen.
Wer es nutzt
Eine Warteschlange, egal wer fragt.
Fragen
FAQ zu Tickets.
Wie wird aus einer E-Mail ein Ticket?
Verbinden Sie ein gemeinsames Postfach. Jede neue E-Mail wird zu einem Ticket, und Antworten werden über die Ticketnummer zugeordnet, sodass die Unterhaltung in einem Ticket bleibt. Kunden, die per E-Mail schreiben, brauchen keinen Seat.
Wann startet die SLA-Uhr?
Sobald ein Ticket in einen Sprint eingeplant wird. Reaktions- und Lösungszeiten stammen aus der SLA-Richtlinie für Abteilung und Priorität des Tickets, zählen nur Geschäftszeiten, und eigene Status wie „Wartet auf Kunde“ können die Uhr anhalten.
Was passiert, wenn ein Ziel gefährdet ist?
Die Eskalationsstufen der Richtlinie greifen: E-Mail oder SMS an die Personen, die Sie benannt haben. Kritische Uptime-Checks im Monitoring folgen derselben Eskalation.
Kann der Agent an jedem Ticket arbeiten?
Ja. Geben Sie dem Ticket ein Startdatum, und der Agent schreibt einen Plan. Gebaut wird erst, wenn ein Mensch ihn genehmigt. Dann baut der Agent in einer Sandbox, führt Ihre Tests vorher und nachher aus und öffnet einen Draft-Pull-Request, den ein Triage-Manager prüft.
Können wir eigene Status und Tickettypen verwenden?
Status ja: Fünf Systemstatus sind enthalten, und Sie fügen eigene hinzu, die jeweils die SLA-Uhr anhalten können. Ein Ticket ist eine Anfrage oder eine Aufgabe, erfasst als Issue oder Hardware, mit Priorität, Support-Level und Tags, die Sie festlegen.
Sieht der Support, was das Engineering sieht?
Ja. Ein Ticket, das aus einem Fehler, einer langsamen Seite oder einem Sicherheitsbefund entsteht, ist in beide Richtungen verknüpft. Diagnose, Pull-Request und Testergebnisse sind so direkt vom Ticket aus sichtbar.
Was kostet Tickets?
Pro Seat: ein Seat für jede Person, die in irgendeinem Projekt Zugriff auf Ticketing hat, einmal gezählt, egal in wie vielen Projekten sie ist. Die Zahlen stehen auf der Preisseite.
Teil eines Workspaces