Proceso de Soporte BOT

Con el fin de aprovechar y optimizar el proceso de soporte del BOT, creamos este artículo que describe el paso a paso que debe seguir al momento de reportar cualquier error (bug) del BOT.

El proceso definido a continuación aplica para fallas encontradas en producción, cualquier solicitud de cambio o reporte de fallas en TEST debe ser reportado en el proyecto de TBOT y no a OMLATAM.

• Escalamiento
  • A quien asignar
  • Cómo reportar el problema
  • Tipos de Incidentes 
  • SLA (tiempos de respuesta)
  • Matriz de escalamiento
  • Preguntas Frecuentes 

Escalamiento

Para atender los casos apropiadamente, sigue este flujo:

A quien asignar

• El usuario debe crear JIRA en OMLATAM y asignado a OMLATAM).

Cómo reportar el problema

1. El ticket debe contener (Tomar plantilla base TBOT-5942):

Campo	Información a enviar
Type	Bug
Titulo	Plataforma :: País :: Titulo :: Unidad de Negocio (Ejemplo: Whatsapp :: PA :: Error :: HOME)
Priority	Blocker / Critical / Major / Minor  /Low Ver detalle en sección "Tipo de incidentes"
Country	Seleccionar país que corresponde
Sub-System:	Bot ECARE
Description	El jira debe contener siempre lo siguiente:
Descripción:	Descripción general del error presentado.
Flow:	Paso a Paso Paso a paso donde se indique como reproducir el error.
Evidencia del paso a paso:	Puedes imágenes o video pero debe tener evidencias del paso a paso para reproducir error
Números del BOT	Números del BOT donde se presenta el error.
Zendesk:	Deben relacionar el Ticket de zendesk con el histórico de la conversación relacionado al error
Masivo o Específico	Indicar si pasa con todas las cuentas (es masivo) o con una o algunas cuentas (específico)
Data de prueba	Data con la que probaron y se puede reproducir error
Siempre dejar en copia a:	[e-mail], [e-mail], [e-mail] [e-mail]

3. OMLATAM toma el caso y asigna a soporte.edge (Soporte EDGE-Monitor-Team).

4. Los incidentes son tomados por el área de Soporte de Edge.

5. Si Soporte de Edge no puede solucionar el incidente o se determina que es responsabilidad de un tercero, debe agregar documentación correspondientemente así como etiqueta en el ticket para identificar si el problema es del (BOT; API; SMOOCH o ZENDESK)

 

Tipos de Incidentes

#	Prioridad	Definición
1	Blocker	La operación esta interrumpida y no hay forma alternativa de funcionamiento.
2	Critical	La operación se ve severamente degradada, pero hay formas mínimas de funcionamiento.
3	Major	La operación tiene un impedimento menor, pero no tiene un impacto general significativo
4	Minor	La operación tiene un impedimento menor, pero no tiene un impacto general significativo
5	Trivial	Solicitud general de información u orientación. Errores de menor impacto. La operación no se ve impactada.

 

Prioridad que deben asignar según el caso

Tomar en cuenta que según el caso reportado y el impacto del mismo se debe asignar la prioridad en el jira de OMLATAM

A continuación ejemplos de los casos más comunes y según el impacto que prioridad le deben asignar:

Caso	Impacto a un cliente	Impacto algunos clientes (Es replicable o se puede medir la afectación)	Impacto Todo un número	Impacto Todo un país	Todos los países
BOT no responde nada	Trivial	Major	Blocker	Blocker	Blocker
BOT responde pero lento (por más de 3 minutos)	Trivial	Major	Blocker	Blocker	Blocker
Desborde al asesor no funciona	Trivial	Major	Blocker	Blocker	Blocker
BOT responde pero lento (por más de 2 minutos)	Trivial	Major	Critical	Blocker	Blocker
BOT Responde pero un CU diferente al solicitado	Trivial	Major	Critical	Blocker	Blocker
Caso de uso no responde que requiere api (Autenticación, Facturas, saldos, consumos, visitas, reagendamiento, reset de modem, etc...)	Trivial	Major	Critical	Blocker	Blocker
Desborde al asesor funciona pero se asigna a grupos incorrectos o no funciona en geral el desborde	Trivial	Major	Critical	Blocker	Blocker
Intención especifica (wit) no responde correctamente	Trivial	Major	Critical	Critical	Blocker
Errores con link - Links rotos	Trivial	Minor	Minor	Minor	Minor
Opción de menú no responde	Trivial	Minor	Major	Major	Major
Error en evento a segment/mixpanel (un único evento)	Trivial	Minor	Major	Major	Major
Error en evento a segment/mixpanel (varios evento o todos)	Trivial	Minor	Critical	Critical	Critical
Alguna regla de negocio y/o validación esta fallando	Trivial	Minor	Major	Major	Major
Cualquier otro bug no especificado	Trivial	Minor	Minor	Minor	Minor
Cambio de texto	No aplica como bug	No aplica como bug	No aplica como bug	No aplica como bug	No aplica como bug
Mejoras, nuevas funcionalidades, cambios de reglas de negocio, tareas, entre otros diferentes a errores	No aplica como bug	No aplica como bug	No aplica como bug	No aplica como bug	No aplica como bug

💡RECUERDA: Si no es un error debe ser reportado en un jira en el proyecto de TBOT.

SLA

Severidad	Tiempo de Respuesta	Tiempo de Resolución
1.Blocker y Critical	30 min	Trabajo 24x7 hasta que el incidente esté resuelto o se encuentre una solución alternativa que lo degrade de prioridad.
2. Major	4 Horas de Oficina	Atender el caso durante horas de oficina hasta que se resuelva o se encuentre una solución alternativa, con el objetivo de solución en 3 días de oficina.
3. Minor	1 día de Oficina	Atender el caso durante horas de oficina hasta que se resuelva o se encuentre una solución alternativa, con el objetivo de solución en 10 días de oficina.
4. Trivial	5 días de Oficina	Atender el caso durante horas de oficina hasta que se resuelva o se encuentre una solución alternativa, con el objetivo de solución en 10 días de oficina.

NOTA Los tiempos indicados (minutos, horas y días) son de acuerdo a las horas de oficina de Edge (lunes a viernes de 9 hs a 18 hs) en la zona horaria de Paraguay (UTC-4 de marzo a octubre y UTC-3 de octubre a marzo), a menos que se especifique lo contrario.

Estos indicadores de nivel de servicio asumen que Edge tiene acceso a los sistemas que debe soportar. Tiempos de espera debidos al Cliente, terceras partes, fallas de otros sistemas fuera de ámbito, no afectarán estas métricas. 

Matriz de Escalamiento

Todo el seguimiento al caso debe ser a través de OMLATAM.

Preguntas Frecuentes

• Encontré un bug en el BOT, ¿Dónde reporte el problema?

Se debe crear un Jira asignado a OMLATAM con el detalle correspondiente.

• ¿Cómo va la solución del problema?

Cualquier consulta relacionado a la solución del problema debe realizarse por el jira y OMLATAM será garante de canalizar las dudas y se tenga respuesta.

• Tengo un bug Blocker y Critical y paso más de una hora sin respuesta ¿Cómo valido u obtengo respuesta?

Se deje validar estado con OMLATAM, sino se tiene respuesta y es urgente llamar al Teléfono de soporte (llamadas solamente, no por whatsapp): [phone]

• Tengo un caso que reporté al BOT y lo escalaron a otro quipo ¿Cómo válido si esta resuelto?

El primer canal siempre debe ser el mismo jira reportado a OMLATAM.

• ¿Qué hago si me devuelven el jira porque no estaba completo y/o falta algún detalle?

Complementar el jira lo más que se pueda y mínimo con todos los requisitos definidos en la plantilla. Comentar y asignar nuevamente a OMLATAM. 

• ¿Puedo reportar por slack, WhatsApp u otro canal diferente a jira un caso?

No, el canal para reportar los casos siempre debe JIRA asignado a OMLATAM. Lo demás canales se pueden usar como alternativos una vez se cree el jira y sea asignado correctamente.

• Hicieron un cambio en la api y la información mostrada es incorrecta ¿A quien reporto?

Implica cambio en la lógica definida inicialmente, por lo que es una mejora a lo definido inicialmente se debe solicitar en el proyecto TBOT.

• Necesito implementar un nuevo ID de horario

Es una mejora, por lo que se debe solicitar en el proyecto de JIRA TBOT.

• Necesito implementar una mejora o nueva funcionalidad o tarea

Se debe solicitar JIRA en el proyecto TBOT.