Olá pessoal! Meu nome é Alexey Volkov. Juntamente com meu colega, desenvolvedor Alexander Solovyov (
alsov ), fazemos serviços Web internos no DataLine. Neste outono, lançamos nossa central de atendimento para substituir o BMC Remedy. Em um post, vou explicar por que recusamos uma solução pronta e fizemos tudo sozinhos.
Em média, 450 aplicativos passam pela central de atendimento por dia.O que Remedy não nos agradou?
Comecei a praticar o Remedy quase imediatamente quando entrei no DataLine. Após repetidas tentativas de concluí-lo em nossas tarefas, decidimos fazer nossa central de atendimento. Aqui está uma lista não tão curta de razões pelas quais decidimos abandonar o Sistema de Solicitação de Ação do Remedy do BMC:
Interface inconveniente. Para registrar um aplicativo, levá-lo ao trabalho e anotar sua permissão, tivemos que fazer 100500 cliques.
Página com o incidente. Pegue pelo menos os campos para o conteúdo da mensagem que precisava ser aberta em uma janela especial.
Uma cascata inteira de guias precisa ser aberta para escrever uma solução ou redirecionar o incidente para outro executor.A integração com outras interfaces do cliente e quaisquer melhorias sugeriram até as danças com um pandeiro. Software proprietário, quase não havia espaço para manobras. As únicas brechas eram os serviços da web que sabiam se comunicar com o Remedy, mas eram muito mal-humorados e instáveis. Fizemos algumas coisas de maneira totalmente manual e desajeitada: lembro como configuramos o upload de relatórios sobre incidentes com a ajuda de seleções do banco de dados.
Obviamente, havia outra maneira: contratar um empreiteiro e cumprir qualquer capricho. Naquela época, havia apenas um contratado no mercado para esse software, e ele sabia disso. Os processos de produção estão sendo ajustados e as melhorias seriam constantemente necessárias. Com isso em mente, o preço acabou desumano e começou em 5 milhões.
Licenças insuficientes. Uma vez no início do DataLine, compramos 100 licenças. Desde então, a empresa cresceu exponencialmente. As licenças estavam competindo. Cada vez mais, surgiam situações em que um engenheiro precisava esperar a liberação da licença para começar a fazer seu trabalho. Na verdade, essa foi a gota d'água.
Corrigindo todas as ações de incidentes . Queríamos que tudo relacionado ao suporte técnico de nossos clientes fosse refletido na central de atendimento. Solução, de fato, apenas solicitações registradas. Todo o trabalho real sobre o incidente foi realizado por correspondência, por telefone, na sala de fumantes - em qualquer lugar, mas não na Remedy. Especialmente se fosse uma aplicação complexa e envolvesse especialistas de vários departamentos. Eles resolveram o problema, mas não havia vestígios disso na Remedy. Como resultado, o incidente foi documentado em fragmentos e, às vezes, não apareceu em Remedy. Foi muito difícil controlar, entender e analisar qualquer coisa.
Service Desk 2.0
As funções do remédio eram fáceis de substituir. A principal tarefa do novo service desk é arrastar toda a atividade de suporte técnico para a “uma janela”: contatos, correspondência de trabalho, documentos. Queríamos obter uma espécie de registro de tudo o que acontece depois que um cliente envia um aplicativo para suporte. Ao longo do caminho, queríamos automatizar muitas coisas para reduzir a carga na primeira linha de suporte e eliminar o fator humano ao máximo.
Aqui estão as funções mais importantes que implementamos no novo service desk:
Incidente de transferência. Frequentemente, recebemos aplicações complexas, realizadas em cadeia por especialistas de diferentes departamentos. Das mais simples, uma aplicação para acesso físico a equipamentos em um data center. Primeiro, o despachante grava um passe e passa os dados do cliente e o número do passe para o engenheiro de serviço que atende e acompanha o cliente no data center. Existem pedidos que elaboram consistentemente 5 departamentos.
Para todos esses casos, um botão "Enviar" separado apareceu na interface.
Correspondência com um cliente e colegas. Essa função serve apenas para garantir que a correspondência sobre o incidente não "vaze" no correio e que todo o histórico de comunicação seja mantido conosco.
Até agora, tudo é muito minimalista. Os planos são criar um editor de texto completo com a capacidade de baixar arquivos, tabelas, etc.
Um histórico de compromissos e um histórico de todas as atividades de incidentes. Essas guias ajudam a resolver problemas controversos e investigações internas. No momento, estou baixando relatórios do histórico para monitorar com que frequência os expedidores cometem erros ao atribuir um incidente a um grupo de perfis.
Esta é a história das nomeações para o incidente interno "Demissão de um funcionário".
Histórico de incidentes. Aqui ainda vamos trazer beleza, mas a tarefa principal já foi resolvida - tudo está registrado.Observador. Ocorre que, em uma carta de solicitação, o cliente prende uma cópia das pessoas interessadas em uma cópia. Todos esses camaradas aparecerão na aba "Observadores" e monitorarão a execução desta aplicação. Eles receberão informações sobre o status da solicitação, se desejarem, poderão corresponder ao nosso suporte técnico. Dentro da empresa, essa função também é requisitada: os gerentes de serviços podem se adequar a qualquer solicitação do cliente e monitorar sua execução.
A lista de observadores pode ser editada: exclua e adicione novos.
Padrões de incidentes. Existem muitas consultas típicas. Para não preencher um pedido de limpeza de passe ou lixo dezenas de vezes por dia, adicionamos a capacidade de criar modelos de incidentes. Você só precisa clicar no botão "Criar incidente", e um modelo pré-preenchido será aberto com o executor, tipo, prioridade e status prescritos.
Existem muitas aplicações recorrentes regularmente no trabalho dos datacenters: rodadas, testes, verificações de equipamentos de engenharia de acordo com listas de verificação, etc. Por tudo isso, são configurados incidentes automáticos, que caem automaticamente no rastreador com uma determinada frequência.
Analytics. Não havia ferramentas analíticas integradas no Remedy, nada podia ser descarregado com ferramentas regulares. Aqui fornecemos o descarregamento de tudo e de tudo para uma análise mais aprofundada. Por exemplo:
- o número de solicitações por dia;
- velocidade de resposta;
- atrasos nas solicitações;
- tipos de pedidos;
- carregamento por departamentos;
- expedidores trabalham;
- frequência e qualidade de problemas emergentes no contexto de clientes;
- várias dependências, por exemplo, velocidade de execução no tipo de solicitação.
Um pouco mais tarde, queremos criar painéis com tabelas e gráficos, para que, sem nenhuma descarga e bruxaria no Excel, tenhamos uma imagem do que está acontecendo no suporte técnico.
Os relatórios podem ser gerados diretamente na central de atendimento usando filtros.
Descarregando dados em vários formatos.
Você pode selecionar os campos que serão exibidos no upload.API para integração com outros serviços internos. De uma simples: a central de atendimento extrai informações dos diretórios com uma lista de empresas clientes, contratos, uma lista de serviços solicitados e pessoas responsáveis que podem enviar solicitações. Antes, era necessário primeiro verificar com um arquivo separado para determinar se o gravador é um cliente e se ele pode gravar solicitações da empresa.
O "desvio de plantão" é outro dos nossos serviços internos, com os quais a central de atendimento agora pode interagir. Esta é uma lista de verificação eletrônica, na qual oficiais de serviço e engenheiros de manutenção inspecionam os data centers várias vezes ao dia em busca de falhas e desordens. Uma situação para um exemplo: durante um desvio, o atendente tropeçou em uma mesa do cliente com equipamento instalado incorretamente. Ele simplesmente faz uma anotação correspondente no programa Bypass, e um incidente no problema chega automaticamente à central de atendimento. O atendente vai mais longe na rota de desvio e o problema com a recepção já está começando a ser resolvido.
Um incidente pode ser criado para qualquer um dos itens da lista de verificação.
Um formulário para um incidente dentro do software Bypass. Acima, pendurar incidentes no trabalho no mesmo objeto.Sobre as pequenas coisas. Todos os tipos mais comuns de solicitações que exibimos na página da interface. Depois de escolher uma prioridade, o usuário vê o prazo e a barra de progresso, mostrando quanto tempo resta para executar o incidente.
Implementação
Durante a operação de teste, testamos a mesa de trabalho em aplicativos internos. Cerca de um mês eles treinaram nos departamentos da AXO, construção de capital, produção e gerenciamento de serviços. Aplicativos externos e aplicativos de outros departamentos continuaram passando pelo Remedy.
Em seguida, concordamos com três clientes para executar o processamento de aplicativos externos. Foi aqui que os primeiros problemas aconteceram.
Quando eles começaram a criar uma nova central de atendimento, acalmei a esperança de que nosso analisador de e-mails inteligentes possa registrar solicitações, dispersá-las por departamentos especializados, arquivar mensagens sobre o mesmo problema em um incidente. No futuro, isso significaria o abandono de despachantes no processamento de solicitações por escrito. Na Remedy, as pessoas estão muito acostumadas a confiar na correspondência; havia mais do que esperávamos. O analisador falhou nos testes de teste: poderia confundir os departamentos ao fazer uma solicitação; ele registrou novas mensagens em um incidente já aberto como novos incidentes. Havia dificuldades mais triviais: o analisador não conseguia ler a carta que vinha do correio com o certificado; Não entendi a codificação não padrão e enviei o texto das perguntas.
Eu tive que adicionar trabalho manual - uma sala de controle apareceu. Este é um purgatório para todos os aplicativos que vieram para
support@dtln.ru . A partir daí, os expedidores distribuem aplicativos manualmente por departamento.
No lado do cliente, a lógica da interação com o suporte técnico permaneceu a mesma, apenas a aparência das batidas mudou. Nos primeiros dias, havia várias sobreposições com eles, principalmente devido a detalhes de contato incorretos nos diretórios. Portanto, um dos clientes tinha 23 pessoas responsáveis e todos tinham um e-mail comum, como info @. A central de atendimento notificou obedientemente a todos, cumprindo a taxa diária por uma hora ao entrar nesta caixa de correio.
O que vem a seguir?
Em um futuro próximo -
integração com Minha conta . Toda a correspondência e o histórico de contatos serão exibidos no perfil do cliente. Teoricamente, essa é uma chance de excluir emails da comunicação com o suporte técnico e, finalmente, arrastar o cliente para a nossa interface da web. Vamos ver como isso se enraíza na vida.
Implementação de uma aplicação parametrizada . Existem consultas que contêm muitos parâmetros e valores, e é importante não misturar nada nelas. Por exemplo, quando um cliente pede para adicionar recursos virtuais ao pool ou criar máquinas virtuais de determinados tamanhos. Para tais casos, planejamos criar um construtor com parâmetros. Ele analisará automaticamente as solicitações de clientes recebidas por correio. Ele será usado pelos despachantes ao aceitar solicitações por telefone.
É assim que uma ordem parametrizada se parece.Avaliação de suporte técnico. O notório "classifica nosso serviço em uma escala de cinco pontos" com a capacidade de escrever de forma livre, tudo o que o cliente pensa sobre o nosso serviço.
Queremos desenvolver a própria
sala de expedição , que surgiu como uma muleta para ajudar o analisador de correspondência, em um
local de trabalho automatizado completo
do expedidor (AWP) . Agora, o despachante precisa examinar várias interfaces (contabilidade de equipamentos, uma lista de pessoas responsáveis, atendimento ao cliente) para coletar as informações necessárias sobre o cliente. No AWP, no entanto, tudo ficará em uma janela: incidentes de clientes, contatos, contratos, serviços solicitados e seus parâmetros, etc. dados.
Bem, não perca a esperança para a
distribuição automática de aplicativos por departamento . Agora, estamos pensando em um sistema de hashtag para um analisador de email.
***
O service desk está operando em modo de combate desde novembro e, durante todo esse tempo, tenho observado um aumento constante no número de incidentes (+ 40%), principalmente devido a solicitações internas. Atrevo-me a esperar que isso se deva ao fato de que a nova central de atendimento é mais amigável em todos os aspectos e os pedidos deixaram de passar por ele.
Outro lucro da nova central de atendimento é a flexibilidade. Já criamos várias soluções personalizadas para clientes individuais, a fim de integrar-se com seus balcões de serviço internos ou simplesmente se adaptar aos seus processos de produção. Anteriormente, levava meses e milhões, mas agora tudo o que é necessário é uma carta ao desenvolvedor e uma a duas semanas, dependendo da complexidade da tarefa.