Escalamientos al equipo regional

• Escalamientos
  • Validación del escalamiento
    • • Qué escalar
      • Status de Zendesk
      • Status de Tymeshift
      • Status de Smooch (Facebook/WhatsApp)
      • Status del Bot
  • Crear 1 JIRA o varios
  • Descartes a hacer
  • ¿Cómo reportar un error?
    
    • A quien asignar
    • Cómo reportar el problema
    • Tiempos de respuesta (fallas de servicio)

Escalamientos

Validar casos para escalamiento

Antes de escalar un caso al equipo regional podrán existir varios items que la operación debe verificar de antemano (consecuentemente, esto apoyará a nuestro equipo con el lograr una resolución más rápida).

¿Qué escalar?

No todo es un error, puede ser que una funcionalidad de Zendesk aún no esté desarrollada del modo que sería más útil para nosotros.

En caso de duda, consultar el equipo por Slack o correo para confirmar si se requiere un JIRA.

Fallas globales de acceso a Zendesk Support o Chat en la operación tampoco serán competencia del equipo regional, por lo menos en una primera fase. Antes de abrir un JIRA, puedes verificar el status de los varios servicios de Zendesk:

Verificar status de Zendesk

Para fallas masivas de Zendesk no es necesario crear JIRA, excepto si la operación necesita una verificación específica en alguna funcionalidad a la cual perdió acceso.

El estado de Zendesk se consulta en https://status.zendesk.com/#tigopy

Esta página muestra el status de los data centers de Zendesk en los últimos 90 días (día de hoy es el rectángulo más a la derecha). En este caso filtramos para el subdominio de nuestra instancia, "tigopy".

Para más detalles sobre la página de status, consulta este artículo.

Verificar status de Tymeshift

Si se observan fallas con Tymeshift, también pueden verificar el status de esta plataforma en https://status.tymeshift.com/

La presentación visual es idéntica a la página de status de Zendesk:

---

Verificar status de Smooch

Si se observan fallas en los canales de comunicación entre Facebook/Whatsapp y Zendesk, verificar en https://status.smooch.io/

La presentación visual es idéntica a la página de status de Tymeshift:

Verificar status del Bot

Si se observan fallas en la comunicación del bot, el bot no responde, el bot no hace handoff, etc, verificar el status de los componenetes del bot en https://status.mic.edge.com.py/?component=2 

En caso de urgencia, llamar al teléfono de soporte [phone]. La llamada debe realizarse una vez esté documentado el caso en JIRA y sólo cuando se trate de fallas críticas de la plataforma (caída total o afectación masiva a los usuarios).

---

Debo crear 1 JIRA, ¿o varios?

Si una solicitud tiene varias tareas distintas pero están dentro del mismo contexto, tenemos varias opciones: (1) utilizar el mismo JIRA o (2) en alternativa, crear un JIRA-padre y después crear los JIRA subtareas ("More » Create sub-task") que quedarán vinculados al principal:

Ejemplo teórico. Configuración de nuevo flujo, con nuevos agentes y Grupo:

• JIRA 1 (normal), "Nuevo flujo X": principal que describe el flujo (cómo nace el ticket, quien atiende, etc., cualquier detalle del flujo que debemos tener en cuenta)
• JIRA 2 (sub-tarea), "Solicitud de licencias para nuevo flujo X + agent views Tymeshift"
• JIRA 3 (sub-tarea), "Datos a enviar via API para nuevo flujo X"
• Etc.

Ejemplo real. El JIRA ZEN-2266 es un JIRA-padre que se creó para establecer la tarea de definir mensajes de inactividad inicialmente. Como tenemos varias operaciones, se creó un JIRA sub-tarea por cada país:

---

Descartes a hacer

Dependiendo de la situación/contexto del inconveniente, podrán existir items a verificar por parte de la operación antes de decidir el escalamiento.

Por ejemplo:

• Temas de redes con otra conexión alterna (datos de un cel)
  • E.g. no abre Chat o Support? Pasa con un usuario? Con varios? Con todos?
• Limpieza de cookies y cache del navegador de los usuarios afectados
  • E.g. a usuario X le carga Chat pero la página queda en blanco
• Verificar si el agente está en el Grupo correcto
  • E.g. usuario X no ve las Vistas de redes sociales o email
• Etc.

---

¿Cómo reportar un error?

El canal oficial es JIRA, según el problema detectado:

Problemas de conexión o lentitud en Zendesk, enrutamiento de tickets, macros, nps, agentes, dashboards: Proyecto ZEN.

Fallas relacionadas con el bot: OMLATAM Ver: Proceso de Soporte BOT

El mejor proceso para nuestro equipo:

1. JIRA con el máximo detalle posible
2. Análisis del equipo, preguntas de seguimiento en el JIRA
   • Si necesario, agendamos una llamada de seguimiento para aclarar puntos, o revisamos por Slack.
3. Confirmación de la operación por escrito en el JIRA
4. Cierre del JIRA

Si es un tema relacionado con chatbot pero relacionado con Zendesk, o tienes dudas, también puedes crear el JIRA en el proyecto TBOT.

A quien asignar

Dependiendo del contexto/tópico de la solicitud, el JIRA se asigna a personas distintas:

• Licencias
  • Zendesk: Felipe Peña + Cc Onel Cuellar, Eduardo Castro
  • Tymeshift
    • Nuevas licencias: Eduardo Castro + Cc Felipe Peña, Onel Cuellar, Jhoan Zabala, Mauricio Calderón
    • Bajas o reemplazos: Felipe Peña, + Cc Onel Cuellar, Jhoan Zabala, Mauricio Calderón
• Nuevos flujos/procesos
  • Eduardo Castro + Cc Jhoan Zabala, Onel Cuellar, Mauricio Calderón, Diego García, Jorge Lage
• Cambios o inconvenientes con flujos, configuraciones, etc.
  
  • Zendesk: Jhoan Zabala + Cc Mauricio Calderón, Diego García, Onel Cuellar
  • Tymeshift: Onel Cuellar + Cc Jhoan Zabala, Diego García
• Reportes (Insights/GoodData/Explore)
  
  • Jhoan Zabala + Cc Onel Cuellar, Diego García
• Bot
  • Crear un OMLATAM + cc siempre a Diego García, Mildred Vivas y Armando Umerez. Ver: Proceso de Soporte BOT
• Redshift

  • Crear JIRA en proyecto CIA ("Cloud Infra Admin") asignado a Nicodemo Peloso + Cc Juan Carballo, Armando Umerez, Diego García

• ⚠ ¿No sabes a quien asignar?
  
  • Jhoan Zabala + Cc Mauricio Calderón, Onel Cuellar

Presentación del problema

De modo a que podamos analizar rápidamente el caso, necesitamos obtener una descripción lo más detallada posible de la información pertinente.

Les agradecemos la siguiente información, siempre y cuando aplique:

• Qué está pasando
• Cuando (o a partir de cuando) se verificó el problema
• Donde está(n) ocurriendo esto(s) inconveniente(s)
• Quien está afectado por el problema.
• Evidencias. Dependiendo del caso puede ser un ticket ID, correo electrónico del usuario, gráficas (capturas de pantalla, videos), vínculos para las páginas con problema, etc.
• Cualquier otro detalle que consideren útil o pertinente

Tiempos de respuesta de fallas

Los tiempos de respuesta varían de acuerdo al tipo de solicitud o de reporte. Para casos en los que se evidencien fallas en las plataformas, según las páginas de status descritas más arriba, los tiempos de respuesta por parte del proveedor oscila están entre 1 y 4 horas así:

Prioridad	Horario de atención	Tiempo de respuesta
3 Preguntas generales, inconvenientes con el uso del producto	9 am a 8 pm  Lunes a Viernes	4 horas
2 Degradación del servicio. Funciona, pero alguna funcionalidad está afectando la experiencia del usuario o de los agentes	9 am a 8 pm  Lunes a Viernes	2 horas
1 Plataforma caída. El producto no funciona hace más de 5 minutos.	24 x 7	1 hora