Só hoje tive tempo de entrar no blog….

Sim, o usuário não via nos ligar para saber o que está acontecendo e sim porque alguma coisa parou de funcionar e ele precisa entender o porque …

Então, respondendo…
“Todas as pessoas que ouvem a mensagem estão realmente atravessando aquele problema? ”

Não … todos escutam a mensagem, se o conteúdo for o suficiente para esclarecer o que está acontecendo, a pessoa desliga, então entendemos que, se não houvesse a mensagem, ela ficaria na linha somente para ser orientada sobre o que está acontecendo coisa que o anunciador fez…. certo?

Aí podemos considerar que o anunciador facilitou o trabalho e ajudou no controle de fila na hora da indisponibilidade, e quem desligou é porque só estava ligando por causa da indisponibilidade …

Se o usuário estiver com um problema que a mensagem não pôde resolver, então ele fica na fila até ser atendido pelo analista.

Sendo assim consideramos que, se o usuário desligou assim que ouviu a mensagem é pq uma simples orientação de que o “ERP está fora e a previsão de retorno é X” resolveu o motivo que gerou a ligação….

Não sei se fui muito claro … rs

Espero que sim …

Abraços !

Igor

Ajeitei o texto que comentaste.

Que bom que comentaste. Quando mais gente escrevendo, mais temos uma visão ampla dos procedimentos que o mercado realiza frente essa situação.

Agora, sacanagem chamar de CAOS, hein?

É um acrônimo de alguma expressão?

El Cohen

Lá quando ocorre de algum sistema cair, o ERP por exemplo, temos o chamado CAOS, que é um problema desconhecido, assim, quando recebemos ligação que algum sistema está fora do ar, o registramos como incidente e indicamos para a equipe responsável, essa equipe, ao receber vários incidentes, verifica que está realmente com problemas e solicita a abertura de um CAOS, após isso, todas as ligações recebidas sobre o mesmo problema são registrados como “informar indisponibilidade”, não gerando mais incidentes, porém não deixando de registrar, já que, pelo menos lá, todas as ligações atendidas devem ser registradas no sistema.

Espero ter contribuído com algo, já frequento este site e blog a bastante tempo, mas só agora vim a comentar.

Com isso, qualquer chamada pôde ser passada por um anunciador, dependendo da origem, interna/externa, nível 1 ou 2, de acordo com o nosso banco de dados.

A operação para mudança do anunciador é mais simples ainda… É só um upload via FTP do arquivo de áudio em wav ou mp3 em uma pasta específica.

Isso não nos resolve tanto pois lidamos diretamente com o cliente final… Mas pra quem tem isso num setor de TI que atende determinados serviços de uma ou mais empresas, seria fantástico!!

Com isso, o asterisk cria um relatório em html de quantas pessoas ouviram cada mensagem, e inclusive pode gravar todas as conversas

Há como configurar no Asterisk as opções depois da mensagem inicial, então colocando algo como “Caso deseje contato com um de nossos atendentes, disque 1″…

Todos que não discarem e abortarem a ligação depois da mensagem inicial certamente estão com o problema, então o relatório chega mais próximo possível dos 100% de exatidão.

Quanto à parte das listas infelizmente não conheço nada que aborde diretamente o assunto (GE ITIL-RS, que por sinal anda bem parada, aborda mais o Itil e não o Service Desk como um todo…).

Grande abraço,

J.Gomes

Obrigado pelo debate, acho que está bem interessante.

Bem, na verdade o usuário “não liga para saber o que está acontecendo“, certo?

Ele provavelmente liga para reclamar de um serviço que não está funcionando direito. Não é por curiosidade, suponho, que ele contata o Service Desk, só pra saber que “confusão é essa com o pessoal do outro setor“.

Porém, você disse que consegue anotar o número de usuários que ouviram a mensagem e desligaram. Eu não tenho muita experiência com tais anunciantes automáticos, mas…

Todas as pessoas que ouvem a mensagem estão realmente atravessando aquele problema?

Caso contrário, sua contabilidade fica prejudicada. E seus argumentos lá em riba (“Registrá-los é importante para medir o impacto no negócio“) vão por água abaixo, pois a contabilização estará, no mínimo, misturando atendimentos.

Veja, não estou afrontando suas idéias. Eu as respeito. Estou é confrontando com meus pensamentos. Ambos (e mais todo mundo que nos lê) sairemos mais calejados no assunto com esse debate sério e responsável.

Em relação às listas: eu só acompanho duas nacionais oriundas do Yahoo: ITSMF e o GE ITIL-RS. Tentei algumas no orkut, mas o povo está mais interessado em material para certificação e dicas sobre arrumar hardware, hehehe..

Abração!

El Cohen

Sobre o anunciador, a idéia é a seguinte: o usuário liga no SD porque o ERP está indisponível, mas ele não sabe … então a intenção dele em nos ligar é saber o que está acontecendo…
Se a mensagem do anunciador suprir essa necessidade de informação o usuário vai ouvir, e desligar o telefone, ou seja ele nem vai falar com o analista que não vai precisar ser repetitivo na orientação e não vai precisar registrar.
Durante o período que o anunciador esteve no ar, eu posso ver quantos usuários ouviram a mensagem e desligaram, ou seja, o quanto o anunciador ajudou a esclarecer as dúvidas do usuário.
Quem não se der por satisfeito com a mensagem, ficará na linha e consequentemente será atendido e terá uma ocorrência registrada…
Se eu tenho controle de quantos usuários ouviram a mensagem e desligaram, esse é um indicador relevante para eu mostrar para o cliente o impacto da indisponibilidade e quanto o uso do anunciador foi importante para ajudar a esclarer a dúvida dos usuários.

Que tal algumas indicações de listas de discussões boas para o nosso mundinho “service deskiano” ? rs …

Obrigado !

Tem tem algo aí que me parece incongruente.

OK para o fato que você sugere registrar tudo. Mas como pode colocar um anunciador? Ele não vai fazer com que muitos incidentes NÃO SEJAM registrados?

Gracias pelos elogios ao livro. Confesso que fico lisonjeado sempre que alguém comenta sobre ele (a favor ou contra, haha).

Sobre os temas para o blog: putz, é difícil trazer assuntos polêmicos para cá. Tento ficar o máximo “antenado” com as várias comunidades (listas de discussão, orkut, blog’s) e daí recupero algo pra cá.

Abração,

El Cohen

Muitas vezes me deparo com problemas desses no dia-a-dia do SD. Creio que a melhor opção é registrar um incidente que deve ser endereçado à equipe responsável o quanto antes. Essa equipe deve munir o SD de informações e prazos para que os outros 200 chamados sejam relacionados ao primeiro, mas somente de orientação. Registrá-los é importante para medir o impacto no negócio, ainda mais quando a indisponibilidade não é programada.
Uma maneira que adotamos e ajuda muito a reduzir os chamados e deixar os usuários cientes do que está acontecendo é um anunciador antes que o analista atenda o telefone. Muitos usuários escutam a mensagem e já se dão por satisfeitos evitando tempo somente de orientação dos analistas. Podemos medir o impacto depois pelo número de abandonos após a mensagem do anunciador.
Seu livro é muito bom, está clareando algumas visões importantes para o dia a dia do SD !
Obrigado !
PS: acho que o blog fica muito interessante quando surgem tópicoos dessa natureza onde podemos trocar ideias e experiências diferentes
Abraços !

Fernando,

Acho que você traz novas luzes sobre o assunto. Realmente, é capaz de engarrafar o atendimento na central de atendimento de maneira que nem seria possível registrar tudo, hehehe.

Em relação à sua idéia de registrar TUDO, em minha opinião a gerência de incidentes deve tentar reestabelecer o serviço o mais rápido possível.

Obviamente, não posso me esquecer que você – Fernando – opera geralmente como um TERCEIRO nas atividades de Help Desk. E nessa situação, é mais recomendável registrar TUDO para que se possa fazer auditorias em sua atividade (e mostrar o alto nível de excelência) mais tarde.

Gomes,

Nós temos visões bem parecidas, até por que atuamos na prestação de serviços a terceiros onde o que importa não é o registro e comprovação posterior, mas sim RESOLVER o pepino ASAP, hehe.

Abraços a todos e obrigado por compartilharem suas idéias.

El Cohen
PS: Fernando, outubro tem Help Desk Day em Curitiba o seu exemplar está garantido, gratuitamente, em troca da sua palestra ]]> http://www.4hd.com.br/blog/2008/09/12/eficiencia-x-eficacia-peter-drucker/comment-page-1/#comment-6274 Jarlei Sun, 14 Sep 2008 14:04:05 +0000 http://www.4hd.com.br/blog/?p=419#comment-6274 Drucker eh simplesmente sensacional. Vale muito a pena reler - sugiro que comecem por uma serie lancada pela Folha, chamada EMPRESARIOS DE EXITO, escritas pelo Robert Heller, por sinal muito bem escrita e que consegue resumir bem as ideias e textos nao so do Drucker, mas de outras pessoas influentes tb. Vamos nos surpreender como coisas que o Drucker fala ha muito tempo, agora esta sendo praticadas. POr exemplo, sempre que tinha oportunidade, o Drucker perguntava: Qual o seu negocio ? A resposta era invariavel, independente do ramo de atuacao: TReinar e Desenvolver pessoas. Drucker eh simplesmente sensacional. Vale muito a pena reler – sugiro que comecem por uma serie lancada pela Folha, chamada EMPRESARIOS DE EXITO, escritas pelo Robert Heller, por sinal muito bem escrita e que consegue resumir bem as ideias e textos nao so do Drucker, mas de outras pessoas influentes tb. Vamos nos surpreender como coisas que o Drucker fala ha muito tempo, agora esta sendo praticadas. POr exemplo, sempre que tinha oportunidade, o Drucker perguntava: Qual o seu negocio ? A resposta era invariavel, independente do ramo de atuacao: TReinar e Desenvolver pessoas. ]]> http://www.4hd.com.br/blog/2008/09/12/eficiencia-x-eficacia-peter-drucker/comment-page-1/#comment-6246 J.Gomes Sat, 13 Sep 2008 03:59:39 +0000 http://www.4hd.com.br/blog/?p=419#comment-6246 Fernando, A idéia é ótima e certamente fica muito confiável essa métrica, etc, etc, etc. Porém... A minha principal função é capacitar e coordenar uma equipe para atender bem os clientes, ou para registrar bem os incidentes??? Acredito que, partindo do exemplo citado pelo Roberto, eu possa me dar ao luxo de desprezar uma exatidão na estatística, para atender "mais e melhor", pois mesmo nos poucos segundos que leva-se no cadastramento do incidente, há tempo para um atendimento mais completo ou até mesmo para um novo atendimento... Esses momentos, que chamo de HDD (Hora do Desespero), sempre complicam bastante o já corrido Service Desk, mas mesmo nestas horas, o atendimento acaba sendo realizado de forma rápida e eficiente... Não é uma questão de "deixar de lado" ou "não dar atenção" às estatísticas, e sim de colocar na balança qual o impacto mais negativo.. Uma métrica perfeita e algumas reclamações, ou alguns números inexatos e reclamação zero?? Não penso duas vezes em sacrificar algum registro em detrimento à qualidade e agilidade do atendimento ao cliente. É ele que paga o nosso salário, e não a estatística! Posso não ter números precisos no final do mês, mas acho que no fim das contas, esse é o prejuízo menor. Abraço, J.Gomes P.S.: O Roberto me proibiu de vender o livro pra um sebo, então vais ter que comprar na livraria mesmo :-) Fernando,

A idéia é ótima e certamente fica muito confiável essa métrica, etc, etc, etc.

Porém… A minha principal função é capacitar e coordenar uma equipe para atender bem os clientes, ou para registrar bem os incidentes???

Acredito que, partindo do exemplo citado pelo Roberto, eu possa me dar ao luxo de desprezar uma exatidão na estatística, para atender “mais e melhor”, pois mesmo nos poucos segundos que leva-se no cadastramento do incidente, há tempo para um atendimento mais completo ou até mesmo para um novo atendimento…

Esses momentos, que chamo de HDD (Hora do Desespero), sempre complicam bastante o já corrido Service Desk, mas mesmo nestas horas, o atendimento acaba sendo realizado de forma rápida e eficiente…

Não é uma questão de “deixar de lado” ou “não dar atenção” às estatísticas, e sim de colocar na balança qual o impacto mais negativo.. Uma métrica perfeita e algumas reclamações, ou alguns números inexatos e reclamação zero??

Não penso duas vezes em sacrificar algum registro em detrimento à qualidade e agilidade do atendimento ao cliente. É ele que paga o nosso salário, e não a estatística!

Posso não ter números precisos no final do mês, mas acho que no fim das contas, esse é o prejuízo menor.

Abraço,

J.Gomes

P.S.: O Roberto me proibiu de vender o livro pra um sebo, então vais ter que comprar na livraria mesmo ]]> http://www.4hd.com.br/blog/2008/09/12/eficiencia-x-eficacia-peter-drucker/comment-page-1/#comment-6240 Fernando Baldin Fri, 12 Sep 2008 22:35:57 +0000 http://www.4hd.com.br/blog/?p=419#comment-6240 Cohen, td bem, minha opinião seria a seguinte: Acredito que das 200 ligações dificilmente todas seriam atendidas, portanto já haveria aí um reflexo naquela hora na taxa de abandono. Após isso parto do principio que se foi atendido uma ligação no SD, o esforço deve ser registrado!! afinal...se não todos os demais relatórios tornam-se inúteis e não confiáveis. Outro ponto, para situações como essa, deve se iniciar um processo de MAJOR INCIDENT, Aonde todo o processo de escalonamento e alertas deve ser específico para proporcionar os recuros adequados a área de operação para resolver o incidente. algo parecido com o conceito de problema, aonde esse major incident deveria ser tratado e todos os demais deveriam então ser linkados a esse incidentes, sendo classificados e registrados corretamente, pois só assim , com essas entradas é que geraríamos saídas consistentes do processo de gestão de incidentes para a efetiva gestão de problemas entender o impacto, custo e as soluções que devem ser realizadas para eliminar o possível erro da infra estrutura. Acredito que ao burlar essa sistemática TI só tem a perder, pois maquiará o real impacto, não o subjetivo, mas sim o baseado em registros e fatos da queda do ERP.!! Abraços e Parabéns pelo Livro!! assim que eu pagar as contas que to devendo!! comprarei um exemplar!!! Abraços!! Cohen, td bem, minha opinião seria a seguinte:
Acredito que das 200 ligações dificilmente todas seriam atendidas, portanto já haveria aí um reflexo naquela hora na taxa de abandono.
Após isso parto do principio que se foi atendido uma ligação no SD, o esforço deve ser registrado!! afinal…se não todos os demais relatórios tornam-se inúteis e não confiáveis.
Outro ponto, para situações como essa, deve se iniciar um processo de MAJOR INCIDENT, Aonde todo o processo de escalonamento e alertas deve ser específico para proporcionar os recuros adequados a área de operação para resolver o incidente. algo parecido com o conceito de problema, aonde esse major incident deveria ser tratado e todos os demais deveriam então ser linkados a esse incidentes, sendo classificados e registrados corretamente, pois só assim , com essas entradas é que geraríamos saídas consistentes do processo de gestão de incidentes para a efetiva gestão de problemas entender o impacto, custo e as soluções que devem ser realizadas para eliminar o possível erro da infra estrutura. Acredito que ao burlar essa sistemática TI só tem a perder, pois maquiará o real impacto, não o subjetivo, mas sim o baseado em registros e fatos da queda do ERP.!!

Abraços e Parabéns pelo Livro!! assim que eu pagar as contas que to devendo!! comprarei um exemplar!!!
Abraços!!