What you'll need
- Ein SkillCort-Workspace mit der Berechtigung, Fragen und Assessments anzulegen
- Eine schriftliche Zusammenfassung dessen, was Ihre Support-Rolle im Alltag tatsächlich bearbeitet
- Zwei oder drei anonymisierte echte Tickets als Grundlage für die Szenarien
- Eine Verständigung mit der einstellenden Führungskraft darüber, welche Kompetenzen am wichtigsten sind
Step 1: Ordnen Sie der Rolle Kompetenzen zu
Benennen Sie, was Sie messen, bevor Sie den Builder überhaupt öffnen. Für die meisten Support-Rollen sind die tragenden Kompetenzen Tonalität, Genauigkeit, Priorisierung und Deeskalation. Schreiben Sie je Kompetenz einen Satz, der beschreibt, wie starke Leistung in Ihrer Warteschlange aussieht — zum Beispiel: „nimmt den Ärger der Kundin oder des Kunden auf, bevor eine Lösung vorgeschlagen wird, und verspricht nie einen Termin, den wir nicht halten können.“
Diese vier Kompetenzen bilden das Rückgrat des gesamten Assessments: Jede Aufgabe, die Sie bauen, zielt auf eine oder zwei davon, jedes Rubrikkriterium verweist auf eine zurück, und die Abschnittsgewichte spiegeln, wie viel jede für genau diese Rolle bedeutet. Das zuerst auf Papier zu tun, hält das Assessment ehrlich — Sie bauen Aufgaben, um Kompetenzen zu messen, nicht Kompetenzen, um Aufgaben zu rechtfertigen.
- Tonalität: Wärme und Professionalität, passend zur Situation
- Genauigkeit: sagt nur, was zutrifft; keine überzogenen Versprechen
- Priorisierung: bearbeitet eine Warteschlange in einer begründbaren Reihenfolge
- Deeskalation: senkt die Temperatur, ohne alles zu verschenken
Step 2: Bauen Sie die Ticket-Simulation in der Fragenbibliothek
Öffnen Sie die Fragenbibliothek und legen Sie einen Ordner für diese Rolle an — zum Beispiel „Support hiring“ — mit ordnerbezogenen Tags wie „ticket“, „triage“ und „de-escalation“, damit Sie später filtern können. Erstellen Sie die erste Aufgabe manuell: eine Antwortaufgabe mit Rich-Text, die ein realistisches Kundenticket zeigt und die bewerbende Person bittet, die Antwort zu schreiben, die sie tatsächlich senden würde.
Nutzen Sie ein nebeneinanderliegendes Stimulus-Layout, damit das Ticket, der einschlägige Auszug aus der Richtlinie und etwaige Bestelldetails auf der einen Seite stehen, während die bewerbende Person auf der anderen schreibt. Legen Sie dem Ticket einen echten, anonymisierten Fall zugrunde: Eine teilweise berechtigte Beschwerde mit einem fehlenden Detail zwingt dazu, Urteilsvermögen zu zeigen, statt nur eine Vorlage abzurufen.
Step 3: Ergänzen Sie die Aufgaben zur Postfach-Priorisierung und zu schwieriger Kundschaft
Erstellen Sie für die Priorisierung eine Aufgabe, die ein kleines Postfach zeigt — sechs bis acht kurze Tickets unterschiedlicher Dringlichkeit — und die bewerbende Person bittet, sie zu ordnen und die beiden obersten Entscheidungen kurz zu begründen. Für die Reihenfolge eignet sich eine Tabelleneingabe gut, ergänzt um ein kurzes Textfeld für die Begründung. In der Begründung steckt der Nachweis; die Reihenfolge allein lässt sich raten.
Schreiben Sie für die Deeskalation ein Szenario mit einer schwierigen Kundin oder einem schwierigen Kunden: eine wütende Nachricht, die auf Kundenseite einen sachlichen Fehler enthält. Die bewerbende Person muss den Sachverhalt richtigstellen, ohne die Lage anzuheizen. Eine Rich-Text-Antwort erfasst das Geschriebene; wenn in Ihrem Kanal die Stimme zählt, lässt eine Aufgabe mit Audioaufnahme Sie die Tonalität direkt hören.
Step 4: Schreiben Sie für jede Aufgabe eine Rubrik
Hängen Sie jeder Aufgabe eine Rubrik an, bevor jemand antwortet. Für die Ticket-Simulation eignet sich eine stufenbasierte Matrix gut: Kriterien für Tonalität, Genauigkeit und Klarheit, jeweils mit verankerten Verhaltensbeschreibungen — wie eine starke, eine akzeptable und eine schwache Antwort konkret aussieht. Die Anker sind es, die zwei Prüfende zusammenhalten; „guter Ton“ bedeutet ohne sie nichts.
Gewichten Sie die Kriterien nach Bedeutung: Genauigkeit wiegt womöglich schwerer als formale Politur. Beim Anhängen wird die Rubrik als Momentaufnahme eingefroren, sodass spätere Änderungen an der Rubrik nicht stillschweigend verändern, wie laufende Bewerbende bewertet werden. Wenn Bewerbende den Maßstab sehen sollen, an dem sie gemessen werden, markieren Sie die Rubrik als für Bewerbende sichtbar.
Step 5: Stellen Sie im Builder die Abschnitte zusammen und setzen Sie die Gewichte
Legen Sie das Assessment an und strukturieren Sie es in Abschnitte, Seiten und Blöcke. Ein klarer Aufbau für diese Rolle: Abschnitt 1 „Ticket handling“ (die Simulation), Abschnitt 2 „Queue triage“ (die Priorisierungsaufgabe), Abschnitt 3 „De-escalation“ (das Szenario mit schwieriger Kundschaft). Importieren Sie Ihre Fragen über das Auswahlfenster, filtern Sie nach dem zuvor angelegten Ordner und den Tags und wählen Sie mehrere auf einmal aus.
Setzen Sie die Bewertungsgewichte der Abschnitte passend zur Rolle. Wenn Deeskalation das ist, was Ihre besten Mitarbeitenden vom Rest unterscheidet, gewichten Sie diesen Abschnitt entsprechend — die Gewichte fließen direkt in den Role-Fit-Wert ein, den Ihr Decision Board später zeigt. Ergänzen Sie Anweisungen für Bewerbende, die die Erwartungen ehrlich setzen: ein kurzer, realistischer Ausschnitt der Arbeit, kein Trick.
Step 6: Zeitsteuerung setzen, Vorschau prüfen und veröffentlichen
Setzen Sie ein Gesamtzeitlimit im Verhältnis zur Arbeit — ein fokussiertes Support-Assessment braucht selten mehr als 30 bis 40 Minuten. Wenn die Triage-Aufgabe unter leichtem, realistischem Druck erledigt werden soll, ergänzen Sie für diese Seite ein Zeitlimit je Seite; läuft es ab, wird die bewerbende Person weitergeleitet und die Seite gesperrt — sagen Sie das in den Anweisungen klar.
Nutzen Sie „Preview as candidate“ in der Kopfzeile des Builders und durchlaufen Sie das gesamte Assessment selbst. Prüfen Sie, ob die Stimulus-Layouts gut lesbar sind, die Zeitvorgabe fair wirkt und nichts mehrdeutig ist. Die Veröffentlichungs-Checkliste blockiert „Publish“, bis die erforderliche Einrichtung vollständig ist — beheben Sie, was sie markiert, und veröffentlichen Sie dann.
Step 7: Durchführen, bewerten und entscheiden
Legen Sie eine Durchführung mit Namen und Zeitfenster an und halten Sie die Integritätskontrollen im Verhältnis zum Einsatz: Für die meisten Support-Besetzungen reicht das Blockieren von Kopieren/Einfügen völlig aus, und Bewerbende sehen beim Einwilligungsschritt vor dem Start genau, was überwacht wird. Laden Sie Bewerbende per E-Mail ein.
Sobald Antworten eintreffen, bewerten die Prüfenden anhand der gemeinsamen Rubriken. Die KI entwirft Zusammenfassungen und Punktwertvorschläge, wobei Modell und Version protokolliert werden, aber ein namentlich benannter Mensch bestätigt jeden Punktwert — der Vorschlag ist Unterstützung, niemals die Entscheidung. Auf dem Decision Board ordnet der gewichtete Role-Fit die Bewerbenden, und jede Zahl lässt sich bis zum zugrunde liegenden Nachweis aufklappen, sodass das Gespräch über die Shortlist davon handelt, was Bewerbende tatsächlich geschrieben haben, und nicht davon, wer im Interview sympathisch wirkte.
Pro tips
- Legen Sie jedem Szenario ein echtes, anonymisiertes Ticket zugrunde — erfundene Szenarien driften in Richtung Detailwissen und weg von der eigentlichen Arbeit.
- Verlangen Sie bei der Priorisierungsaufgabe eine kurze Begründung; die Reihenfolge allein sagt Ihnen weit weniger als das Warum.
- Lassen Sie die ersten Bewerbenden von zwei Prüfenden unabhängig voneinander bewerten und die Notizen vergleichen, bevor die übrigen bewertet werden — so treten Mehrdeutigkeiten in der Rubrik früh zutage.
- Halten Sie die Gesamtzeit für Bewerbende unter 40 Minuten; ein langes Assessment filtert nach freier Zeit, nicht nach Kompetenz.
- Nehmen Sie ein Ticket auf, bei dem die richtige Antwort lautet, zu eskalieren statt selbst zu lösen — die Grenzen der eigenen Befugnis zu kennen, ist eine Support-Kompetenz.