Você está na página 1de 3

1-SOBRE O OBJETIVO DO ATENDIMENTO O cliente entra em contato com o atendimento quando tem uma duvida ou um problema.

Quando tem uma duvida, ele tende a ser mais paciente, mas espera que o analista entenda sua duvida e o responda de forma clara e pode se irritar caso isso no acontea. Do mesmo modo, o cliente com um problema j est mais propenso irritao, quando no atendido bem e de forma gil. Tendo isso em mente, fica claro que a funo primordial do atendimento entender a necessidade do cliente e mostrar a ele que est agindo para atend-lo. Para atender a necessidade do cliente, basta conseguir responder trs perguntas principais: -O que o cliente est tentando fazer? -Qual o resultado dessa tentativa? -Como podemos simular esse erro? Exemplo 1: O cliente reclama que no consegue enviar emails para um determinado destinatario. -O que o cliente est tentando fazer: Enviar emails para o destinatario fulano@email.com. -Qual o resultado dessa tentativa: Retorna uma mensagem de erro dizendo "destinatario no existe". -Como podemos simular esse erro: Pegamos os dados de acesso ao email do cliente e tentamos fazer um envio. Exemplo 2: O cliente reclama que est sem acesso ao servidor. -O que o cliente est tentando fazer: Tentando acessar ou "pingar" o site. -Qual o resultado dessa tentativa: Retorna um erro dizendo "A pagina no pode ser exibida", ou o "ping" no responde. -Como podemos simular esse erro: Testando o acesso ao site de nosso escritorio, "pingando" o servidor. Se o analista consegue responder as trs perguntas acima, ele est preparado para atend-lo, seja ajudando-o no processo, seja gerando uma solicitao para a equipe de admins. Nesse caso, o atendimento trabalha para o cliente, mas importante lembrar que o analista trabalha tambm para nossa empresa, e ele faz isso ao mostrar para o cliente que sua necessidade est sendo atendida de forma gil por nossa equipe e tranquilizando-o, medida que ele entende que pode contar conosco e se mantem satisfeito com nosso servio.

2-SOBRE A FORMA DE TRATAMENTO Nenhum cliente gosta de um atendimento "mecnico", "scriptado". Cabe ao analista usar seu instinto para identificar quando deve ser mais formal, ou quando pode agir com certa informalidade. No errado faze-lo, mas algumas regras devem ser observadas: -O cliente "Senhor", "Senhora" ou, quando a conversa menos formal, "Voc". Nunca "cara" ou "mano" e s "tu" se ambos, analista e cliente, forem gachos. -Ainda que a conversa esteja informal, processos internos NUNCA devem ser discutidos. "Fulano est almoando, mas assim que voltar vai ver o seu caso", "Deixa eu correr para falar com Fulano antes que ele v embora", "J pedi prioridade para o seu caso para Fulano, mas voc sabe como ..." e outras do tipo so inadmissveis. -Para o cliente, quem faz o atendimento nunca deve ser o Fulano, Ciclano ou Beltrano. Ao dar nome aos admins, voc passa ao cliente a impresso de pouco profissionalismo e de equipe pequena. Na ausncia de Fulano quem ir ver a solicitao? Chamados so sempre encaminhados para a EQUIPE de admins, nunca para um em especifico.

3-SOBRE O USO DO GERNDIO Ao contrario do que comumente dito, no errado usar o gerndio. O gerndio usado em qualquer frase que indique uma ao em curso. O problema est exatamente no habito, esse sim incorreto, usar o gerndio para indicar uma ao em progresso NO FUTURO. Veja o exemplo: -"Estou testando o acesso ao seu servidor" - Indica que o analista est, naquele instante, trabalhando no caso;

-"Vou estar testando o acesso ao seu servidor" - Indica que o analista est trabalhando no caso, mas em algum instante no futuro, o que no faz sentido sem uma maquina do tempo. O maior problema nesse caso, alm do uso incorreto, o fato de esse tipo atitude ter se tornado uma "marca registrada" de call centers ruins. Um analista j perde bastante o respeito do cliente, ao incorrer nesse erro. 4-Sobre a forma de abrir o chamado Para facilitar a busca em chamados antigos e para tornar mais fcil a leitura de um chamado, importante que exista uma padronizao desse mtodo. Essa uma parte essencial do trabalho do atendimento, sintetizar a duvida do cliente (que normalmente explicada em um email gigantesco e muitas vezes prolixo) e passa-la para a equipe de admins. Adotamos o formato abaixo como padro: TITULO: O "subject" do chamado deve ter o formato "EMPRESA - SERVIDOR - DESCRIO BREVE". Exemplo 1: "ELITE - FDWUAG11 - Recebimento de anexos" Exemplo 2: "ELITE - Desktop - Configurao de impressora" CONTEUDO: O contedo deve seguir o formato abaixo, totalmente preenchido: Cliente: Ambiente (Desktop ou nome do servidor): Problema: Mensagens de erro: Dados para teste: Demais Comentarios: Obviamente, podem existir solicitaes em que um dos campos no se aplique, ou em que seja necessria uma informao extra. No primeiro caso, basta colocar um "No se aplica" no campo. No segundo, use o campo "Demais Comentrios", e o bom-senso. 5-SOBRE A COBRANA AOS ADMINS O atendimento, como dito acima, trabalha para o cliente, e isso nunca pode ser esquecido. O analista vai ser cobrado pelo cliente, e s vezes precisa cobrar o admin para que um chamado seja atendido com certa prioridade. Isso correto, desde que o analista lembre que ele tambm trabalha pela sua empresa. A regra, nesse caso, usar o bom-senso. preciso que o analista entenda o impacto da solicitao do cliente, para poder fazer um correto julgamento de sua prioridade. Para o cliente, todas suas solicitaes so prioritrias, mesmo que a solicitao seja de alterao de uma senha, ou criao de um novo usuario de FTP. Se dois clientes entram em contato, um com problemas com sua senha e outro com seu servidor indisponvel, e ambos pedem prioridade, necessrio decidir sobre qual dos dois o analista vai cobrar o admin. Para o cliente, evidentemente, o analista nunca vai dizer que "existem outras prioridades", mas importante que o analista saiba que sua funo tranquilizar o cliente, e na medida do possvel essa "presso" nunca deve ser retransmitida para o admin. Novamente, existem excees. Nesse caso, impera o bom-senso do analista. 6-SOBRE O QUE DE NOSSA RESPONSABILIDADE As vezes um cliente entra em contato com uma demanda que no est no escopo de nosso trabalho. Alguns exemplos disso so: -Speedy fora do ar (a reclamao original era de "site fora do ar", mas o analista viu que a internet do cliente est fora); -Problemas para "abrir" o seu Outlook; -Problemas com a programao do seu site. Nesses casos, importante que o analista saiba lidar com o cliente e mostrar para ele que o assunto no de nossa competncia. Na medida do possvel isso deve ser feito de forma a mostrar para o cliente que o problema no conosco. No exemplo acima, onde o Speedy est fora do ar, o analista pode mostrar para o cliente que, da mesma forma que ele no consegue acessar o novo servidor, ele tambm no consegue acessar o UOL, o GOOGLE e etc, e

deve entrar em contato com o seu provedor de internet. Obviamente isso se aplica apenas aos clientes cujo link de internet no administrado pela Worldweb. A no ser em rarssimas excees, nunca devemos auxiliar um cliente em um problema que no seja de nossa responsabilidade, mesmo que seja algo simples, de uma rea que o analista "domine". Isso porque uma vez que o cliente tenha sido ajudado por nossa equipe em um desses assuntos, ele se sente no direito de exigir o mesmo tratamento, quando precisar novamente. Um analista est aprendendo a programar em PHP, por exemplo, e atende um cliente com um, para o analista, claro problema de programao. Se o analista explica que o problema no est em nosso servidor e que o cliente precisa entrar em contato com o seu desenvolvedor, o assunto est encerrado. Se, por outro lado, o analista resolve o problema na programao do cliente, ele cria vrios possiveis problemas. Se no dia seguinte o cliente perceber outro erro, ele vai entrar em contato conosco novamente, atrs de ajuda. Caso o analista que o atenda nessa segunda vez no tenha esse conhecimento de programao, o cliente vai se sentir lesado e exigir o mesmo tratamento da ultima vez. "Fulano resolveu isso ontem", ou pior, nos acusa de ter causado esse segundo problema, com a alterao anterior. Novamente, podem existir excees. Como sempre, contamos com o bom-senso do analista, lembrando que essas excees devem ser raras.