Kurzfassung
Support-Abdeckungsplanung besteht aus drei Entscheidungen: Zu welchen Zeiten und auf welchen Kanälen Sie antworten, wie viele Agenten jede Stunde braucht und was mit Tickets passiert, die eintreffen, wenn niemand da ist. Die meisten Teams starten bei der Uhr („Sollen wir Wochenenden machen?"). Ich würde beim Kanal anfangen, denn ein Chat-Kunde wartet Sekunden und ein E-Mail-Kunde Stunden, und dieser eine Unterschied bestimmt den Großteil Ihres Dienstplans.
Rechnen Sie, bevor Sie einstellen. Ziehen Sie die Heatmap der Tickets pro Stunde aus Ihrem Helpdesk, multiplizieren Sie das Volumen mit der Bearbeitungszeit und addieren Sie dann 15-35 % Shrinkage, die Spanne, die Zendesks eigene Workforce-Management-Dokumentation als Branchenstandard bezeichnet. Ein rund um die Uhr besetzter Platz kostet etwa 6 Personen, weshalb fast kein kleines Team Nächte mit Menschen besetzen sollte.
Für die Zeiten, die Sie nicht besetzen können, beantwortet ein KI-Helpdesk-Teammate wie eesel die Routine-Tickets in Ihrem bestehenden Helpdesk und lässt die schwierigen für den Morgen markiert liegen. Menschen behalten Live-Chat, Telefon und Ausfälle; die KI übernimmt das „Wo ist meine Bestellung?" um 2 Uhr nachts.
Was ist Support-Abdeckungsplanung?
Support-Abdeckungsplanung bedeutet, die Zeiten Ihres Teams mit dem Moment abzugleichen, in dem Kunden Sie wirklich brauchen. Sie beantwortet drei Fragen:
- Zu welchen Zeiten und an welchen Tagen antworten wir, pro Kanal? E-Mail, Chat, Telefon und Social Media brauchen nicht dieselben Zeiten.
- Wie viele Agenten brauchen wir in jeder Stunde, in der wir geöffnet haben? Nicht pro Tag, sondern pro Stunde, weil das Volumen nicht gleichmäßig ist.
- Was passiert außerhalb dieser Zeiten? Eine automatische Antwort, eine Person in Bereitschaft, ein Partner oder ein KI-Agent.
Ich gehöre zum Support-Team von eesel und lebe jeden Tag mit den Folgen dieses Plans. Und weil eesel seit Jahren KI auf Live-Support-Warteschlangen einsetzt, habe ich bei vielen Teams dasselbe Muster gesehen: Der Abdeckungsplan wurde einmal nach Bauchgefühl entschieden, als das Team drei Leute hatte, und niemand hat ihn überprüft, als sich das Volumen verdreifachte.
Außerdem wird er mit Nachbarthemen verwechselt. Die Abdeckungsplanung legt fest, wann Sie geöffnet haben. Ihre SLA-Richtlinien legen fest, wie schnell Sie innerhalb dieser Zeiten Antwort versprechen. Eine Schichtübergabe ist das, was an den Nahtstellen passiert. Wenn die Abdeckung falsch ist, können die anderen beiden das nicht retten.
Schritt 1: Herausfinden, wann Kunden wirklich schreiben
Beginnen Sie mit Daten, nicht mit Annahmen. Jeder große Helpdesk hat inzwischen einen Bericht, der das Ticketvolumen nach Stunde und Tag zeigt, und er ist in etwa zehn Minuten gelesen.
| Helpdesk | Zu öffnender Bericht | Was er zeigt | Tarif |
|---|---|---|---|
| Gorgias | Busiest times | Heatmap nach Stunde und Tag mit markierten Geschäftszeiten; erstellte, beantwortete, geschlossene Tickets | Alle Helpdesk-Tarife |
| Front | Workload-Bericht, Busiest times | Heatmap neuer Konversationen, Nachrichten und aktiver Teammitglieder; standardmäßig 9 bis 17 Uhr, erweiterbar auf 24 Stunden | Alle aktuellen Tarife |
| Help Scout | All-Channels-Bericht | Heatmap „Busiest time of day" plus die Kennzahl Busiest Day | In der Dokumentation nicht angegeben |
| Freshdesk | Ticket volume trends (Load Analysis) | Erstellte, gelöste, wieder geöffnete und ungelöste Tickets pro Stunde | Für diesen Bericht nicht angegeben |
| Zendesk | Explore-Rezept, Tickets nach Tageszeit | Eigener Bericht zu „Ticket created - Hour", plus ein Rezept für Stoßzeiten nach Kanal | Suite Professional und höher oder Explore Professional |
In der Heatmap sollten Sie auf zwei Dinge achten. Erstens das Offensichtliche: wo die dunklen Felder liegen. Zweitens, und nützlicher, die dunklen Felder außerhalb Ihrer aktuellen Zeiten. Die Gorgias-Dokumentation formuliert es besser, als ich es kann: „A dark cell outside your business hours is demand arriving when nobody is scheduled."
Schauen Sie dann auf erstellte gegenüber gelösten Tickets pro Stunde, denn in den Stunden, in denen die erstellten überwiegen, beginnt ein Ticket-Rückstau. Freshdesks Load Analysis ist genau dafür gebaut, und laut Dokumentation gilt: Wenn erstellte Tickets in einem Zeitraum die gelösten übersteigen, „you should add more agents during this time period."
Nutzen Sie Monate an Historie, nicht Tage (Zendesks Prognose startet mit sechs Monaten Tickets), und nehmen Sie bekannte Spitzen aus der Basis heraus. Eine Blumenlieferdienst-Marke, die eesel mit ihren früheren Tickets trainiert hat, bat eesel aus demselben Grund, ihre Spitzen an Valentinstag und Muttertag auszuschließen: Spitzenwochen verzerren, wie ein normaler Dienstag aussieht. Planen Sie zuerst die Basis, dann die Spitzen getrennt (Schritt 6).
Schritt 2: Abdeckung pro Kanal festlegen, nicht pro Uhrzeit
Das ist die Umdeutung, für die ich am stärksten werbe. „Haben wir samstags offen?" ist die falsche Frage. Die richtige lautet: Wie lange wartet ein Kunde auf diesem Kanal, bevor die Verzögerung uns etwas kostet?
| Kanal | Wie lange Kunden warten | Was Abdeckung bedeutet |
|---|---|---|
| Telefon | Sekunden | Eine Person in der Leitung, oder die Leitung ist geschlossen |
| Live-Chat | Ein bis zwei Minuten | Eine Person online, oder der Chat schaltet auf „Nachricht hinterlassen" um |
| E-Mail und Web-Formulare | Stunden | Jemand antwortet innerhalb Ihres genannten Fensters, das auch erst am nächsten Morgen beginnen kann |
| Social-DMs | Stunden, aber öffentlich | Wie E-Mail, mit genauerer Beobachtung bei Beschwerden |
| Ausfälle und Sicherheitsprobleme | Minuten, egal welcher Kanal | Eine Person in Bereitschaft, auch wenn alles andere geschlossen ist |
Zendesks eigene Prognose-Engine behandelt Kanäle so. Ihre Prognose-Dokumentation sagt, dass E-Mail-Volumen außerhalb der besetzten Zeiten „over the period of First Response Time" verteilt wird, während Sprach- und Chat-Volumen außerhalb der Zeiten gar nicht vorgetragen wird. Einfach gesagt: Eine E-Mail um 23 Uhr ist die Arbeit von morgen, ein verpasster Anruf ist weg.
Das ergibt einen sinnvollen Standard für die meisten Teams:
- Live-Kanäle laufen nur in den Zeiten, die Sie ordentlich besetzen können. Außerhalb davon schaltet der Chat auf E-Mail-Erfassung um. Help Scout, Front und Zendesk unterstützen das, und mein Leitfaden zu Zendesk Offline-Messaging behandelt eine Einrichtung.
- E-Mail bekommt ein Antwortversprechen („innerhalb von 4 Geschäftsstunden") statt Personal rund um die Uhr, das ist der Kern von asynchronem Support, und Ihre SLA-Timer folgen demselben Zeitplan.
- Ausfälle bekommen eine benannte Person in Bereitschaft, jeden Tag, mit einer kurzen Alarmliste.
Ein Hacker-News-Kommentator brachte die Käuferseite dieses Punkts auf den Punkt: Für SaaS gelte „I'd be fine with business hour support. SaaS failures don't directly cost me money and/or reputation." Ihre Kunden könnten anders sein. Ein Zahlungsprodukt oder ein Krankenhaussystem kann diesen Tausch nicht eingehen. Seien Sie ehrlich, welcher Fall bei Ihnen vorliegt.
Schritt 3: Berechnen, wie viele Agenten Sie pro Stunde brauchen
Jetzt die Rechnung. Die einfache Version ist ein Arbeitslastmodell:
Einzuplanende Agenten = (Tickets in dieser Stunde × Minuten pro Ticket ÷ 60) ÷ Auslastung ÷ (1 − Shrinkage)
Minuten pro Ticket ist Ihre durchschnittliche Bearbeitungszeit. Zwei der anderen Begriffe brauchen eine Definition, und das WFM-Glossar von Zendesk hat saubere:
- Auslastung ist die Zeit, die Agenten mit Arbeit verbringen, geteilt durch ihre gesamte Arbeitszeit. Niemand hält 100 % durch; Zendesks eigenes Rechenbeispiel deckelt sie bei 90 %.
- Shrinkage umfasst „lunch breaks, training sessions, scheduled meetings" sowie „absenteeism, holiday, vacation, sick days, lateness, and leaving early." Zendesk nennt als Branchenstandard 15-35 %.
Setzen Sie hier Ihre eigenen Zahlen ein. Der Rechner gibt Ihnen die einzuplanenden Agenten in Ihrer Spitzenstunde und die Vollzeit-Mitarbeiterzahl für eine Woche mit Ihren Öffnungszeiten.
Das Arbeitslastmodell ist für Live-Kanäle eine Untergrenze, nicht die Antwort. Chat- und Telefonkunden stehen in der Warteschlange, und die Formel, mit der Workforce-Tools diese Warteschlange bemessen, heißt Erlang C; sie fügt Agenten hinzu, damit ein bestimmter Anteil der Kontakte innerhalb einer Zielzeit beantwortet wird. Zendesk WFM berechnet den benötigten Personalbedarf pro 15-Minuten-Intervall „based on a modified version of Erlang C."
Erlang C hat bei niedrigem Volumen eine bekannte Eigenheit. Zendesks Best-Practices-Dokument warnt, dass „for low-volume workstreams, the industry-standard Erlang C formula may result in slightly higher staffing recommendations." Das eigene Rechenbeispiel zeigt, wie viel: 38 E-Mails pro Tag zu je 210 Sekunden sind etwa 2,2 Stunden Bearbeitung, doch das Modell landet bei „1.5 agents per day", also 12 Stunden besetzter Zeit. Diese Lücke ist der Preis dafür, auf einer ruhigen Warteschlange eine schnelle Antwort zu garantieren, und sie ist das stärkste Argument dafür, ruhige Stunden gar nicht mit Menschen zu besetzen.
Was ein 24/7-Platz wirklich kostet
Das ist die Zahl, die die meisten Debatten „Sollen wir auf 24/7 gehen?" beendet.
Eine Woche hat 168 Stunden. Zendesks Glossar zählt eine Vollzeitstelle als 40 Stunden pro Woche. Das sind 4,2 Personen, um einen einzigen Stuhl besetzt zu halten, bevor irgendjemand Urlaub nimmt. Mit 30 % Shrinkage sind es 6 Personen für einen Platz. Wenn Sie nachts zwei Agenten wollen, verdoppeln Sie es.
Ein Hacker-News-Kommentator, der das erlebt hatte, fasste zusammen, was die Tabelle meist auslässt:
"Still need enough staff at each site to handle rotation for covering weekends and for people to go on holiday and get sick or quit for new jobs etc."
Schritt 4: Ein Abdeckungsmodell für die Zeiten wählen, die Sie nicht besetzen können
Sobald Sie Ihre Stoßzeiten und Ihren Personalbestand kennen, wählen Sie, wie Sie den Rest handhaben. Hier sind die sechs Modelle, die ich am häufigsten sehe, mit dem, was jedes kostet.
| Modell | So funktioniert es | Am besten für | Der Haken |
|---|---|---|---|
| Nur Geschäftszeiten | Ein Zeitplan, ein klares Antwortversprechen, automatische Antwort außerhalb der Zeiten | B2B-SaaS, wo eine Verzögerung den Kunden kein Geld kostet | Rückstau am Montagmorgen |
| Gestaffelte Schichten | Gestaffelte Startzeiten (7-15, 9-17, 11-19), um ein Team über 12 Stunden zu strecken | Teams ab 4 Personen in einer Region | Dünne Abdeckung an den Rändern |
| Rufbereitschaft | Eine Person trägt nach Feierabend ein Telefon oder einen Pager für dringende Fälle | Ausfälle, VIP-Konten | Zermürbt Menschen schnell |
| Follow-the-Sun | Teams in 2-3 Regionen decken jeweils ihren Tag ab | Globale Kunden, 15+ Agenten | Übergaben, doppelte Führung |
| Ausgelagert außerhalb der Zeiten | Ein Partner beantwortet Nächte und Wochenenden (Outsourcing-Leitfaden) | Telefonlastiger Endkunden-Support mit hohem Volumen | Wissenstransfer und Qualität |
| KI als erste Linie plus menschliche Zeiten | KI beantwortet Routine-Tickets rund um die Uhr; Menschen übernehmen den Rest, wenn sie da sind | Teams mit großem Routineanteil | Braucht gutes Wissen und klare Grenzen |
Ein paar Anmerkungen von Teams, die das durchlebt haben.
Rufbereitschaft ist günstiger als Schichten und teurer, als sie aussieht. Bereitschaft schränkt Ihr Leben auch in ruhigen Wochen ein:
"We were a small team so rotation was weekly and you would be on support every 4 weeks or so. I couldn't go to the gym after work without worrying about a call coming in and ruined weekends for me."
Halten Sie Rotationen für echte Notfälle bereit, mit einer kurzen schriftlichen Definition, was als solcher zählt, und einem klaren Eskalationsprozess dahinter.
Feste Einstellungen kommen vor 24/7, und es gibt dafür einen groben Auslöser. Die Faustregel eines Gründers: Wenn das Team 20 Stunden oder mehr pro Woche für Support aufwendet, „hire a dedicated support person or agency, even if they're part time", und dann „schedule dedicated hours for each person to be on call." Das ist die Frage nach der Support-Team-Struktur in einem Satz.
Einstellungen für den Tag lösen die Nächte nicht. Ein anderer Kommentator, dessen 10-köpfiges Team schnell wuchs, beschrieb, wie er feste Support-Leute einstellte und trotzdem feststellte, dass „after hours were an issue." Wenn Ihre Lücke nachts liegt, schließen mehr Tageskräfte sie nicht.
Hier kommen Follow-the-Sun-Support, ein Offshore-Team oder eine KI als erste Linie ins Spiel. Die Kosten von Offshore-Teams habe ich separat mit KI verglichen.
Schritt 5: Dienstplan bauen und den Helpdesk einrichten
Ein Plan, der nur in einer Tabelle lebt, driftet innerhalb eines Monats von der Realität weg. Legen Sie ihn in Ihrem Helpdesk ab, damit Timer, Routing und automatische Antworten ihm folgen. Hier steht, was jeder kann und wo die Tarifgrenzen liegen.
| Geschäftszeiten | Mehrere Zeitpläne (Regionen, Kanäle) | Schichten, die den Agentenstatus umschalten | |
|---|---|---|---|
| Zendesk | Ein Zeitplan bei Suite Growth und Professional | Enterprise (Zeitplan-Dokument) | Nicht nativ; braucht das WFM-Add-on |
| Freshdesk | Growth und höher | Pro ($55/Agent/Monat jährlich) | Enterprise ($89), Agent Shifts |
| Help Scout | Plus ($45) und höher, pro Postfach | Pro Postfach, Plus und höher | Nicht verfügbar |
| Gorgias | Basic und höher, pro Integration | Pro Integration | Nicht verfügbar |
| Front | Professional ($65), pro Postfach | Pro Postfach | Enterprise ($105), Shifts |
Die Falle ist der Status. Zendesks Agentenstatus-Dokument sagt „operating hours won't set an agent's status", ein Zeitplan, der „geschlossen" sagt, hält also nicht davon ab, an jemanden zu routen, der vergessen hat, sich offline zu schalten. Beheben Sie das zuerst, denn intelligentes Routing ist nur so gut wie die Status, die es liest.
Meine Leitfäden zu Zendesk-Geschäftszeiten und Feiertagsplänen behandeln die Einrichtung, und Automatisierungen außerhalb der Geschäftszeiten regeln, was mit Tickets passiert, die außerhalb eintreffen.
Bei Gorgias erledigen zeitgesteuerte Autoresponder dieselbe Aufgabe.
Wann Sie Workforce-Management-Software brauchen
Für ein Team von sechs brauchen Sie kein Workforce-Management-Tool (WFM), um die Abdeckung zu planen. Sobald Sie ein paar Dutzend Leute über Schichten und Kanäle hinweg einplanen, schon, denn das Tool macht Intervallprognosen und baut Dienstpläne für Sie.
- Zendesk WFM prognostiziert das Volumen „for up to a year in the future" aus Ihrer Ticket-Historie (es braucht mindestens einen Monat Daten) und zeigt den benötigten Personalbedarf pro 15-Minuten-Intervall. Der öffentliche Preis ist das Workforce Engagement Bundle, WFM plus QA, für
$50pro Agent und Monat bei jährlicher Zahlung auf der Zendesk-Preisseite, und Add-ons werden für jeden Agenten im Konto gekauft. - Assembled führt Workforce Management auf seiner Preisseite mit
$25,$45und$75im Monat für die Tarife Core, Pro und Enterprise auf, ohne anzugeben, ob das pro Agent gilt. Seine WFM-Seite sagt, Personalpläne „account for AI agent capacity alongside human resources", und so sollte man es auch denken.
Schritt 6: Für Spitzen, Feiertage und Abwesenheiten planen
Ihr Basisplan deckt eine normale Woche ab. Drei Dinge sprengen ihn.
Saisonale Spitzen. E-Commerce-Teams kennen ihre: Black Friday, Feiertage, Launch-Wochen. Eine Marke für Nahrungsergänzungsmittel, die zu eesel kam, bearbeitet etwa 7.000 Tickets im Monat mit einer Hochsaison von November bis Mai, und ihr Team kam mit dem Volumen allein nicht hinterher. Planen Sie die Spitzenabdeckung als eigene Schicht: Aushilfen, Überstunden oder ein KI-Agent, der den repetitiven Anteil per Ticket-Deflection übernimmt. Mein Leitfaden zum Black-Friday-Support geht das Vorgehen durch.
Feiertage. Tragen Sie jeden gesetzlichen Feiertag jeder Region, die Sie bedienen, in den Zeitplan Ihres Helpdesks ein, damit SLA-Uhren pausieren und automatische Antworten das Richtige sagen. Prüfen Sie dann den Tag nach jedem, der meist Ihr schlimmster Tag des Monats ist.
Abwesenheit und Fluktuation. Das ist wieder Shrinkage, und hier scheitern Pläne leise. Zwei Leute gleichzeitig weg bei einem Team von sechs senken Ihre Kapazität um ein Drittel. Den Verlust eines erfahrenen Agenten spüren Sie noch stärker, weil sein Wissen mitgeht; ein IT-Dienstleister kam gezielt zu eesel, um das Wissen zweier ausscheidender Senior-Agenten zu sichern, bevor sie gingen. Antworten in Ihre Wissensdatenbank zu schreiben ist ebenfalls Abdeckungsplanung.
Wo KI in einen Abdeckungsplan passt
Hier wird der Plan günstiger. Wenn sechs Leute einen Platz nachts besetzt halten, lautet die Frage für die meisten Teams nicht „Wie besetzen wir die Nächte?", sondern „Wie viel der Nacht braucht überhaupt einen Menschen?" Für die meisten Warteschlangen ist die Antwort weniger, als Sie denken, und das ist der ganze Grund für KI-Support außerhalb der Geschäftszeiten.
Die Form, die funktioniert: Ihr Team deckt die vollen Werktagsstunden ab; ein KI-Agent deckt alles andere als erste Linie ab; eine Person ist für Ausfälle in Bereitschaft; und alles, wobei die KI unsicher ist, wartet markiert und zusammengefasst auf die nächste besetzte Schicht. Die KI füllt die leeren Felder, nicht die vollen.
Anytime Fitness ist das klarste Beispiel, das ich nennen kann. Vor eesel wartete ein Mitglied, das um 22 Uhr eine Frage stellte, bis zum Morgen; jetzt werden die häufigen Fragen zu jeder Stunde in über 5.000 Studios beantwortet. Gridwise sah, wie eesel im ersten Monat 73 % seiner Tier-1-Tickets löste, laut seinem Zitat auf eesels Seite zum KI-Helpdesk-Agenten.
Die Regel, die KI außerhalb der Geschäftszeiten sicher macht, verlangen Käufer in fast jedem Gespräch. Ein CX-Leiter einer Nahrungsergänzungsmarke auf Gorgias, der etwa 7.000 Tickets im Monat bearbeitet, sagte es deutlich:
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
Das ist der Abdeckungsplan im Kleinen: Die KI übernimmt nachts den sicheren Anteil, der Rest landet mit Kontext in der Morgenwarteschlange. Dieselbe Idee steckt hinter 24/7-Support mit KI. Wenn Sie die Mechanik wollen, behandelt mein Leitfaden dazu, wann die KI übergeben sollte, das Thema.
Eine Lektion, die eesel auf die harte Tour gelernt hat: Legen Sie Ihre Geschäftszeiten und Übergaberegeln in den eigenen Zeitplan- und Routing-Einstellungen des Helpdesks fest, nicht nur in den Anweisungen der KI. Bei einem Kunden machte die KI trotz detaillierter Prompt-Anweisungen Fehler bei der Zeitzonenlogik. Der Zeitplan des Helpdesks ist die maßgebliche Quelle; die KI sollte daraus lesen.
Häufige Fehler bei der Support-Abdeckungsplanung
- Pro Tag statt pro Stunde planen. Ein Team, das montags „voll besetzt" ist, kann trotzdem von 9 bis 11 Uhr untergehen. Nutzen Sie die Heatmap.
- Shrinkage vergessen. Ein Plan ohne Shrinkage ist jede einzelne Woche unterbesetzt. Beginnen Sie bei 30 %, wenn Sie Ihren Wert nicht kennen.
- Dieselben Zeiten für jeden Kanal. Live-Chat für Zeiten zu öffnen, die Sie nicht besetzen können, macht aus einem guten E-Mail-Erlebnis ein schlechtes Chat-Erlebnis. Schließen Sie den Chat, bevor Sie ihn unterbesetzen; Chatbots und Live-Chat habe ich separat verglichen.
- Ruhige Stunden mit Menschen besetzen. Erlang C polstert Intervalle mit niedrigem Volumen auf, und Nächte haben meist niedriges Volumen. Das ist die teuerste Abdeckung, die Sie kaufen können.
- Kein Verantwortlicher für Ausfälle. Jeder Plan braucht eine benannte Person in Bereitschaft für das, was nicht warten kann, selbst wenn alles andere geschlossen ist.
- Den Plan nie überprüfen. Lassen Sie die Heatmap jedes Quartal und nach jedem großen Launch neu laufen, neben Ihren anderen Kundenservice-KPIs. Verfolgen Sie die erste Antwortzeit nach Tageszeit; wenn sie in einem Band hochschnellt, ist das Ihre nächste Lücke.
eesel für die Support-Abdeckungsplanung
eesels KI-Helpdesk-Teammate füllt die Felder Ihres Abdeckungsplans, die zu teuer zu besetzen sind. Er schließt sich dem Helpdesk an, den Sie schon betreiben, sei es Zendesk, Freshdesk, Gorgias, Help Scout oder Front, lernt aus Ihren früheren Tickets, Ihrem Help Center und Ihren Makros und beantwortet Routine-Tickets nachts und am Wochenende. Alles, wobei er nicht sicher ist, bleibt mit einer Zusammenfassung für Ihre nächste Schicht in der Warteschlange.
Sie können ihn gegen Hunderte Ihrer früheren Tickets laufen lassen, bevor er ein Live-Ticket anfasst, und sehen genau, welchen Anteil Ihres Volumens außerhalb der Geschäftszeiten er bearbeitet hätte. Und er fügt keine Plätze für die Nachtschicht hinzu: Der Teammate-Tarif beginnt bei $299 im Monat für 500 Credits, wobei ein Ticket oder ein Chat einen Credit kostet.
Wenn Ihre Heatmap nach 18 Uhr dunkle Felder zeigt und Sie nicht sechs Leute einstellen wollen, um sie zu füllen, testen Sie eesel kostenlos auf Ihrer eigenen Warteschlange und sehen Sie, was es am letzten Wochenende beantwortet hätte.