Cómo un proveedor de servicios hizo su Service Desk

Hola a todos! Me llamo Alexey Volkov. Junto con mi colega, el desarrollador Alexander Solovyov ( tambiénv ), realizamos servicios web internos en DataLine. Este otoño, lanzamos nuestra mesa de servicio para reemplazar BMC Remedy. En una publicación, le diré por qué rechazamos una solución preparada e hicimos todo nosotros mismos.


En promedio, 450 aplicaciones pasan por la mesa de servicio por día.

¿Qué no nos complació Remedy?


Comencé a practicar Remedy casi de inmediato cuando ingresé a DataLine. Después de repetidos intentos de terminarlo bajo nuestras tareas, decidimos hacer nuestra mesa de servicio. Aquí hay una lista no tan breve de las razones por las que decidimos abandonar el Sistema de Solicitud de Acción de Remedio de BMC:

Interfaz incómoda. Para registrar una aplicación, llévela al trabajo y tenga en cuenta su permiso, tuvimos que hacer 100500 clics.


Página con el incidente. Tome al menos los campos para el contenido del mensaje que debía abrirse en una ventana especial.


Es necesario abrir una cascada completa de pestañas para escribir una solución o redirigir el incidente a otro ejecutor.

La integración con otras interfaces de cliente y cualquier mejora sugerida incluso aquellos bailes con una pandereta. Software propietario, casi no había espacio para maniobrar. Las únicas lagunas eran los servicios web que sabían comunicarse con Remedy, pero eran muy malhumorados e inestables. Hicimos algunas cosas de forma completamente manual y torpe: recuerdo cómo configuramos la carga de informes sobre incidentes con la ayuda de selecciones de la base de datos.

Por supuesto, había otra forma: contratar a un contratista y cumplir cualquier capricho. En ese momento solo había un contratista en el mercado para este software, y él lo sabía. Los procesos de producción se están ajustando, y las mejoras serían constantemente necesarias. Con esto en mente, el precio resultó inhumano y comenzó en 5 millones.

No hay suficientes licencias. Una vez en los albores de DataLine, compramos 100 licencias. Desde entonces, la compañía ha crecido exponencialmente. Las licencias estaban compitiendo. Cada vez más, surgieron situaciones en que un ingeniero tuvo que esperar a que se liberara la licencia para comenzar a hacer su trabajo. En realidad, esta fue la gota que colmó el vaso.

Arreglando todas las acciones del incidente . Queríamos que todo lo relacionado con el soporte técnico de nuestros clientes se reflejara en la mesa de servicio. Remedio, de hecho, solo registra las solicitudes. Todo el trabajo real sobre el incidente se realizó por correo postal, por teléfono, en la sala de fumadores, en cualquier lugar, pero no en Remedy. Especialmente si se trataba de una aplicación compleja e involucraba especialistas de varios departamentos. Resolvieron el problema, pero no había rastro de esto en Remedy. Como resultado, el incidente se documentó en fragmentos y, a veces, no apareció en absoluto en Remedy. Fue muy difícil controlar, comprender y analizar cualquier cosa.

Service Desk 2.0


Las funciones de remedio fueron fáciles de reemplazar. La tarea principal de la nueva mesa de servicio es arrastrar toda la actividad de soporte técnico a la "ventana única": contactos, correspondencia de trabajo, documentos. Queríamos obtener una especie de registro de todo lo que sucede después de que un cliente nos envía una aplicación para recibir asistencia. En el camino, queríamos automatizar muchas cosas para reducir la carga en la primera línea de soporte y eliminar al máximo el factor humano.

Estas son las funciones más importantes que implementamos en la nueva mesa de servicio:

Transferencia incidente. A menudo recibimos aplicaciones complejas, que se llevan a cabo en una cadena por especialistas de diferentes departamentos. De las más simples, una aplicación para acceso físico a equipos en un centro de datos. Primero, el despachador escribe un pase, luego pasa los datos del cliente y el número de pase al ingeniero de turno que se encuentra y acompaña al cliente en el centro de datos. Hay solicitudes que constantemente resuelven 5 departamentos.
Para todos estos casos, un botón separado "Enviar" apareció en la interfaz.



Correspondencia con un cliente y colegas. Esta función es solo para garantizar que la correspondencia sobre el incidente no "se filtre" en el correo y que se mantenga con nosotros todo el historial de comunicación.

Hasta ahora, todo es muy minimalista. Los planes son hacer un editor de texto completo con la capacidad de descargar archivos, tablas, etc.



Un historial de citas y un historial de todas las actividades de incidentes. Estas pestañas lo ayudan a resolver problemas polémicos e investigaciones internas. En este momento, estoy descargando informes del historial para controlar la frecuencia con la que los despachadores cometen errores al asignar un incidente a un grupo de perfiles.



Esta es la historia de las citas para el incidente interno "Despido de un empleado".


Historial de incidentes. Aquí todavía traeremos belleza, pero la tarea principal ya está resuelta: todo está registrado.

Observador Sucede que en una carta de solicitud, el cliente sujeta una copia de las personas interesadas en una copia. Todos estos camaradas aparecerán en la pestaña "Observadores" y supervisarán la ejecución de esta aplicación. Recibirán información sobre el estado de la solicitud, si lo desean, podrán comunicarse con nuestro soporte técnico. Dentro de la empresa, esta función también es muy solicitada: los gerentes de servicio pueden adaptarse a cualquier solicitud de su cliente y controlar su ejecución.
La lista de observadores se puede editar: eliminar y agregar nuevos.



Patrones de incidentes. Hay muchas consultas típicas. Para no completar una solicitud de pase o limpieza de basura docenas de veces al día, agregamos la posibilidad de crear plantillas de incidentes. Solo tiene que hacer clic en el botón "Crear incidente" y se abrirá una plantilla rellenada previamente con el ejecutor prescrito, el tipo, la prioridad y el estado.

Hay muchas aplicaciones recurrentes en el trabajo de los centros de datos: rondas, pruebas, verificaciones de equipos de ingeniería de acuerdo con las listas de verificación, etc. Para todo esto, se configuran los incidentes automáticos, que caen automáticamente en el rastreador con una frecuencia determinada.



Analítica No había herramientas analíticas integradas en Remedy, no se podía descargar nada con las herramientas normales. Aquí proporcionamos la descarga de todo y todo para su posterior análisis. Por ejemplo:

  • la cantidad de solicitudes por día;
  • velocidad de respuesta;
  • retrasos en las solicitudes;
  • tipos de solicitudes;
  • carga por departamentos;
  • los despachadores trabajan;
  • frecuencia y calidad de los problemas emergentes en el contexto de los clientes;
  • varias dependencias, por ejemplo, velocidad de ejecución en el tipo de solicitud.

Un poco más tarde, queremos hacer paneles con cuadros y gráficos, para que sin ninguna descarga y brujería en Excel obtengamos una imagen de lo que está sucediendo en el soporte técnico.


Los informes se pueden generar directamente en la mesa de servicio mediante filtros.


Descarga de datos en varios formatos.


Puede seleccionar los campos que se mostrarán en la carga.

API para integración con otros servicios internos. De una manera simple: la mesa de servicio extrae información de directorios con una lista de empresas clientes, contratos, una lista de servicios solicitados y personas responsables que pueden enviar solicitudes. Anteriormente, primero tenía que verificar con un archivo separado para determinar si el escritor es un cliente y si puede escribir solicitudes de la compañía.

El "Desvío de turno en servicio" es otro de nuestros servicios internos, con el que el servicio de atención al cliente ahora puede interactuar. Esta es una lista de verificación electrónica, en la cual los oficiales de servicio y los ingenieros de mantenimiento inspeccionan los centros de datos varias veces al día en busca de averías y desórdenes. Una situación para un ejemplo: durante un desvío, el asistente tropezó con el escritorio de un cliente con equipo instalado incorrectamente. Simplemente hace una nota correspondiente en el programa Bypass, y un incidente sobre el problema llega automáticamente a la mesa de servicio. El asistente va más allá en la ruta de derivación y el problema con la recepción ya está comenzando a resolverse.


Se puede crear un incidente para cualquiera de los elementos de la lista de verificación.


Un formulario para un incidente dentro del software Bypass. Por encima de colgar incidentes en el trabajo sobre el mismo objeto.

Sobre las pequeñas cosas. Todos los tipos de solicitudes más comunes que mostramos en la página de la interfaz. Después de elegir una prioridad, el usuario ve la fecha límite y la barra de progreso, que muestra cuánto tiempo le queda para ejecutar el incidente.



Implementación


Durante la operación de prueba, probamos el escritorio de trabajo en aplicaciones internas. Aproximadamente un mes se capacitaron en los departamentos de AXO, construcción de capital, producción y gestión de servicios. Las aplicaciones externas y las aplicaciones de otros departamentos continuaron pasando por Remedy.

Luego acordamos con tres clientes para ejecutar el procesamiento de aplicaciones externas. Aquí es donde sucedieron los primeros problemas.

Cuando recién comenzaron a crear un nuevo servicio de atención al cliente, tenía la esperanza de que nuestro analizador de correo inteligente pudiera registrar solicitudes, distribuirlas a través de departamentos especializados, archivar mensajes sobre el mismo problema en un incidente. En el futuro, esto significó el abandono de los despachadores en el procesamiento de solicitudes por escrito. En Remedy, la gente está muy acostumbrada a confiar en la correspondencia por correo; había más de lo que esperábamos. El analizador falló en las pruebas de prueba: podría confundir los departamentos al hacer una solicitud, registró nuevos mensajes en un incidente ya abierto como nuevos incidentes. Hubo dificultades más triviales: el analizador no podía leer la carta que venía del correo con el certificado; No entendí la codificación no estándar y envié el texto de las preguntas.

Tuve que agregar trabajo manual: apareció una sala de control. Este es un purgatorio para todas las aplicaciones que llegaron a support@dtln.ru . A partir de ahí, los despachadores distribuyen manualmente las aplicaciones por departamento.



Del lado del cliente, la lógica de interacción con el soporte técnico ha permanecido igual, solo ha cambiado la apariencia de los ritmos. En los primeros días, hubo varias superposiciones con ellos, principalmente debido a detalles de contacto incorrectos en los directorios. Entonces, uno de los clientes tenía 23 personas responsables y todos tenían un correo electrónico común, como info @. El servicio técnico notificó obedientemente a todos, cumpliendo la tarifa diaria durante una hora entrando en este buzón.

Que sigue


En un futuro cercano: integración con Mi cuenta . Toda la correspondencia y el historial de contactos se mostrarán en el perfil del cliente. Teóricamente, esta es una oportunidad para excluir el correo de la comunicación con el soporte técnico y finalmente arrastrar al cliente a nuestra interfaz web. Veamos cómo se arraiga en la vida.

Implementación de una aplicación parametrizada . Hay consultas que contienen muchos parámetros y valores, y es importante no mezclar nada en ellas. Por ejemplo, cuando un cliente solicita agregar recursos virtuales al grupo o crear máquinas virtuales de ciertos tamaños. Para tales casos, planeamos hacer un constructor con parámetros. Analizará automáticamente las solicitudes de clientes recibidas por correo. Será utilizado por los despachadores al aceptar solicitudes por teléfono.


Así es como se ve un orden parametrizado.

Evaluación de soporte técnico. El notorio "califica nuestro servicio en una escala de cinco puntos" con la capacidad de escribir en forma gratuita, todo lo que el cliente piensa sobre nuestro servicio.

Queremos desarrollar la misma sala de despacho , que surgió como una muleta para ayudar al analizador de correo, en un lugar de trabajo automatizado completo del despachador (AWP) . Ahora el despachador tiene que buscar en varias interfaces (contabilidad de equipos, una lista de personas responsables, servicios al cliente) para recopilar la información necesaria sobre el cliente. Sin embargo, en AWP, todo estará en una ventana: incidentes de clientes, contactos, contratos, servicios solicitados y sus parámetros, etc. datos.

Bueno, no pierda la esperanza de la distribución automática de aplicaciones por departamento . Ahora estamos pensando en un sistema de hashtag para un analizador de correo electrónico.

***
La mesa de servicio ha estado operando en modo de combate desde noviembre, y todo este tiempo he visto un aumento constante en el número de incidentes (+ 40%), principalmente debido a solicitudes internas. Me atrevo a esperar que esto se deba al hecho de que el nuevo servicio de atención al cliente es más amigable en todos los aspectos y las solicitudes dejaron de pasar por alto.

Otro beneficio de la nueva mesa de servicio es la flexibilidad. Ya hemos realizado varias soluciones personalizadas para clientes individuales con el fin de integrarse con sus mesas de servicio internas o simplemente adaptarse a sus procesos de producción. Anteriormente, tomaría meses y millones, pero ahora todo lo que se necesita es una carta a su desarrollador y 1-2 semanas dependiendo de la complejidad de la tarea.

Source: https://habr.com/ru/post/es434178/


All Articles