Ein Support-Ticket nach dem Rechnungsland weiterzuleiten klingt, als müsste es funktionieren, und funktioniert meistens nicht. Das Rechnungsland sagt Ihnen, wo ein Konto eingerichtet wurde, nicht, wo die Person, die das Ticket einreicht, gerade sitzt. Ein Unternehmen mit Support-Mitarbeitern in drei Schichten verschickte immer wieder Antworten, die um zwei Uhr morgens bei Kunden ankamen, die gerade auf Reisen waren, aus einem anderen Land remote arbeiteten oder einfach an einem Ort lebten, den ihre Rechnungsadresse nicht widerspiegelte.
Das Unternehmen stellte stattdessen auf eine Weiterleitung nach der tatsächlichen aktuellen Uhrzeit des Kunden um. Jedes eingehende Ticket enthält die IP-Adresse des Besuchers, die /v1/ip in Land, Region, Stadt und Koordinaten auflöst, zusammen mit einem Zeitzonenfeld in derselben Antwort. Diese Zeitzone, nicht das hinterlegte Rechnungsland, entschied, in welcher Schicht das Ticket landete. Ein Ticket von einer IP, in deren Region gerade Arbeitszeit war, ging an die Schicht, die in diesem Teil der Welt besetzt und wach war. Eines, das weit außerhalb der Arbeitszeit eintraf, wurde für die nächste Schicht eingereiht, bei der man vernünftigerweise erwarten konnte, dass eine Antwort zu einer normalen Uhrzeit ankommt.
Für Tickets, die einen geplanten Rückruf statt einer asynchronen Antwort erforderten, ging das Team einen Schritt weiter und übergab die aufgelösten Koordinaten an /v1/timezone. Dieser Endpunkt liefert sowohl den IANA-Zeitzonennamen als auch den UTC-Offset für diesen Punkt, berechnet für den jeweiligen künftigen Zeitpunkt, für den der Rückruf geplant wurde. Das war wichtig, weil sich Offsets mit der Zeitumstellung in verschiedenen Ländern zu unterschiedlichen Zeitpunkten verschieben, und ein Rückruf, der drei Wochen im Voraus gebucht wurde, den Offset brauchte, der an diesem Datum tatsächlich gilt, nicht den von heute.
Das Ergebnis waren weniger Antworten zu offensichtlich ungünstigen Uhrzeiten und ein Weiterleitungssystem, das sich automatisch anpasste, wenn Kunden umzogen, reisten oder einfach an einem Ort lebten, den ihr Kontodatensatz nicht widerspiegelte. Zudem erhielt das Team eine wirklich nützliche Kennzahl, die es vorher nicht gehabt hatte: wie viele Tickets außerhalb der Arbeitszeiten sämtlicher Schichten eintrafen. Daraus wurde ein datengestütztes Argument für die Anpassung der Schichtpläne statt einer Ahnung eines müden Mitarbeiters.
Nichts davon hing davon ab, dass der Kunde etwas eingab. Die IP-Adresse war bereits Teil jeder Anfrage, die das Support-Widget stellte, sodass das gesamte System ohne zusätzliches Formularfeld oder eine Aufforderung zur Bestätigung der Zeitzone lief, die man auf Reisen ohnehin gern überspringt oder falsch beantwortet.
Das Anfragevolumen entsprach eins zu eins dem Ticketvolumen und lag für einen Helpdesk dieser Größe bequem innerhalb des kostenlosen Tageskontingents, das in jedem My Geocode-Schlüssel enthalten ist, mit der üblichen Prepaid-Option, falls das Ticketvolumen darüber hinauswachsen sollte. Das Team musste nach dem Start nie über Kosten nachdenken, was in der Regel ein Zeichen dafür ist, dass ein Stück Infrastruktur still im Hintergrund seine Arbeit macht.
Die vollständigen Feldreferenzen für beide Endpunkte finden Sie unter /docs/ipv4-lookup/ und /docs/timezone-lookup/, das Verhalten bei Ratenlimits ist unter /docs/rate-limits/ beschrieben.