Les empreses amb operacions globals s'enfronten a un repte constant: oferir suport tècnic ininterromput sense mantenir torns de nit a totes les oficines. La solució clàssica és l'encaminament follow-the-sun, que assigna automàticament cada ticket a la regió que en aquell moment es troba en horari laboral. No obstant això, la implementació tècnica amaga una complexitat que molts subestimen: els canvis d'horari d'estiu, les finestres de cobertura nocturna i la necessitat d'un fallback quan cap hub està operatiu.
A Q2BSTUDIO hem treballat amb múltiples empreses per dissenyar sistemes d'encaminament intel·ligents, integrant cloud AWS/Azure, IA i automatització de processos. Aquesta experiència ens ha ensenyat que un router de tickets basat en zona horària no és un problema d'operacions exclusivament, sinó un desafiament d'enginyeria de programari que requereix precisió en el maneig del temps, tolerància a fallades i una arquitectura extensible.
L'enfocament ingenu consisteix a hardcodejar offsets UTC, però això es trenca dues vegades a l'any quan els rellotges canvien. Pitjor encara, si el teu servidor està en una zona i el teu equip en una altra, l'hora local del servidor no serveix. La solució correcta és delegar el càlcul del temps a una API de zones horàries que retorni l'hora local real de cada hub, incloent l'estat DST (horari d'estiu). Així, en lloc de sumar o restar hores manualment, compares directament l'hora local en format string (per exemple, "09:30:00") amb la finestra de cobertura definida a la teva configuració.
Modelar els hubs de suport és el següent pas. Cada hub ha de tenir un identificador, una zona IANA (com "Europe/Berlin"), un diccionari d'horaris per dia de la setmana (obert i tancat), una llista de festius locals i una prioritat per a desempats. També és recomanable incloure els idiomes que gestiona, per encaminar preferentment a un hub que parli l'idioma del client. La configuració ha d'estar en un fitxer a part, no incrustada en la lògica d'encaminament, perquè els canvis de cobertura no requereixin modificar el codi.
La lògica de decisió es redueix a tres passos: determinar quins hubs estan oberts en la seva hora local, seleccionar el millor entre ells (per idioma, prioritat i un tie-break estable), i retornar un fallback si cap ho està. El fallback és crucial: mai no s'ha de deixar un ticket sense assignar. En lloc d'això, s'envia a un hub de guàrdia (on-call) que estigui configurat per rebre tickets fora d'horari. Això és millor que perdre un ticket o que un hub en rebi un quan no hi ha ningú.
A més de l'encaminament, és molt útil enriquir el ticket amb l'hora local del client. Saber si el client escriu a les 3 de la matinada o a les 2 de la tarda canvia el to de la resposta. Una crida addicional a la mateixa API de zona horària, però utilitzant la IP del sol·licitant, proporciona la seva ciutat, país i hora local. Aquesta dada es pot afegir com a comentari intern al sistema de tickets (Zendesk, Freshdesk, etc.) perquè l'agent tingui context.
La implementació tècnica es pot fer amb qualsevol llenguatge, però aquí utilitzem TypeScript per mostrar el patró. Es defineix un client HTTP que consulta l'API amb un timeout (1.5 segons) i cacheja el resultat per zona durant 30 segons, per no martellejar l'endpoint en pics de tickets. Després, la funció isOpenNow rep un hub, obté la seva hora local, extreu el dia de la setmana de la resposta, i compara l'hora actual amb la finestra definida per a aquell dia. També gestiona finestres nocturnes (per exemple, de 22:00 a 06:00) revisant si l'hora actual cau en la part del dia anterior.
Quan diversos hubs estan oberts, s'ordenen primer per coincidència d'idioma, després per prioritat numèrica i finalment per identificador (per estabilitat). El primer de la llista és el destí. Si cap està obert o totes les crides fallen, s'utilitza el hub de fallback predefinit.
Un error comú és no considerar que l'hora local del hub pot no estar disponible per un error de xarxa o límit de taxa. La funció ha de retornar un estat "unknown" en lloc de "false", perquè una fallada no equival a "tancat". Així evitem encaminar a un hub que podria estar obert però no vam poder verificar, o tancar la porta a tots els hubs quan només un va fallar.
La integració amb sistemes de helpdesk com Zendesk és directa: un trigger al helpdesk envia un POST al teu endpoint quan es crea un ticket. El teu servei executa l'encaminament i després actualitza el grup o regió del ticket mitjançant l'API corresponent. És important que l'endpoint retorni un codi d'error (per exemple, 502) si l'assignació falla, perquè el trigger de Zendesk pugui aplicar una regla de suplència.
Des de la perspectiva de Q2BSTUDIO, aquest tipus de solució encaixa perfectament en projectes d'automatització de processos programari. La lògica d'encaminament es pot ampliar amb agents d'IA que classifiquin tickets per urgència o sentiment abans d'enviar-los al hub adequat. També es pot integrar amb quadres de comandament de Business Intelligence (Power BI) per analitzar els temps de resposta per regió i optimitzar les finestres de cobertura.
La ciberseguretat no s'ha de descuidar: les APIs de zona horària s'han d'autenticar amb clau, i l'endpoint d'encaminament s'ha de protegir contra injeccions i abusos. Q2BSTUDIO ofereix serveis de ciberseguretat i pentesting per garantir que la teva infraestructura cloud (AWS/Azure) sigui robusta davant d'atacs.
En resum, l'encaminament automàtic de tickets per zona horària és una peça de programari que sembla simple però requereix atenció al detall. Amb una arquitectura basada en APIs de temps real, configuració externalitzada i un fallback sòlid, qualsevol empresa global pot oferir suport 24/7 sense duplicar equips. Si estàs plantejant implementar un sistema així o necessites assessorament sobre desenvolupament d'aplicacions a mida, a Q2BSTUDIO podem ajudar-te a dissenyar una solució escalable, segura i adaptada al teu negoci.
