Kundenanfrage → gelieferter Code

Von der Kundenanfrage zum gelieferten Code — in einem Werkzeug

Ein Kunde meldet ein Problem. Daraus wird eine Aufgabe, ein Entwickler behebt es in der IDE, der Commit ist mit der Aufgabe verknüpft, die Arbeit durchläuft Review und Test — und wenn sie den letzten Schritt erreicht, erfährt der Kunde, dass es erledigt ist. Vi verbindet jedes Glied dieser Kette, sodass nichts von Hand kopiert wird und niemand daran denken muss, ein Update zu senden.

Kostenlos starten Die ganze Kette ansehen

Wo geht eine Kundenanfrage normalerweise verloren?

Eine Kundenanfrage geht meist an den Übergaben zwischen Werkzeugen verloren: Der Support erfasst sie in einem Helpdesk, jemand kopiert sie in den Issue-Tracker, ein Entwickler behebt sie in Git, und der Kunde hört nur dann etwas, wenn sich jemand erinnert, zum ersten Werkzeug zurückzukehren. Jede Übergabe verliert Kontext — welcher Kunde gefragt hat, was genau er wollte, welcher Commit es behoben hat —, und der Kunde schreibt immer wieder „Gibt's was Neues?“, weil sich aus seiner Sicht nichts bewegt hat. Die Lösung ist kein besserer Helpdesk und kein besserer Tracker, sondern ein einziger Datensatz, der von der Anfrage des Kunden bis zum Code wandert.

Die Kette, Glied für Glied

Jeder Schritt wird von einer anderen Person erledigt, und jede gibt denselben Datensatz an die nächste weiter — kein Kopieren, kein zweites System.

1
Kunde
Schreibt eine E-Mail an die Vi-Adresse Ihrer Organisation oder füllt ein Formular im Kundenportal aus und erhält sofort eine Referenznummer und einen Link zu einer Statusseite. Im Business-Plan kommt ein Issue in einem verbundenen GitHub-Repository auf dieselbe Weise an; dort erscheinen die Antworten des Teams und das Ergebnis direkt im Issue.
2
Teamleiter
Prüft die Anfrage im Triage-Posteingang und wandelt sie in echte Arbeit um, in den eigenen Worten des Teams: eine Aufgabe oder — wenn sie mehrere Probleme beschreibt — ein Epic mit den nötigen Aufgaben, bis zu 20. Die ursprüngliche Nachricht des Kunden bleibt in der Unterhaltung der Anfrage, statt in eine Aufgabe kopiert zu werden.
3
Workflow
Die Aufgabe betritt Ihren Workflow, wird automatisch der am wenigsten ausgelasteten Person mit der passenden Rolle zugewiesen und startet ihre SLA-Uhr — genau wie jede andere Arbeit, die Ihr Team ausliefert.
4
Entwickler
Wählt die Aufgabe in VS Code, Visual Studio, RAD Studio oder Lazarus und klickt auf Start. Ist die Arbeit fertig, klickt er auf Erledigt: Vi committet die Änderung mit einer Nachricht wie „[#123] Aufgabentitel“, pusht sie, wenn das Repository ein Git-Remote hat, und markiert seinen Schritt als abgeschlossen. Die Aufgabe geht weiter — sie ist noch nicht geschlossen.
5
Reviewer / QA
Prüft, testet oder gibt in den nächsten Schritten Ihres Workflows frei — so viele, wie Ihr Prozess braucht. Eine Ablehnung schickt die Aufgabe mit Begründung zurück; eine Freigabe bringt sie weiter.
6
Workflow
Wenn die Aufgabe — oder bei einer aufgeteilten Anfrage jede Aufgabe in ihrem Epic — den letzten Schritt des Workflows erreicht, gilt die Anfrage als erledigt. Ein Entwickler, der seinen eigenen Schritt abschließt, schließt die Anfrage des Kunden nie von allein.
7
Kunde
Erhält eine E-Mail, dass die Anfrage gelöst ist, und die Statusseite zeigt sie als erledigt. Separat folgt eine Zufriedenheitsumfrage mit einem Klick. Schreibt er danach erneut, geht die Nachricht in den Triage-Posteingang, und Ihr Team entscheidet, ob die Arbeit wiedereröffnet oder etwas Neues begonnen wird.

Zwei Sichten auf denselben Datensatz

Ihr Kunde und Ihr Team sehen dieselbe Anfrage, aber jeder nur das, was für ihn nützlich ist.

Was Ihr Kunde sieht

Eine Referenznummer, einen von vier einfachen Zuständen — eingegangen, in Bearbeitung, gelöst, geschlossen —, einen Fortschrittswert und bei einer aufgeteilten Anfrage, wie viele Teile erledigt sind („2 von 3“). Im Kundenpanel: die Antworten, die Ihr Team ihm schicken wollte, sowie seine eigenen Nachrichten und Anhänge. Keine Namen von Mitarbeitern, keine internen Workflow-Schritte, keine interne Diskussion.

Was Ihr Team sieht

Die vollständige Aufgabe: Workflow-Schritt, Bearbeiter, SLA, interne Kommentare, Freigaben, aufgewendete Zeit — und im Abschnitt „Ausgeliefert“ der Aufgabe jeden dafür erstellten Commit mit Hash, Branch und Zeilenzahlen. Eine Kundenanfrage-Karte an der Aufgabe (und bei einer Anfrage mit mehreren Aufgaben am Epic) zeigt die Referenznummer, genau das, was der Kunde gerade sieht, das Zufriedenheitsergebnis und die Unterhaltung mit dem Kunden, in der das Team antwortet.

Wie ist die Kundenanfrage mit dem Code verknüpft?

Die Kundenanfrage ist über ihre Aufgabe mit dem Code verknüpft: Commit & Close schreibt die Aufgabennummer als [#123] in die Commit-Nachricht und meldet die Metadaten des Commits an diese Aufgabe zurück, sodass Anfrage, Aufgabe und Commits eine nachvollziehbare Linie bilden. Nur Metadaten verlassen den Rechner des Entwicklers — Hash, Nachricht, Branch und Zeilenzahlen sowie Dateinamen, wenn Ihre Organisation das einschaltet. Quellcode nie.

Was, wenn eine Anfrage eigentlich mehrere Arbeitspakete ist?

Ist eine Anfrage eigentlich mehrere Arbeitspakete, wandeln Sie sie in ein Epic um und listen die nötigen Aufgaben auf, oder teilen Sie eine bestehende Aufgabe später in bis zu 20 separate Aufgaben. Jede Aufgabe wird wie gewohnt über Ihren Workflow zugewiesen, und es wird keine Platzhalteraufgabe nur für die Unterhaltung erstellt — die Unterhaltung gehört zur Anfrage. Der Kunde sieht weiterhin eine einzige Anfrage, mit dem Fortschritt als erledigte Teile von der Gesamtzahl; sie gilt erst als gelöst, wenn jeder Teil erledigt ist.

Für wen das gedacht ist — und für wen nicht

Passt gut

Softwareteams, die ein Produkt bauen und dessen Kunden selbst betreuen — Agenturen, Produktstudios und interne Teams, in denen der Entwickler, der einen Bug behebt, nur wenige Schritte vom Kunden entfernt ist, der ihn gemeldet hat. Wenn Ihre Supportanfragen regelmäßig zu Codeänderungen werden, nimmt Ihnen diese Kette den Großteil der manuellen Arbeit drumherum ab.

Passt weniger gut

Eine große, eigenständige Supportabteilung, die die meisten Tickets ohne Entwicklung löst oder Telefon und Live-Chat, Hilfecenter für mehrere Marken oder Makros für Tausende Tickets pro Tag braucht — eine spezialisierte Helpdesk-Suite ist dafür besser geeignet. Vi deployt Ihren Code auch nicht: Die Kette endet bei Commit, Push und dem letzten Schritt Ihres Workflows.

Welchen Plan brauchen Sie?

Commit & Close und die IDE-Erweiterungen sind in jedem Plan verfügbar, auch in Free. Die Kundenseite der Kette — E-Mail-zu-Aufgabe mit Ticket-E-Mails in beide Richtungen, der Triage-Posteingang, das Kundenportal, Statusseiten, das Kundenpanel und die automatischen E-Mails — ist Teil des Business-Plans. Kundenkonten belegen nie einen Platz, und E-Mail funktioniert über die Vi-Adresse Ihrer Organisation ohne externen Helpdesk oder Maildienst.

Häufige Fragen

Benachrichtigt das Erledigt eines Entwicklers den Kunden?

Nein — das Erledigt eines Entwicklers schließt seinen eigenen Workflow-Schritt ab und bringt die Aufgabe zum nächsten; der Kunde wird erst benachrichtigt, wenn die Aufgabe den letzten Schritt des Workflows erreicht. So hört der Kunde „gelöst“ nach Review und Test, nicht schon beim ersten Commit.

Kann der Kunde Commits oder Code sehen?

Nein — der Kunde sieht nur Status und Fortschritt der Anfrage sowie die Antworten, die Ihr Team ihm schickt. Commits erscheinen für Ihr Team in der Aufgabe, und selbst dort speichert Vi nur Commit-Metadaten, nie Quellcode.

Welche IDEs unterstützen Commit & Close?

Commit & Close ist heute für VS Code, Visual Studio, RAD Studio 13 und Lazarus verfügbar. In jeder davon startet ein Entwickler die Aufgabe, klickt auf Erledigt, wenn sein Teil fertig ist, und Vi committet mit der Aufgabennummer, pusht bei konfiguriertem Git-Remote und verschiebt die Aufgabe in den nächsten Workflow-Schritt.

Wird jede E-Mail automatisch zur Aufgabe?

Nein — jede E-Mail wartet im Triage-Posteingang, auch von jemandem, der bereits ein Konto in Ihrer Organisation hat, bis ein Admin sie in eine Aufgabe oder ein Epic umwandelt oder ablehnt. Der Admin formuliert die Aufgabe in den Worten des Teams; die ursprüngliche E-Mail bleibt in der Unterhaltung der Anfrage.

Was erhält der Kunde, und braucht er ein Konto?

Der Kunde erhält eine Referenznummer, eine Statusseite, die sich ohne Anmeldung öffnet, und E-Mails, wenn die Anfrage eingegangen, gelöst oder geschlossen ist — kein Konto und kein bezahlter Platz nötig. Möchte er alle seine Anfragen sehen, antworten oder Dateien anhängen, meldet er sich mit einem einmaligen Link per E-Mail im Kundenpanel an.

Wie unterscheidet sich das von der Helpdesk-Seite von Vi?

Die Helpdesk-Seite beschreibt die Support-Werkzeuge selbst — Posteingang, Triage, CSAT und Textbausteine —, während diese Seite eine Anfrage von Anfang bis Ende verfolgt, durch die IDE des Entwicklers und Ihre Prüfschritte zurück zum Kunden. Beide beschreiben dasselbe Produkt: Eine Supportanfrage in Vi ist eine Aufgabe.

Deployt Vi die Korrektur in die Produktion?

Nein — Vi endet bei Commit, Push und dem letzten Schritt Ihres Workflows; das Deployment bleibt bei Ihrer bestehenden CI/CD. Wenn das Ausrollen Teil Ihres Prozesses ist, fügen Sie einen Schritt wie „Ausgerollt“ als letzten Schritt des Workflows hinzu, damit der Kunde erst benachrichtigt wird, wenn die Korrektur live ist.

Weiterlesen: Helpdesk und E-Mail-zu-Aufgabe · so funktioniert Commit & Close · Sicherheit des Quellcodes · ein fokussiertes Pilotprojekt starten · Pläne und Preise

Close the Loop mit Ihrem Kunden — von der Anfrage zum Code und zurück

In zwei Minuten kostenlos starten. Keine Kreditkarte erforderlich.

Kostenlos starten