Manual de soporte
1. Introducción
1.1 Propósito del Documento
Este Manual proporciona una visión general del Soporte de Navegasoft, incluidas las definiciones de los programas, procesos y procedimientos.
1.2 Alcance
Este documento cubre las políticas, procedimientos y prácticas del servicio y soporte analista de los productos de Navegasoft cubiertos por el Soporte.
1.3 Definiciones, Acrónimos y Abreviaturas
- Soporte: Conjunto de servicios ofrecidos de forma estándar para todos los clientes.
- Tique: Registro formal de una solicitud o reporte hecho por un cliente.
- SLA: Es el acuerdo entre nuestro equipo de soporte y nuestros clientes que establece de manera clara y detallada los servicios que serán proporcionados. El SLA define los estándares de calidad, disponibilidad y rendimiento que nuestro equipo se compromete a cumplir, asegurando así la satisfacción y las expectativas claras de nuestros clientes. Este acuerdo incluye métricas específicas para evaluar el desempeño de los servicios prestados, las responsabilidades de ambas partes y las políticas de respuesta ante incidentes, garantizando una gestión eficaz y una comunicación transparente. Además, se detallan las compensaciones o remedios en caso de que no se cumplan los niveles de servicio acordados, reafirmando nuestro compromiso con la excelencia y la mejora continua.
1.4 Referencias
- Página web de Navegasoft
- Manual de usuario de los productos de Navegasoft
1.5 Visión General del Documento
Este documento detalla la estructura organizacional, procesos, herramientas y políticas relacionadas con el soporte analista de Navegasoft.
2. Estructura Organizacional del Soporte
2.1 Roles y Responsabilidades
- Soporte Nivel 1: Atención inicial, resolución de problemas comunes.
- Soporte Nivel 2 - Funcional: Atención especializada, solución de problemas más complejos basados en experiencia.
- Soporte Nivel 3 - Analista: Soporte analista especializado y solución de problemas analistas avanzados.
Para acceder a la lista de personas disponibles organizada por rol, por favor siga el siguiente enlace:
https://www.navegasoft.com/web#id=124&menu_id=785&cids=1&action=1814&model=knowledge.article&view_type=form
2.2 Estructura del Equipo de Soporte
El equipo de soporte está estructurado en tres niveles, cada uno con responsabilidades y habilidades específicas.
|
Nivel |
Responsabilidades |
Habilidades |
|
1 |
Atender tiques de bugs, problema, pregunta y anomalía. |
Conocimientos básicos de Odoo. |
|
2 |
Atender tiques de problema, pregunta, anomalía y bugs. (siempre y
cuando el Niel 1 no pueda dar solución) |
Conocimientos avanzados de Odoo. |
|
3 |
Investigar y resolver bugs. |
Conocimientos expertos de Odoo y código python. |
2.3 Flujos de Comunicación
Canales Oficiales de Comunicación para Soporte
- Tiques: A través de nuestro sitio web.
- Correo de Soporte: [email protected]
- Llamadas a través de Zadarma: Al número publicado en nuestra web.
- Chat de Odoo: Canal de chat disponible en la web.
- Anydesk: Asistencia remota en caso de ser necesario.
Uso de WhatsApp
- No Oficial para Soporte: WhatsApp no es un canal oficial para solicitudes de soporte.
- Sin Trazabilidad: Las comunicaciones a través de WhatsApp no serán consideradas para la trazabilidad ni para calcular el tiempo de los SLA (Acuerdos de Nivel de Servicio).
- Uso Permitido: Contingencia en caso de no poder usar Odoo, actualizaciones rápidas.
Consecuencias del Uso No Autorizado de WhatsApp
- No Garantía de Respuesta: Aclarar que las solicitudes de soporte a través de WhatsApp pueden no ser atendidas.
- No Afectación a SLA: Las solicitudes a través de WhatsApp no afectarán los cálculos de los SLA.
- Inicio del Proceso de Asistencia
Es fundamental para la eficacia de nuestro soporte que todos los casos, sin importar el medio por el cual se reciben (telefónico, correo electrónico, chat en vivo, etc.), sean formalmente registrados en nuestro sistema de gestión de tiques. Este procedimiento garantiza que cada solicitud de soporte sea adecuadamente rastreada, gestionada y resuelta, manteniendo un alto nivel de servicio y satisfacción del cliente.
Registro en el Sistema de Tiques: Un Requisito Indispensable
El proceso de asistencia técnica comienza oficialmente en el momento en que el tique es registrado en nuestro sistema. Este paso es crucial para:
1. Asegurar la trazabilidad: Permite un seguimiento detallado del caso desde su apertura hasta su cierre, facilitando la revisión de acciones realizadas y la comunicación con el cliente.
2. Mejorar la gestión del tiempo y recursos: Facilita la asignación eficiente de los casos al personal de soporte adecuado, optimizando la resolución de problemas.
3. Mantener la consistencia: Garantiza que todos los casos se manejen siguiendo los mismos estándares de calidad, independientemente de cómo se recibió la solicitud de soporte inicialmente.
4. Facilitar la retroalimentación y mejora continua: Proporciona datos valiosos para analizar tendencias, identificar áreas de mejora y desarrollar estrategias para elevar la calidad del servicio.
Política de Registro de Tiques
Para mantener la integridad de nuestro proceso de soporte, se requiere que todos los miembros del equipo sigan rigurosamente esta política, asegurando así la eficiencia y efectividad de nuestra asistencia técnica. Este enfoque estandarizado nos permite ofrecer una experiencia de soporte excepcional, marcando una diferencia significativa en la satisfacción de nuestros clientes.
3. Procesos de Soporte
3.1 Proceso de Recepción de Solicitudes
Las solicitudes de soporte se reciben a través de la página web de Navegasoft, donde los clientes pueden generar un tique detallando su problema o consulta o por medio de chats en vivo. Cuando se recibe una solicitud de soporte analista, el analista debe realizar lo siguiente:
Confirmar la identidad del usuario. El analista debe solicitar al usuario su nombre, compañía o cualquier otra información que sea necesaria para identificarlo si fuese por medio de chat, en caso de ser por medio de tique se debe verificar que se cuente con la información para identificar que cliente es, en caso contrario deberá solicitar más información por medio del mismo tique, con la finalidad de conocer que cliente es y poder brindar soporte.
Verificar la suscripción: El analista deberá verificar los servicios contratados por el cliente, para reconocer:
· Si tiene una suscripción activa: Las suscripciones que se encuentran activas están marcadas en la etapa 'En progreso'. Para acceder a estas suscripciones, es necesario dirigirse al módulo de suscripciones y utilizar los filtros disponibles para buscar por nombre o por número de suscripción, en caso de tener esta información disponible. Cabe destacar que el número de suscripción corresponde a la orden de venta que generó dicha suscripción.
· Que no se encuentre en mora: Para verificar si algún cliente se encuentra en mora, debe acceder a la sección de suscripción donde encontrará un botón denominado 'Facturas'. Dentro de esta sección, si observa que alguna factura en la columna 'Fecha de Vencimiento' supera los 10 días de retraso, dicha suscripción se considerará en mora.
En caso de que se haya llegado a un acuerdo con el cliente, podrá verificar esta información en la misma vista. Junto a la columna de facturas, encontrará la columna 'Actividades'. Si el acuerdo está vigente, el estado de la actividad mostrará la palabra 'Acuerdo' seguido de la fecha hasta la cual es válido. Si esta fecha aparece en rojo, significa que el acuerdo ha sido incumplido."
Es importante destacar que, si la suscripción cuenta únicamente con una factura, el sistema incluirá directamente en ella información relevante. Podrá observar el estado de la factura, el cual estará indicado mediante una etiqueta situada en el margen del documento. Adicionalmente, al final del documento, se detallará cualquier actividad relacionada, incluyendo los acuerdos existentes, si los hubiere.
Determinar el problema. El analista debe trabajar con el usuario para determinar el problema que está experimentando. En caso de que la información no esté completa, se deberá solicitar mayor detalle por medio del tique, en caso de prioridad urgente y si lo ve prudente el analista comunicarse vía llamada para tener mayor contexto, pero siempre dejar evidencia en el tiquet.
Clasificar el problema. El analista debe clasificar el problema en una de las siguientes categorías:
1. Problema
2. Pregunta
3. Anomalía
4. Usabilidad
5. Bugs
6. Solicitud
Registrar la solicitud. En caso de que por medio del chat no se pueda dar respuesta al cliente, el analista deberá dejar registrado en el módulo de “servicio de asistencia” la solicitud y deberá indicar le al cliente el # del tique.
Si por el chat se logra dar respuesta, se debe crear el tique en todo caso, y cerrarlo para registrar la evidencia de la asistencia.
3.2 Clasificación y Priorización de Tiques
Tipos de tiques
Los tipos de tiques se dividen en las siguientes categorías:
Problema: Advertencias que surgen en el sistema, como que no les deja firmar un documento electrónico, está haciendo mal los cálculos, etc.
Pregunta: Se entiende como las dudas que le pueden surgir al usuario.
Anomalía: Un comportamiento anormal en el sistema como que no deje ingresar a un módulo, aunque se tenga el permiso, no tome la configuración contable, etc.
Bugs: Errores en el funcionamiento del sistema o ventanas emergentes con código, que no sean comprensibles por el usuario.
Solicitud: Estas solicitudes se pueden deber a que requieren una sesión, desarrollos los cuales serían escalados al departamento comercial, ajustes, requerimiento de facturas, certificados, etc.
Usabilidad: Estas situaciones, aunque menos frecuentes, se relacionan con elementos del diseño de la plataforma o del proceso de ejecución de tareas que podrían resultar confusos para el usuario. Se identifican y clasifican específicamente en este apartado con el objetivo de comunicar internamente al equipo de desarrollo la necesidad de realizar ajustes. El propósito es mejorar la experiencia de usuario, abordando proactivamente cualquier aspecto que pueda interferir con la usabilidad o la comprensión de la plataforma.
Descripción de los tipos de tiques
Problema
Los tiques de problema son aquellos que afectan el funcionamiento del sistema, pero no impiden su uso. Estos tiques deben ser atendidos en un plazo de 24 horas.
Se aconseja proporcionar siempre una solución alternativa (Plan B) al usuario en espera de una respuesta definitiva. Además, se insta al soporte de nivel 1 a documentar meticulosamente estas soluciones alternativas. Esto no solo mejora la eficiencia en la gestión de futuras consultas, sino que también asegura una experiencia de usuario fluida y satisfactoria mientras se trabaja en resolver el problema de manera definitiva.
Pregunta
Los tiques de pregunta son aquellos que no afectan el funcionamiento del sistema, sino que son dudas o consultas que tienen los usuarios, requieren la creación de material de apoyo para el usuario, como video tutoriales o indicaciones Estos tiques deben ser atendidos en un plazo de 48 horas.
Anomalía
Los tiques de anomalía son aquellos que muestran un comportamiento anormal del sistema. Estos tiques deben ser atendidos en un plazo de 72 horas.
Bugs
Los tiques de bugs son aquellos que reportan errores en el funcionamiento del sistema. Estos tiques deben ser escalados al equipo de desarrollo.
Solicitud
Los tiques de solicitud son aquellos que requieren una acción por parte del equipo de soporte, como una sesión de formación, un desarrollo, un ajuste, etc. Estos tiques deben ser atendidos en un plazo de 3 días hábiles.
Usabilidad
Es imperativo que estos tiques se atiendan dentro de un plazo máximo de dos días hábiles, asegurándonos de confirmar la recepción y evaluación de cada solicitud. Aunque no nos comprometemos a realizar mejoras inmediatas, sí ofrecemos nuestro apoyo al usuario para facilitar su comprensión del proceso. Esto puede incluir la provisión de una sección de preguntas frecuentes, tutoriales en video, o asistencia directa mediante AnyDesk. Paralelamente, nuestro equipo de desarrollo trabajará en optimizar el flujo basándose en estos insights.
Etapas de los tiques
Comprender el funcionamiento de las diferentes etapas por las que atraviesa un tique y las implicaciones de cada cambio de estado es fundamental. A continuación, se detallan estos estados:
- Nuevo: Se refiere a los tiques recién recibidos en la bandeja de entrada del sistema de gestión de tiques, que aún no han sido clasificados ni priorizados.
- En proceso: Indica que el tique está siendo gestionado activamente por el responsable asignado.
- En proceso del solicitante: Este estado se utiliza cuando se necesita información adicional o retroalimentación por parte del cliente para avanzar en la resolución del tique o validar la solución propuesta.
- Resuelto: Se asigna a los tiques cuya solución ha sido implementada satisfactoriamente, resolviendo la necesidad planteada por el cliente.
- Cancelado: Aplica a los tiques que no son procedentes por diversas razones, tales como estar en mora, no contar con un servicio activo con nuestra empresa, o ser duplicados de otro tique que ya está siendo atendido.
Estado de las etapas
El sistema emplea un método de señalización similar a un semáforo, donde, por defecto, cada etapa se muestra en color gris, indicando que el tique está en “En progreso”. El color verde significa que el tique está en “Preparado(a)” se ha completado y está listo para avanzar a la siguiente etapa. Por otro lado, el color rojo significa que el tique está en “Bloqueado(a)”, el proceso está bloqueado, lo cual puede deberse a la necesidad de realizar alguna acción adicional en paralelo, dependiendo del tipo de tique. En el caso de los tiques nuevos que aparecen con un estado en verde, esto indica que ya han sido clasificados y priorizados por un analista de soporte de nivel 1.
Categorías de los tiques
El sistema permite la asignación de múltiples categorías a cada tique, una función esencial que facilita la automatización en la generación de tareas en algunos casos. Esta funcionalidad es crucial no solo para identificar los módulos que presentan incidencias con frecuencia, sino también para distinguir entre las solicitudes que implican la realización de un proceso específico por parte de nuestro equipo. Estos procesos pueden incluir:
- Activar base: Acciones requeridas para obtener y asegurar datos de forma segura.
- Folios: Procedimientos para habilitar o registrar nuevos folios en el sistema.
- Cotización: Elaboración de estimaciones de costos para servicios o productos.
- Garantía: Procesos relacionados con la validación y aplicación de garantías para nuestros servicios o productos.
La clasificación precisa en categorías como 'Módulos’, 'Proceso' y 'Origen’ no solo mejora nuestra eficiencia al gestionar y resolver tiques, sino que también nos proporciona información valiosa para analizar tendencias y mejorar continuamente nuestro sistema y procesos.
Prioridad
Nuestro sistema clasifica las prioridades mediante un sistema de estrellas, que indica el nivel de urgencia de cada ticket. La ausencia de estrellas señala una prioridad baja; una estrella indica una prioridad media, sugerente de problemas que afectan la operatividad pero que pueden gestionarse con soluciones alternativas o un plan B. Dos estrellas representan una prioridad alta, asignada a situaciones en las que el cliente enfrenta impedimentos para emitir cualquier tipo de documento electrónico. Tres estrellas marcan una situación urgente, reservada para casos en los que el cliente no puede acceder o utilizar la plataforma en absoluto o entrar al punto de venta para operar.
La categorización se aplica de la siguiente manera:
- Urgente (tres estrellas): Para situaciones críticas donde el cliente no puede operar o acceder a la plataforma.
- Alta (dos estrellas): Cuando el cliente es incapaz de emitir documentos electrónicos, afectando operaciones esenciales.
- Media (una estrella): Para problemas operativos que, aunque perturbadores, permiten continuar trabajando mediante alternativas o soluciones temporales.
- Baja (sin estrellas): Para casos que no requieren acción inmediata.
Esta estructura de priorización asegura una respuesta rápida y adecuada a las necesidades de nuestros clientes, optimizando la asignación de recursos para resolver incidencias de manera eficiente.
Independientemente del tipo de ticket inicial, si el analista determina que este cumple con los criterios para ser clasificado como prioridad urgente, la respuesta debe ser inmediata, asegurando que el tiempo de atención no exceda las 8 horas. En situaciones donde no sea posible ofrecer una solución inmediata, es crucial mantener informado al solicitante de manera constante sobre el progreso, hasta alcanzar una resolución satisfactoria.
Es crucial resaltar que, en el Acuerdo de Nivel de Servicio (SLA) publicado en nuestra web, el término 'prioridad' no se utiliza. En su lugar, se emplea 'impacto' como categoría, con los niveles 'crítico', 'alto', 'medio' y 'bajo'. Internamente, estos niveles corresponden a 'urgente' (tres estrellas), 'alto' (dos estrellas), 'medio' (una estrella) y 'bajo' (sin estrellas). Esta adaptación terminológica tiene como objetivo alinear nuestra comunicación web con la percepción del cliente sobre el impacto que un incidente puede tener en su negocio, en lugar de enfocarnos únicamente en nuestra clasificación interna de prioridad.
3.3 Asignación de Tiques
Basado en la clasificación y priorización, los tiques se asignan al nivel correspondiente de soporte.
El nivel 1 es el responsable de categorizar y tipificar los tiques, dependiendo de esto se deberá gestionar oportunamente o escalar al nivel o área correspondiente.
3.4 Resolución de Incidentes
Una vez que se ha registrado la solicitud de soporte, el analista debe investigar y resolver el problema.
Investigar el problema. El analista debe recopilar información sobre el problema, como los pasos para reproducirlo, los mensajes de error que se producen y cualquier otra información que sea relevante.
Escalar tiques. En caso de ser necesario se debe verificar si el tique se debe escalar, el analista encargado del nivel 1 debe cerciorarse a que nivel será escalado y si cuenta con la información necesaria y aprobación por parte del cliente en caso de ser necesario.
Probar soluciones. El analista debe probar diferentes soluciones para resolver el problema.
Comunicar la solución al usuario. El analista debe comunicar la solución al usuario, incluyendo instrucciones sobre cómo implementarla.
Es esencial mantener al cliente continuamente informado sobre el progreso del proceso, especialmente si se prevé que el tiempo de respuesta se acercará al límite establecido en nuestra promesa de servicio.
3.4.1 Tipos de incidencias identificadas y manejo
El uso del término "indiferente" en las categorías indica que este dato no afecta o es relevante para el tipo específico de incidencia en cuestión.
No.1
Nombre: Desconfiguración
Tipo: Anomalía
Categorías: Indiferente
Diagrama:
Este documento describe el procedimiento estructurado en fases para manejar eficientemente los tickets de soporte técnico, asegurando un enfoque ordenado desde la apertura hasta la resolución del ticket. En caso de detectarse manipulaciones indebidas del sistema, se activará un protocolo especial para abordar estos incidentes.
Fase 1: Verificación Inicial
- Verificar Estado del Cliente: Confirmar la activación del cliente y que no haya retrasos en la facturación.
- Verificación de Alcance: Asegurar que la solicitud cae dentro de los servicios contratados, documentando la autorización para proceder si fuera necesario.
Fase 2: Preparación y Documentación
- Compleción de Información: Verificar que se cuenta con toda la información necesaria para el soporte.
- Información Adicional: Documentar datos relevantes sobre configuraciones específicas requeridas.
Fase 3: Procesamiento y Asignación
- Unicidad del Ticket: Evitar duplicidades manteniendo el primer ticket abierto como referencia.
- Asignación a Soporte Técnico: Derivar el ticket al equipo de soporte técnico correspondiente.
Fase 4: Diagnostico
En caso de detectarse manipulaciones indebidas, como alteraciones en la base de datos o modificaciones no autorizadas, se seguirá el siguiente protocolo:
- Diagnóstico: Durante cualquier fase, si se detecta una manipulación indebida, se procede con el diagnóstico detallado.
- Documentación Detallada: Registrar en el ticket la naturaleza específica de la manipulación.
- Notificación al Área Comercial: Informar al área comercial con evidencia sobre la manipulación detectada.
- Comunicación al Cliente: Notificar al cliente sobre la detección, explicando las implicaciones y el cobro adicional por el servicio.
- Aprobación del Cliente: Obtener la aprobación del cliente para el cobro correspondiente.
- Facturación y Pago: Proceder con la facturación y confirmar el pago por los servicios adicionales.
- Reanudación del Soporte: Una vez resuelto el asunto de manipulación y confirmado el pago, el ticket se envía de nuevo al soporte técnico para su continuación o cierre.
Fase 5: Pruebas y Resolución
- Realización de Pruebas: Llevar a cabo pruebas y documentar los resultados obtenidos.
- Verificación Post-Soporte Técnico: Confirmar la correcta funcionalidad tras las correcciones. Retornar a desarrollo si persisten errores.
Fase 6: Cierre
- Estado Resuelto: Marcar el ticket como resuelto tras confirmar la satisfacción en las pruebas.
No.2
Nombre: Emisión de documentos electrónicos.
Tipo: Bug / Problema
Categoría: Documentos Electrónicos
Diagrama: https://www.drafty.pro/editor/8942ec43-7950-4419-841d-9bdcea3c6e35
1. Verificación Inicial
Verificar Cliente Activo: Confirmar que el cliente tenga un estado activo y esté al día en pagos.
Revisión de Base de Errores: Comprobar si el problema reportado ya está documentado en nuestra base de errores conocidos.
Configuración de Impuestos y Diarios: Verificar la correcta configuración de los impuestos y los registros contables.
Información Completa: Asegurarse de que todos los detalles necesarios para el soporte técnico estén completos y correctamente proporcionados.
2. Procesamiento del Ticket
Manejo de Múltiples Números: Si el cliente proporciona varios números, informar que se realizará una prueba con un solo documento electrónico.
Unicidad del Ticket: Confirmar que no haya duplicidad de tickets para el mismo problema. En caso afirmativo, cancelar los tickets duplicados, manteniendo solo el más antiguo.
Es importante si en el ticket más reciente o recientes contiene información nueva, añadirlo al más antiguo en la parte de notas internas.
Preparación de Datos: Verificar que el XML necesario esté disponible en Odoo15 y prepararlo para el soporte técnico.
3. Comunicación con Facturatech (O proveedor tecnológico del caso)
Creación de Ticket en Facturatech: Generar un ticket para Facturatech para determinar si el problema necesita desarrollo.
Documentación del Problema: Registrar detalladamente el problema y cualquier solución propuesta en las notas del área de desarrollo.
Asignación a soporte técnico: Transferir el ticket a soporte técnico para su análisis y resolución.
4. Resolución y Cierre
Envío de Documento Electrónico: Proceder al envío del documento electrónico para su validación.
Solicitar previamente la autorización del solicitante para el envío del documento relacionado, garantizando así la solución y protegiéndonos frente a posibles reclamaciones futuras al ser nosotros los emisores.
- Cierre del Ticket: Cambiar el estado del ticket a resuelto tras la correcta emisión y recepción del documento electrónico.
No.3 Nombre: Instalaciones y actualizaciones
Tipo: Solicitud
Categoría: Módulos
Diagrama: https://www.drafty.pro/editor/8f5322fa-1869-4e08-b391-9f2f0f5cd36d
Para gestionar eficientemente los tickets de soporte técnico en las categorías de instalaciones y actualizaciones con prioridad media (considerando que la prioridad alta se asigna cuando el cliente está por realizar una puesta en vivo o cuando una actualización obstaculiza la generación de documentos electrónicos o la operatividad), el proceso se estructurará en varias fases clave: Verificación Inicial, Preparación y Documentación, Procesamiento y Asignación, Pruebas y Resolución, y finalmente, Cierre. Este método estructurado asegura una administración ordenada y efectiva de los tickets desde su inicio hasta su conclusión satisfactoria. A continuación, se presentan las fases detalladas junto con sus pasos específicos:
1. Verificación Inicial
Verificar Estado del Cliente: Asegurarse de que el cliente o clientes estén activos y sin retrasos en facturación.
Verificación de Alcance: Confirmar que el módulo solicitado se encuentre dentro del alcance de servicios del cliente. Si no está dentro del alcance, se debe anotar en el ticket quién autorizó la instalación.
2. Preparación y Documentación
Compleción de Información: Verificar que toda la información necesaria para el soporte técnico esté completa.
Información Adicional: Añadir cualquier información relevante sobre configuraciones o características faltantes o necesarias para la instalación.
3. Procesamiento y Asignación
Unicidad del Ticket: Confirmar que no haya más de un ticket para la misma solicitud de instalación. Los duplicados se cancelarán, manteniendo el ticket más antiguo como referencia.
Asignación a soporte técnico: El ticket se asigna a soporte técnico para la instalación o actualización.
4. Pruebas y Resolución
Realización de Pruebas: Soporte técnico realiza las pruebas necesarias y documenta los resultados en el ticket. Si las pruebas son exitosas, se procede a la siguiente fase.
Verificación Post-soporte tecnico: Tras la devolución del ticket por parte de soporte técnico, se verifica que todo funcione correctamente en las bases de datos afectadas. Si se detectan errores, el ticket se devuelve a desarrollo hasta asegurar su correcto funcionamiento.
5. Cierre
Estado Resuelto: Una vez que todo funciona correctamente y las pruebas son satisfactorias, el ticket se marca como resuelto.
No.4 Nombre: Errores dentro del sistema
Tipo: Bugs
Categoría: Indiferente
Diagrama: https://www.drafty.pro/editor/5a58a82c-9d7c-44f4-938d-6b1ba2f5fb52
Para el proceso de apertura y cierre de tickets de soporte técnico enfocado en la categoría de errores dentro del sistema (BUGS) con prioridad alta, el mapa de procesos se estructura en varias fases clave: Verificación inicial, Documentación y preparación, Asignación y desarrollo, Pruebas y verificación, y Cierre. Este enfoque garantiza un manejo eficiente y ordenado desde la identificación del error hasta su resolución final. A continuación, se detalla cada fase junto con los pasos correspondientes:
1. Verificación Inicial
Estado del Cliente: Confirmar que el cliente esté activo y al día en sus pagos.
Verificación de Alcance: Asegurar que el módulo afectado esté dentro del alcance del cliente. Si no lo está, se debe validar con el área comercial.
2. Documentación y Preparación
Compleción de Información: Verificar que la información necesaria para el soporte técnico esté completa y correctamente detallada.
Información Adicional: Añadir información relevante sobre configuraciones o características específicas que puedan estar faltando o que sean necesarias para entender el error.
3. Asignación y Desarrollo
Unicidad del Ticket: Confirmar que no existan múltiples tickets para el mismo error. En caso de duplicados, se cancelarán los más nuevos, manteniendo el más antiguo como referencia.
Asignación a soporte técnico: El ticket se asigna a soporte técnico para la corrección del error.
4. Pruebas y Verificación
Pruebas por soporte técnico: Una vez que el desarrollo ha abordado el error, se realizan pruebas para verificar la solución. Los resultados se documentan en el ticket.
Verificación Post-Soporte Técnico: Después de recibir el ticket de vuelta del desarrollo, se verifica que la solución funcione correctamente en la base de datos afectada. Si persisten errores, el ticket se devuelve a desarrollo hasta asegurar su corrección total.
5. Cierre
Resolución del Ticket: Cuando se confirma que el error ha sido corregido satisfactoriamente y no hay problemas adicionales, el ticket se marca como resuelto.
No.5 Nombre: Clientes nuevos
Tipo: Solicitud
Categoría: Activación
Diagrama: https://www.drafty.pro/editor/207f9e6f-4cfd-43b5-984f-b4e4ad0192e3
Para el proceso de apertura y cierre de tickets de soporte técnico para clientes nuevos, con prioridad alta, el mapa de procesos se diseñará para asegurar una integración suave y eficaz del cliente al sistema. Este mapa se organizará en varias fases clave: Inicio y Verificación, Documentación y Preparación, Asignación y Soporte técnico, Pruebas y Verificación, y Cierre. Cada fase se detalla a continuación con sus pasos correspondientes:
1. Inicio y Verificación
Estado del Cliente: Confirmar que el cliente esté activo y sin retrasos en facturación.
Definición de Alcance: Añadir al ticket el alcance para el cliente, incluyendo los módulos a los que tendrá acceso y cualquier módulo adicional que se desarrollará. Si hay enlaces o descargas para los módulos, también se incluirán. La url que se espera activar.
2. Documentación y Preparación
Usuarios y Accesos: Verificar la necesidad de agregar usuarios en git y en el acceso de Odoo, incluyendo sus nombres y cualquier prueba pertinente.
Inclusión de Versión: Especificar la versión del software o sistema con el que el cliente trabajará.
Información Adicional: Documentar cualquier configuración o característica relevante que esté presente o que falte, necesaria para la instalación o integración.
3. Asignación y Soporte técnico
Unicidad del Ticket: Asegurar que no existan múltiples tickets para la misma solicitud de instalación. Los tickets duplicados se cancelarán, referenciando el ticket más antiguo.
Asignación a Soporte técnico: El ticket se asigna al equipo de soporte técnico para proceder con la configuración e integración necesaria para el cliente nuevo.
4. Pruebas y Verificación
Verificación Post-Soporte técnico: Una vez que el soporte técnico haya completado el trabajo y devuelto el ticket, se realizará una verificación para asegurar que todo funcione correctamente en la base de datos afectada. Cualquier error detectado se reportará de nuevo a soporte técnico para su corrección.
5. Cierre
Resolución del Ticket: Tras confirmar que todas las integraciones y configuraciones funcionan correctamente y cumplen con los requisitos del cliente, el ticket se marca como resuelto.
No.6 Nombre: Bajar Base
Tipo: Solicitud
Categoría: Bajar Base / Suspensión
Diagrama: https://www.drafty.pro/editor/f3e7b722-fe32-41a1-8bb1-807cb4b2e2d5
Para el proceso de apertura y cierre de tickets de soporte técnico en la categoría de bajar bases, con prioridad baja, el mapa de procesos se diseñará para garantizar un manejo adecuado y eficiente de las situaciones donde se requiere dar de baja bases debido a la falta de pago o por otras razones comerciales. Este mapa se organiza en fases claras: Inicio y Verificación, Comunicación Comercial, Documentación, Asignación y Resolución, y Cierre. A continuación, se detallan estas fases y sus pasos correspondientes:
1. Inicio y Verificación
Verificación Administrativa: El área administrativa verifica que no se haya realizado el pago durante un número específico de días.
Si se trata de una suspensión el área administrativa, debe crear la tarea programada de informar a los 7 dias de la baja, al solicitante que después de este día, se procede a cancelación definitiva y las consecuencias descritas en los términos y condiciones.
2. Comunicación Comercial
Asignación al Área Comercial: El ticket se asigna al área comercial para entender los motivos detrás de la falta de pago o la solicitud de baja.
Independientemente del canal de distribución, ya sea directo o indirecto, es crucial documentar la razón de la baja tanto en el ticket correspondiente como en el registro de la suscripción. Esta información es esencial para comprender mejor el comportamiento del cliente y para el desarrollo de estrategias futuras.
En lo que respecta al nivel de negociación y el esfuerzo comercial requerido para prevenir bajas, se aborda detalladamente en un capítulo específico dentro del manual comercial.
Registro de Motivos: El área comercial documenta en las notas del ticket el motivo de la baja, incluyendo detalles relevantes como el nombre del cliente, pruebas si las hay, y la URL relevante.
3. Asignación y Resolución
Asignación a soporte técnico: Tras recoger toda la información necesaria y entender los motivos de la baja, el ticket se asigna al equipo de soporte técnico.
Resolución por soporte técnico: El equipo de desarrollo procede con las acciones necesarias para dar de baja las bases, ajustando los sistemas según sea necesario.
4. Cierre
Cierre del Ticket: Una vez que el proceso de dar de baja las bases está completo y todas las partes involucradas han sido debidamente informadas, el ticket se pasa a estado resuelto.
Este proceso asegura que las solicitudes de baja de bases se manejen de manera organizada y eficiente, con una comunicación clara entre los departamentos administrativos, comerciales y de desarrollo. El objetivo es asegurar que se comprendan completamente los motivos detrás de la solicitud de baja y que el proceso se ejecute de manera que se mantenga la integridad de los datos y se minimicen las interrupciones para el cliente.
No.7 Nombre: Ambiente de pruebas
Tipo: Solicitud
Categoría: Ambiente de pruebas
Diagrama:
Para el proceso de apertura y cierre de tickets de soporte técnico en la categoría de ambientes de prueba, con prioridad baja, se estructurará un mapa de procesos enfocado en garantizar que los clientes puedan tener acceso y usar eficientemente los ambientes de prueba dentro del primer mes de servicio. Este mapa se dividirá en fases claras: Verificación inicial, Documentación, Asignación y Resolución, y Cierre. A continuación, se detallan estas fases con sus pasos correspondientes:
1. Verificación Inicial
Estado del Cliente: Confirmar que el cliente esté activo y al día en sus pagos.
Período de Prueba: Verificar que el cliente esté dentro del primer mes de servicio, periodo durante el cual puede solicitar ambientes de prueba sino pasar al área comercial.
Brindar la alternativa del ambiente de pruebas comunal.
2. Documentación
Información del Cliente: Asegurar que el ticket incluya el nombre del cliente.
Causa del Ambiente de Pruebas: Documentar la razón o causa por la cual el cliente solicita el ambiente de pruebas.
3. Asignación y Resolución
Unicidad del Ticket: Verificar que no haya más de un ticket para la misma solicitud de instalación de ambiente de pruebas. En caso de duplicados, se cancelarán los más nuevos, manteniendo el más antiguo como referencia.
Asignación a soporte técnico: El ticket se asigna al equipo de soporte técnico para configurar y proporcionar el ambiente de pruebas solicitado.
Disponemos de tres escenarios para la creación de bases de prueba: Enterprise y Community.
Enterprise: Dentro de Enterprise, ofrecemos dos modalidades: SaaS y SH. En ambos casos, la creación de bases de prueba se realizará sin costo para el cliente. Además, proporcionaremos un manual para que el cliente pueda, en el futuro, autogestionar la creación de bases de prueba de manera más eficiente.
Community: Para los clientes que utilizan FullAppSuite en la modalidad Community, se facilitará la creación de una única base de prueba según sus necesidades. Es importante mencionar que, si ya existe una base de prueba vigente y se solicita una nueva, el área de soporte técnico procederá a eliminar la anterior y crear una nueva basada en la versión más reciente de la producción. Este proceso está disponible únicamente durante el horario nocturno del cliente, para minimizar cualquier posible interrupción en sus operaciones.
Community: Para los demás clientes, deberán pagar el costo del servicio el tiempo que deseen, esta información se encuentra expuesta en los términos y condiciones de navegasoft.com/terms
4. Cierre
Resolución del Ticket: Una vez que el ambiente de prueba ha sido configurado y se ha proporcionado acceso al cliente, el ticket se marca como resuelto.
Este proceso está diseñado para manejar de manera eficiente y efectiva las solicitudes de ambientes de prueba, asegurando que los clientes puedan comenzar a utilizar los servicios de manera satisfactoria desde el principio. Al mantener un registro detallado y asegurarse de que cada solicitud se procese adecuadamente, se facilita una experiencia positiva para el cliente y se mejora la calidad del servicio de soporte técnico.
Incidencias no registradas
En caso de que se identifiquen nuevos tipos de incidencias que se presenten con frecuencia o requieran de un proceso específico, es fundamental comunicar esta información mediante las notas de este manual al Gestor de Calidad. Esto asegurará su inclusión adecuada y la actualización correspondiente del manual.
3.5 Escalación de Incidentes
Si el nivel actual de soporte no puede resolver el incidente, este se escala al siguiente nivel.
|
Tipo |
Primera Línea |
Escalar a |
Escalar a |
|
Problema |
Nivel 1 |
Nivel 2 |
Nivel 3 |
|
Pregunta |
Nivel 1 |
Nivel 2 |
N/A |
|
Anomalía |
Nivel 1 |
Nivel 3 |
N/A |
|
Bugs |
Nivel 1 |
Nivel 3 |
N/A |
|
Solicitud |
Nivel 1 |
Al área correspondiente |
N/A |
|
Usabilidad |
Nivel 1 |
Área de proyectos |
N/A |
Comunicación fallida
En caso de que la solicitud escalada no obtenga respuesta del nivel correspondiente en un tiempo razonable, considerando nuestra configuración de equipo dinámico que opera en distintas franjas horarias, con un plazo máximo de 24 horas para actualizaciones sobre el estado, fechas estimadas o retorno del ticket, procederemos a contactar directamente a la persona asignada a través del WhatsApp corporativo. Si esta acción no resulta en una respuesta, la situación se escalará al líder de proyectos. De no obtener respuesta de este último en un plazo adicional de 12 horas, el siguiente paso será escalar al líder de operaciones.
Para los tickets de prioridad urgente, se asignarán de inmediato al rol correspondiente, pero también se notificará la situación a través de WhatsApp al número de emergencia disponible 24/7.
Si el avance del ticket se ve obstaculizado por la falta de información por parte del solicitante, y no se recibe respuesta al día siguiente, se hará un seguimiento marcando al número vía Zadarma. Es importante minimizar la comunicación vía WhatsApp. Si después de dos intentos no se obtiene respuesta, el caso se deberá escalar al área comercial para solicitar más datos de contacto. Es crucial dejar constancia de estas acciones en el registro del tiquet.
3.6 Procedimientos para la documentación de problemas
Es importante documentar los problemas que se resuelven para que se puedan aprender de ellos y evitar que vuelvan a ocurrir. Los analistas deben documentar los problemas por medio de un video o PDF, el cual debe ser publicado en la página WEB de Navegasoft en el apartado de preguntas frecuentes de la siguiente manera:
Describir el problema. El analista debe describir el problema de forma clara y concisa.
Proporcionar una solución. El analista debe proporcionar una solución al problema.
Agregar información adicional. El analista puede agregar información adicional que sea relevante, como los pasos para reproducir el problema, los mensajes de error que se producen o cualquier otra información que pueda ser útil.
Al crear esta documentación, si se necesita utilizar datos basados en información de un cliente, es crucial ocultar o anonimizar cualquier información sensible para asegurar que no se reconozca ningún dato personal o confidencial del cliente.
3.7 Procedimientos para la comunicación con los usuarios
La comunicación con los usuarios es una parte importante del proceso de soporte analista. Los analistas deben comunicarse con los usuarios de forma clara, concisa y profesional. Los analistas deben seguir los siguientes consejos para comunicarse con los usuarios:
Sea amable y comprensivo. Los usuarios pueden estar frustrados o molestos cuando tienen un problema. Es importante ser amable y comprensivo con ellos.
Sea claro y conciso. Los usuarios pueden no estar familiarizados con la terminología técnica. Es importante usar un lenguaje claro y conciso que ellos puedan entender.
Sea proactivo. Los analistas deben mantener a los usuarios informados sobre el progreso de la resolución del problema.
Una vez resuelto el incidente, el tique se deberá cambiar de estado el tique a Resuelto o En Proceso del Cliente.
Los analistas de soporte analista deben siempre informar al usuario del estado de su solicitud, incluso si el tique se ha cerrado, indicando si el problema fue resuelto o enviando la respuesta de este.
3.7 Procedimientos para los tiques que van al área de desarrollo
Aclaración
El área de desarrollo se distingue del soporte técnico en varias facetas clave. Mientras que el soporte técnico se concentra en resolver incidencias de impacto crítico y alto, además de gestionar procesos cotidianos, el área de desarrollo se enfoca en la creación y mejora de productos para nuestros clientes, basándose en proyectos específicos. Los tiques generados por soporte técnico se convierten en valiosos insumos para identificar oportunidades de mejora en nuestros productos o en los procesos organizacionales, alineándose con nuestra filosofía de mejora continua.
Debido a esta distinción fundamental en roles y responsabilidades, se dedica un capítulo independiente a la gestión de desarrollo dentro de nuestro manual. Esto asegura que las actividades de desarrollo se planifiquen y ejecuten de manera organizada, con presupuestos y tiempos asignados específicamente para cada proyecto. Esta estructura no solo refleja la importancia estratégica del área de desarrollo, sino que también facilita una colaboración efectiva entre soporte técnico y desarrollo, impulsando la innovación continua y el enriquecimiento de nuestros productos y servicios.
Establece un flujo de trabajo claro que permite evaluar, priorizar y asignar tareas de manera efectiva. Este proceso es lo suficientemente flexible para adaptarse a las distintas fuentes de requerimientos (Tipo: bugs, usabilidad / Categorías: Oportunidades de mejora, Garantías) y a las diferentes opciones de solución (desarrollo interno, externalización, compra o uso de apps existentes, studio, ajustes mediante herramientas específicas o descarte de la necesidad de desarrollo).
Fases:
Fase 1. Recepción y Registro de Requerimientos
- Canal único de recepción:
Proceso Unificado de Recepción y Registro de Requerimientos
1. Recepción de Requerimientos:
- Canal Único: Uso del sistema de tiques como el punto único de entrada para todos los requerimientos, independientemente de su origen (Categorías: Clientes, Interno, Auditoría, etc.).
- Formulario de Registro: Estandarización en el sistema de tiques que capture información esencial del requerimiento, como:
- Descripción detallada del problema o solicitud.
- Categorías:
Módulos.
Proceso.
Origen.
- Impacto potencial o beneficio esperado.
- Cualquier información adicional relevante (por ejemplo, pasos para reproducir un bug).
2. Clasificación Inicial:
- Al recibir un tique el área de soporte realiza una clasificación inicial para determinar su tipo es un bug, una anomalía, un problema y su categoría; una garantía, una oportunidad de mejora (Incluyen las solicitudes de nuevas funciones, o migraciones de funciones que solo están presentes en versiones diferentes al del solicitante).
- Esta clasificación ayuda a priorizar y dirigir el tique al flujo de trabajo adecuado.
3. Conversión o Copia en Tarea:
- Bugs y Garantías: Si el tique es un bug o una garantía, se mantiene en el sistema de tiques para su seguimiento y comunicación con el cliente. Cuando se decide desarrollar una solución, se crea una tarea relacionada en el sistema de gestión de proyectos (manteniendo una referencia al tique original) para su ejecución.
- Oportunidad de mejora: Si el tique representa una oportunidad de mejora, y tras una evaluación preliminar se aprueba para el desarrollo, se convierte en una tarea dentro del proyecto del cliente o en el proyecto de Mejora Continua”, según corresponda.
4. Comunicación y Seguimiento:
- Mantener una comunicación constante con el solicitante, proporcionando actualizaciones sobre el estado de su requerimiento, desde la recepción hasta la resolución.
Fase 2. Evaluación Preliminar
Formación y Operación del Comité de Evaluación
Formación del Comité:
- Composición: Formar un comité de evaluación con representantes de diversas áreas (líder de desarrollo, líder de proyectos, líder de soporte, y un líder funcional). Este comité debería tener la autoridad para tomar decisiones informadas sobre los requerimientos.
- Frecuencia de Reuniones: Se realizará cada 5 tiques, esto específicamente para los que están en las categorías de oportunidad de mejora y /o en los tipos de usabilidad.
El analista de soporte nivel 1, deberá llevar el conteo y una vez se tengan los requeridos se informará al líder de proyectos, para convocar la sesión.
Operación del Comité:
- Revisión de Tiques: En cada reunión, el comité revisa los tiques clasificados durante el periodo anterior, discutiendo su viabilidad, impacto, urgencia, y la mejor ruta de acción.
- Criterios de Evaluación: Utilizar criterios preestablecidos para evaluar cada tiquet, como:
- Impacto en el negocio o en el usuario final.
- Recursos necesarios para la implementación.
- Tiempo estimado de desarrollo.
- Compatibilidad con la hoja de ruta de desarrollo del producto.
- Decisión: Tomar decisiones sobre si proceder con el desarrollo, rechazar la solicitud, buscar una solución alternativa, o necesitar más información.
- Documentación: Registrar las decisiones del comité, incluyendo la justificación y los pasos a seguir, para mantener la transparencia y facilitar la comunicación con los interesados.
Ejemplo de Evaluación:
- Tique: Solicitud de nueva función que permita la integración con una plataforma externa.
- Evaluación: El comité discute el impacto potencial de esta integración en la eficiencia operativa, el posible aumento de satisfacción del cliente, y los recursos necesarios para la implementación.
- Decisión: Aprobar el desarrollo de la integración, asignando la tarea a un equipo interno con experiencia en integraciones de terceros, y establecer un plazo para la revisión de progreso.
Este enfoque estructurado no solo ayuda a gestionar los requerimientos de manera eficiente, sino que también asegura que las decisiones se tomen con una visión completa del impacto en el negocio y los recursos disponibles.
Fase 3. Clasificación y Priorización
- Matriz de decisión: Se utilizará una matriz para decidir si el requerimiento debe ser desarrollado internamente, externalizado, se puede comprar una solución ya existente, usar apps de la comunidad, o si puede ser resuelto con herramientas existentes sin desarrollo adicional.
- Priorización: Priorizar los requerimientos basándote en criterios como urgencia, impacto en el negocio, y recursos requeridos.
Matriz de Decisión para Requerimientos
La matriz se divide en cuatro cuadrantes basados en el impacto en el negocio (Eje Y) y la complejidad técnica (Eje X). Cada cuadrante sugiere una ruta de acción preferente para los requerimientos que caen dentro de su área.
Aunque el término "complejidad" se utiliza con frecuencia, es importante reconocer que cada proyecto o tarea, independientemente de su tamaño, conlleva su propia complejidad. Cuando hablamos de "baja" o "alta" complejidad, no nos referimos necesariamente a la dificultad inherente de las tareas, sino al tiempo estimado que se requerirá para su completación. En nuestra organización, definimos un proyecto de "baja complejidad" como aquel que se puede completar en menos de 8 horas y uno de "alta complejidad" como aquel que requiere más de 8 horas de trabajo. Esta distinción nos permite planificar y asignar recursos de manera más efectiva, asegurando una gestión eficiente del tiempo y una distribución adecuada de la carga de trabajo.
Cuadrantes:
1. Alto Impacto, Baja Complejidad (Desarrollo Interno):
- Acción Sugerida: Priorizar para desarrollo interno. Estos proyectos ofrecen un gran valor con un esfuerzo relativamente bajo, ideal para el equipo interno.
- Ejemplo: Implementación de una función solicitada frecuentemente por los usuarios que requiere cambios mínimos en el código existente.
2. Alto Impacto, Alta Complejidad (Externalización):
- Acción Sugerida: Considerar la externalización o colaboración con socios. Dado su alto valor y complejidad, pueden requerir habilidades especializadas o recursos que no están disponibles internamente.
- Ejemplo: Integración con una nueva plataforma de tecnología financiera que requiere conocimiento especializado en seguridad y cumplimiento.
3. Bajo Impacto, Baja Complejidad (Menú Técnico / Apps de la Comunidad / Studio):
- Acción Sugerida: Resolver con herramientas existentes o apps de la comunidad. Estos no justifican el desarrollo desde cero debido a su bajo impacto.
- Ejemplo: Mejoras menores en la interfaz de usuario que pueden ajustarse con herramientas de diseño sin codificación.
4. Bajo Impacto, Alta Complejidad (Reevaluar / No Proceder):
- Acción Sugerida: Puede no ser prudente proceder. Requieren una inversión significativa para un retorno limitado. Reevaluar la necesidad o buscar alternativas más viables.
- Ejemplo: Creación de una característica novedosa que solo unos pocos usuarios utilizarían y que requeriría una reestructuración amplia del sistema existente.
Ejemplo de Matriz de Decisión
|
Impacto / Complejidad |
Baja Complejidad |
Alta Complejidad |
|
Alto Impacto |
Desarrollo Interno |
Externalización |
|
Bajo Impacto |
Menú Técnico / Apps |
Reevaluar / No proceder |
Uso de la Matriz:
- Al recibir un nuevo requerimiento, evalúa primero su impacto potencial en el negocio y luego determina su complejidad técnica.
Al evaluar el impacto, nuestra guía principal será la legalidad, otorgando máxima prioridad a todo lo concerniente a los documentos electrónicos y aspectos relacionados, tales como la emisión de folios y su fácil gestión. Además, en casos donde un motivo de ticket se identifique como recurrente, nuestro enfoque será minimizarlo o resolverlo definitivamente, con el objetivo de reducir la necesidad de asistencia futura y solucionar el problema de manera definitiva.
- Sitúa el requerimiento dentro de la matriz para determinar la acción recomendada. De forma complementaria, el sistema de tiquets preclasificará automáticamente los tickets según los criterios seleccionados y categorizados por el analista, como son el tipo, las categorías y la prioridad. Esto facilita una identificación más precisa y oportuna para el comité de revisión, aprovechando la funcionalidad del acuerdo de nivel de servicio (SLA).
- Considera cualquier factor adicional que pueda influir en la decisión, como limitaciones de tiempo, presupuesto, o recursos humanos. Sin embargo, una vez calificada en base a la liberación de recursos se mandarán a la cola de desarrollo o ejecución.