Ferramentas de Domínio Público para Gerenciamento de Chamados a Suporte

Resumo

Este artigo tem por objetivo fornecer uma visão geral sobre como funcionam e para que servem as ferramentas automáticas de atendimento a chamados de suporte.

Serão discutidas as vantagens de se usar este tipo de sistema e serão mostradas as funcionalidades gerais das diversas ferramentas que possuem esse propósito. Uma descrição genérica sobre o funcionamento destas ferramentas também será fornecida.

De forma a exemplificar o que está sendo mostrado, será apresentada a ferramenta Request Tracker(RT), utilizada pela RNP para o gerenciamento em questão. Esta apresentação inclui instalação, utilização e administração da ferramenta. Por fim, outras ferramentas de domínio público são citadas e, em seguida, tem-se uma breve conclusão.

1. Introdução

Em qualquer empresa, a satisfação de seus clientes é ponto fundamental. Qualquer avaliação sobre a qualidade do serviço prestado por uma empresa é influenciada pela maneira pela qual seus clientes são tratados enquanto usuários de serviços e produtos. E, dentre os vários aspectos que caracterizam uma boa prestação de serviço, um dos principais é o atendimento a reclamações.

Os procedimentos de abertura de reclamação tornaram-se muito versáteis graças ao uso de ferramentas web e de correio eletrônico. Sendo assim, nada melhor do que automatizar o atendimento a reclamação - é o que fazem os programas genéricamente chamados de "ferramentas de Trouble Tickets".

Basicamente, essas ferramentas consistem num programa capaz de receber reclamações, seja via web ou por email, e encaminhar estas reclamações para as pessoas responsáveis. Ao mesmo tempo em que é feito este encaminhamento, o cliente que solicitou o serviço recebe um número de seqüência que identifica a reclamação e que permite ao usuário pedir informações sobre o andamento de seu atendimento.

Atualmente, no âmbito da Internet, existem várias ferramentas de trouble tickets de domínio público. Cada uma delas traz funcionalidades e facilidades que flexibilizam a operação de atendimento e propiciam uma maior credibilidade junto ao reclamante. Além disso, essas funcionalidades permitem o uso dessas ferramentas para outros propósitos, como por exemplo, para o acompanhamento na execução de um projeto, ou mesmo para uma avaliação de quão ágil e correto vem sendo o atendimento às reclamações.

2. Funcionalidades Gerais

Algumas características são desejáveis numa ferramenta de trouble ticket. Permitir a criação de mensagens automáticas e configuráveis de resposta a reclamações é uma delas. Nessas mensagens, é informado o número do ticket (também denominado "chamado"), ou seja, o número serial que identifica a reclamação ou pedido. É desejável também a possibilidade de configurar e enviar mensagens que informem ao solicitante o andamento de seu pedido, assim como as transações efetuadas durante a "vida" do ticket. Tais transações são particulares de cada ferramenta e variam de acordo com sua filosofia de ação.

A potencialidade de uma ferramenta de trouble ticket depende muito de como são organizados internamente os chamados. É desejável ser possível criar "filas", nas quais estarão associados ticketsrelacionados a um assunto em particular. Por exemplo, todas as reclamações oriundas do maior cliente da empresa, ou ainda, pedidos encaminhados pelo setor de marketing. Cada fila possuirá sua política de acesso e de tratamento de chamados. A maneira como um ticket é atribuído a uma fila, em geral, pode ser feita tanto manualmente (pelo administrador da ferramenta) quanto em função do email para o qual foi enviado o chamado. Cada fila, por sua vez, também poderá conter outras divisões lógicas que ajudem na hora de listar ou organizar os tickets da fila.

Uma fila, portanto, pode ser considerada uma entidade independente. A ela podem ser associados usuários que podem abrir chamados, recebê-los ou manipulá-los - será função das permissões atribuídas à fila e a cada usuário, independentemente. Desta forma, os usuários cadastrados numa determinada fila podem não tomar conhecimento do que está sendo tratado em outras filas nas quais eles não estão cadastrados. Esta é uma funcionalidade importante do ponto de vista de organização e de segurança de informação.

Da mesma forma, uma fila tanto pode ser liberada para que qualquer pessoa, usuária cadastrada ou não, possa abrir um chamado quanto pode ser liberada apenas para um conjunto de pessoas (em geral usuários cadastrados). Graças a isto, é possível filtrar mensagens indesejáveis que resultariam em abertura de chamados.

Cada ticket, além de possuir seu mandante, também pode ter um responsável a ele associado. Isto é interessante pois permite saber a quem deve ser cobrado o andamento do chamado. A data de envio de cada chamado também deve ser registrada de maneira a ser possível avaliar o tempo de espera do cliente até seu atendimento. Algumas ferramentas também fornecem a opção de se atribuir um prazo máximo para o atendimento do chamado. Passado este prazo, emails de aviso poderão ser enviados.

Além destes atributos, um ticket possui um atributo especial que é aquele que lhe confere um estado. Este estado, em geral, pode ser "aberto" (quando o ticket é criado) ou "fechado" (quando o ticket é resolvido), mas existem outros possíveis, como o estado "suspenso" (quando não se sabe como resolvê-lo, por exemplo) ou o "eliminado" (quando ele é ignorado).

A manipulação dos tickets, em geral, se dá através de uma interface web. Para acessá-la, o usuário deverá fornecer nome e uma senha que, de acordo com as permissões configuradas, o possibilitará visualizar e/ou alterar as propriedades de certos tickets.

Diante de todas essas funcionalidades passíveis de configuração, torna-se necessário que cada ferramenta possua seu módulo de gerência, assim como usuários administradores. Estes administradores agem como "super-usuários", capazes de configurar permissões e atributos de quaisquer filas e usuários que façam parte do sistema.

3. Comportamento Básico

Uma ferramenta de trouble ticket trabalha basicamente em cima de mensagens enviadas e pertinentes a um determinado ticket. Essas mensagens, oriundas de emails ou da própria interface web da ferramenta, circulam entre os membros da respectiva fila podendo ou não chegar ao mandante do chamado. Portanto, seu conjunto, cronologicamente ordenado, consiste num histórico sobre o atendimento ao chamado em questão. Cada ticket possuirá todas as mensagens trocadas e relacionadas com ele até o seu definitivo fechamento, assim como todas as mudanças em seu estado ou mudanças de quaisquer outros atributos.

Vejamos a seguir um exemplo comum. Digamos que um chamado vai ser aberto por um determinado cliente tratando de um problema ligado ao acesso a um determinado site da internet. O usuário envia uma mensagem para um determinado email que é direcionada para a ferramenta de trouble ticket. Ao chegar na ferramenta, este email é convertido em "ticket aberto" e uma mensagem automática de aviso de recebimento, contendo o número do chamado, é enviada ao cliente.

O ticket em questão, relacionado a uma determinada fila, é atribuído pelo administrador desta fila para um dos membros. Tanto o texto original do chamado como a atribuição da responsabilidade deste a um dos membros é arquivado no ticket. Daí pra frente podem ocorrer várias trocas de mensagens entre os membros da fila sem que o cliente tome conhecimento. Em geral, estas mensagens são chamadas de comentários. Também outras mensagens podem ser direcionadas ao cliente, com cópia para os demais membros, pedindo informações extras. Estas informações são respondidas pelo cliente através de emails que contenham o identificador do ticket. O cliente tem liberdade para enviar quantas mensgens quiser referentes a este ticket, assim como qualquer um dos membros da fila, desde que mantido o identificador. É este identificador que permitirá catalogar todas as mensagens e ações relacionadas com o ticket.

Após as várias mensagens trocadas, o ticket poderá ser fechado e reaberto tantas vezes quanto forem necessárias, sempre com todas as ações arquivadas em seu corpo. Uma vez fechado em definitivo, caberá ao administrador removê-lo definitivamente do sistema ou não, quando bem entender.

4. Ferramenta para gerenciamento de chamados usada na RNP - Request Tracker

O RT (Request Tracker) foi a ferramenta adotada pela RNP para gerenciar o atendimento em diversos setores da empresa. Ele cobre desde as requisições aos suportes locais até os chamados relacionados com a operação do backbone. Da mesma maneira, os chamados feitos pelos técnicos da RNP à EMBRATEL são registrados no RT de modo a se ter um acompanhamento documentado do serviço por eles oferecido. O RT é distribuído segundo a licença pública da GNU (GPL, General Public License) e pode ser adquirido no site http://www.fsck.com/projects/rt/ . Lá também podem ser encontrados uma descrição sobre a ferramenta, manuais, telas de exemplo, FAQs e listas de discussão.

4.1 Requisitos Básicos

O RT roda em plataformas UNIX e é baseado em Perl versão 5.0 ou superior ( http://www.perl.com ). Além de ser necessário o Perl 5.x, é preciso que ele possua os módulos CGI.pm e Digest::MD5, ambos conseguidos no mesmo site do Perl.

A base de dados do RT é construída usando o MySQL ( http://www.mysql.com ) versões 3.20.x, 3.21.x ou 3.22.x . Uma dessas versões deve também estar instalada na plataforma e a versão utilizada deve ser informada no arquivo de instalação. Para que o Perl interfaceie com o MySQL, deve-se ter instalado o Msql-Mysql-modules ( ftp://ftp.mysql.com/pub/mysql/Contrib ).

Um outro requisito importante é ter um agente de correio eletrônico instalado e funcionando (por exemplo, o sendmail). Vale ressaltar também que é preciso usar o Gnu Make ( http://www.gnu.org ) para se ter garantia na execução dos comandos do "makefile" de instalação.

4.2 Instalação

Será relatado abaixo o procedimento para a instalação da versão 1.07 do RT. Esta era a versão recomendada em abril de 2001, atualmente a versão recomendada é a 2.06 . No arquivo README, que acompanha a distribuição, encontra-se uma descrição mais sucinta sobre a instalação.

Eis os passos após ser "baixado" o arquivo rt.tar.gz:

  a. Expandir rt.tar.gz num diretório temporário:
  tar xvzf rt.tar.gz -C /tmp

  b. Verificar se os módulos Perl foram corretamente instalados:
  perl /tmp/rt-1.0.7/bin/testdeps.pl -warn

  Caso algo não conforme seja informado, isto poderá ser corrigido caso se tenha o 
  CPAN instalado (www.cpsn.org):
  perl /tmp/rt-1.0.7/testdeps.pl -fix

  c. Criar um usuário RT pertencente ao grupo RT

  d. Alterar /tmp/rt-1.0.7/Makefile de acordo com as necessidades. Dentre as 
  alterações a serem feitas:

  - Na linha 95, colocar o "mail alias" para recebimento de mensagens pelo RT:
  RT_MAIL_ALIAS = ...

  - Na linha 136, colocar a versão do Mysql:
  MYSQL_VERSION = ...

  - Na linha 157, colocar uma senha para o RT se autenticar com o mysql:
  RT_MYSQL_PASS = ...

  - Na linha 242, colocar o nome usado para o grupo do root (por ex: wheel), o 
  "default" é root:
  chgrp -R ... $(RT_PATH)

  - Todas as variáveis do Makefile devem estar setadas.

  e. Como root, dar o comando de instalação (usar o GNU make):
  gmake install

  f. Ocorrendo algum problema durante a instalação, caso o Makefile já tennha
  criado alguma base "mysql", descomentar a linha 284 do Makefile para poder
  rodá-lo novamente (esta linha destroi   a base de dados criada):

  #    $(MYSQLDIR)/mysqladmin -h $(RT_MYSQL_HOST) -u $(MYSQL_DBADMIN) drop
  $(RT_MYSQL_DATABASE)

  g. Configurar no arquivo "/etc/aliases" os aliases para o RT:
  rt:          "|/opt/rt/bin/rt-mailgate general correspond"
  rt-action:   "|/opt/rt/bin/rt-mailgate general action"

  h. Copiar o executável /opt/rt/bin/suidwrapper para o diretório de programas 
  que podem ser executados pelo sendmail:
  cp -p /opt/rt/bin/suidwrapper /usr/libexec/sm.bin/

  i. Fazer o "link" simbólico rt-mailgate apontar para o executável do ítem anterior:
  rm /opt/rt/bin/rt-mailgate
  ln -s /usr/libexec/sm.bin/suid_wrapper /opt/rt/bin/rt-mailgate

  j. Alterar /opt/rt/etc/config.pm para que o sendmail seja chamado no PATH correto: 

  - Na linha 72
  $mailprog = "/usr/sbin/sendmail";

  k. Verificar outras possíveis alterações no arquivo /opt/rt/etc/config.pm

  l. Disparar o mysql com o comando safe_mysqld

  m. Dar o comando newaliases para que as modificações em /etc/aliases sejam 
  incorporadas

  n. Colocar o comando safe_mysqld para ser executado sempre que houver boot

  o. Copiar templates de 
  /opt/rt/lib/generic_templates/ para /opt/rt/etc/templates/queues/general/ 
  e modificá-los (pressupõe-se que a primeira fila a ser criada será 
  chamada de "general")

  p. Inserir em /usr/local/etc/apache/httpd.conf, na parte de aliases:
 
      Alias /webrt/ "/opt/rt/lib/images/"
 
      <Directory />
          Options Indexes MultiViews
          AllowOverride None
          Order allow,deny
          Allow from all
      </Directory>
 
      ScriptAlias /rt/ "/opt/rt/bin/cgi/"
 
      <Directory />
          AllowOverride None
          Options None
          Order allow,deny
          Allow from all
      </Directory>
 
  q. Dar o comando "apachectl graceful" para que as alterações em httpd.conf 
  sejam incorporadas ao apache sem que sua execução seja interrompida.

4.3 Funcionamento

O RT possui as mesmas funcionalidades e o mesmo comportamento básico descrito nas seções anteriores. Os "chamados" (tickets) podem ser criados ou "enchidos" (ter textos incluídos) via correio eletrônico. De acordo com o endereço (alias) de destino do email, este será direcionado para uma determinada fila no RT.

Cada ticket corresponde a um grupo de emails em ordem cronológica que, por tratarem de um mesmo tema, possuem um mesmo cabeçalho no campo de assunto (subject). Este cabeçalho é composto por uma parte fixa acrescida do número sequencial do ticket. Sempre que um email enviado ao RT contiver um determinado cabeçalho (salvo prefixos padrões do tipo "Re:"), o RT saberá em qual ticketanexar o conteúdo deste email. Caso o email não contenha este cabeçalho, o RT criará um novo ticket e seu conteúdo inicial será o conteúdo deste email.

Os tickets possuem um campo chamado status que o identifica como aberto (open), resolvido (resolved), morto (dead) ou parado (stalled, ou seja, sem solução prevista). Sempre que um ticket é criado, ele é dado como aberto. Com o desenrolar do problema tratado, ele pode ter seu status alterado por algum membro da fila que tenha permissão para manipulação. Em geral, quando o assunto tratado é esgotado, o ticket tem seu estado alterado para resolvido.

Um outro campo de cada ticket é o requisitante (requestor). Ele corresponde ao email de quem criou o ticket, ou seja, de quem primeiro enviou uma mensagem ao RT sobre um assunto ainda não existente.

Os campos que correspondem ao número serial, fila, assunto, requisitante e status de cada ticket são campos obrigatórios e sempre possuem algum valor associado. Porém, de maneira a flexibilizar e ampliar as operações envolvendo tickets, o RT provê outros campos que podem ou não ser utilizados. Dentre os mais úteis, tem-se os campos prazo limite (due), responsável (owner) e área (area). O owner de um ticket é sempre um membro da fila ao qual o ticket está relacionado. Na configuração da fila, podem ser atribuídos ao owner determinados avisos sobre mudanças ocorridas nos diversos campos dos tickets pelos quais é responsável. Da mesma maneira, uma fila pode ser configurada para ter diversas áreas. Estas áreas visam apenas facilitar a estrutura de informação dos tickets. Por exemplo, os tickets de uma mesma área podem ser responsabilidade de um mesmo membro, ou seja, possuirem um mesmo owner.

Vários destes campos se justificam ao se usar a interface web do RT. Eles fornecem uma orientação visual que permite um entendimento mais rápido sobre o problema tratado e quem está trabalhando nele. A interface web é acessada via login e senha - apenas usuários cadastrados podem adentrar o sistema. A figura 1 mostra a tela inicial para se entrar num sistema RT. A figura 2 traz um exemplo de como são visualizados os tickets de uma base de dados no RT.

Figura 1 - Tela inicial para se entrar num sistema RT

Figura 2 - Exemplo de como são visualizados os tickets de uma base de dados no RT

Como pode ser visto pela figura 2, a página principal do RT pode ser "lida" como que possuindo 3 setores, um em cima do outro. No primeiro, mais acima, tem-se um lista de tickets com os valores associados a seus campos. Cada campo se encontra numa coluna em separado, que em seu topo possui botões que possibilitam ordenar os tickets de forma crescente ou decrescente, de acordo com os valores desse campo. No setor do meio, o RT permite selecionar quais tickets serão listados. Esta seleção é feita escolhendo-se valores, pré-definidos ou não, para os diversos campos. Por exemplo, pode-se listar apenas os tickets abertos pertencentes a fila "chamados internos". E, por último, o setor de baixo da página permite a visualização de um determinado ticket (identificado por seu número serial) e a criação de tickets numa determinada fila, o que substitui o envio de um email para um determinado alias. A figura 3 mostra a tela de criação de um ticket.

Figura 3 - Tela de criação de um ticket

Os ítens da página na figura 2 que posuem uma linha sublinhada correspondem a links que podem ser acessados. Os links referentes aos números de série servem para visualizar o conteúdo do ticket(o mesmo que usar o botão "Display request #" na parte de baixo da página principal). Os linksreferentes aos requestors servem para enviar mensagens ditas "de resposta" ao requisitante. A figura 4 mostra a tela para envio de resposta e as figuras 5a e 5b mostram a tela de visualização do ticket.

Figura 4 - Tela para envio de resposta

Figura 5a - Tela de visualização do ticket

Figura 5b - Tela de visualização do ticket

Pela figura 5a podemos notar links para os diversos campos do ticket. Estes links se encontram no setor superior da página. De acordo com o tipo de permissão do usuário que está acessando o ticket, lhe será permitido alterar o valor destes campos, clicando no respectivo link e seguindo os procedimentos que se sucedem.

Após este setor, podemos verificar que há um setor denominado "histórico de transações" (Transaction History) e que possui todo o histórico de mensagens trocadas com relação ao assunto tratado. Estas mensagens aparecem em ordem cronológica de cima para baixo. Acima de cada mensagem, aparece uma tarja informando se a mensagem trata-se de um chamado (request), uma resposta (reply) ou um comentário (comment). A diferença da resposta (também chamada de "correspondência") para o comentário é que a primeira é sempre enviada para o requisitante e a segunda nunca é enviada para o requisitante. Em ambos os casos, as mensagens poderão ser enviadas para os membros da respectiva fila, caso assim esteja configurado.

Ainda nestas tarjas, pequenos botões no final à direita são links para páginas de envios de comentários ou de respostas, nesta ordem. Ao se clicar nestes botões, o texto abaixo da tarja será automaticamente incluído no email a ser enviado (de comentário ou de resposta). Outras tarjas informando operações com o ticket, como mudanças de owner ou de status, também podem aparecer no histórico de transações.

No rodapé e no topo da página mostrada nas figuras 5a e 5b, aparecem links para a edição de comentário e para edição de resposta (correspondência) que não incluem nenhum texto no corpo da mensagem a ser enviada. Outros links para funções úteis, como "resolver" o ticket (mudar o status do ticket para resolved), também aparecem na página de acordo com a permissão do usuário que a está acessando.

4.4 Administração

A configuração de filas e usuários, assim como sua administração, é feita através de uma interface web própria. Esta interface possui uma etapa de login nos mesmos moldes que a da interface de visualização de chamados. Após a autenticação do usuário, uma página similar à mostrada na figura 6 é apresentada. A conta e senha para o primeiro acesso à administração do RT, que corresponde a uma conta de super-usuário para este sistema, são configuráveis no arquivo Makefile, usado durante a instalação, e no arquivo config.pm .

Figura 6 - Menu principal de administração para um usuário configurado como "administrador do RT" (RT Admin)

A página da figura 6 contém o menu principal de administração para um usuário configurado como "administrador do RT" (RT Admin). Este menu se divide em duas partes facilmente identificáveis: configuração de usuários e configuração de filas.

A criação e/ou configuração do usuário é feita a partir da página mostrada na figura 7. Na coluna à esquerda, estão os dados do usuário, incluindo nome real, senha e email. Na coluna à direita, estão as permissões para acesso às filas. Estas permissões podem ser do tipo "sem acesso" (no access), "visualização" (display), "manipulação" (manipulate) e "administração" (admin). Acima desta coluna, encontra-se um campo para seleção que indica se o usuário é um administrador do RT ou não.

Figura 7 - Tela para criação e/ou configuração do usuário

Apenas os usuários configurados como administradores do RT têm as opções de criação de fila e criação de usuários no menu principal, assim como a opção de modificar a configuração de outros usuários ou filas. Usuários que não sejam administradores do RT só poderão modificar sua própria configuração e as filas nas quais ele tenha permissão de administrador.

A permissão de "administrador" para uma determinada fila permite, além de sua configuração, a sua manipulação. Manipular uma fila significa poder alterar os diversos campos dos tickets nela contidos (além de respondê-los ou comentá-los). A permissão de "manipulação" dá este poder mas não permite configurar a fila, apenas visualizar sua configuração. A permissão de "visualização" permite apenas que os tickets sejam visualizados e respondidos ou comentados, mas não permite visualizar a configuração da fila. Já a permissão "sem acesso" não dá direito a nenhuma informação relacionada à fila, nem mesmo o conhecimento de sua existência.

As permissões de acesso de todos os usuários para uma determinada fila também podem ser configuradas pelos usuários administradores desta fila. As figuras 8a e 8b mostram a página de configuração de uma fila, acessada através do link encontrado no menu principal.

Figura 8a - Página de configuração de uma fila

Figura 8b - Página de configuração de uma fila

Na coluna da direita, referente ao controle de acesso, se encontram os usuários cadastrados e suas respectivas caixas de seleção de permissão. No alto desta coluna aparece um campo para habilitar, na fila, a criação de tickets provenientes de emails de pessoas não cadastradas como usuários ("Allow non-members to create requests").

Na coluna da esquerda se encontram a configuração do alias para emails (figura 8a), a configuração das notificações sobre correspondências, comentários, respostas automáticas de criação ou qualquer transação, e também a criação ou remoção de áreas na fila. Além disso tudo, é possível configurar uma faixa de valores para o campo "prioridade" que está associado aos tickets pertencentes à fila (figura 8a).

4.5 Funcionalidades Extras

O RT possibilita a incorporação de novas funcionalidade através do uso de scripts em Perl. No site do RT, por exemplo, é possível encontrar scripts capazes de montar gráficos com estatísticas envolvendo o tempo de fechamento dos tickets. Também se pode encontrar scripts capazes de remover "físicamente" do sistema os tickets com status igual a dead.

5. Outros Exemplos de Ferramentas de Domínio Público para Atendimento a Chamados

Existe um grande número de ferramentas gratuitas de trouble ticket disponíveis na internet. Vejamos alguns exemplos.

• Wreq:
  
  O Wreq, que vem de "Work Request", foi criado na universidade de Duke por Yunliang Yu. A ferramenta pode ser conseguida na URL http://www.math.duke.edu/~yu/wreq . Uma amostra da interface web do Wreq pode ser encontrada neste site. A ferramenta é escrita em Perl, portanto, o pré-requisito para a instalação é ter instalado o Perl versão 5 com GDBM, ambos disponibilizados pela GNU (o módulo GD para Perl é necessário).

• JitterBug:
  
  Esta ferramenta foi desenvolvido por Andrew Tridgell para possibilitar aos usuários do sistema samba reportarem os bugs encontrados. Ferramentas com este enfoque costumam ser chamadas de "bug trackers". Ela está disponibilizada sob licença GPL (General Public License) da Gnu e pode ser encontrada na URL http://samba.anu.edu.au/jitterbug/ . Trata-se de um programa escrito em linguagem C que funciona como um script CGI. Dentre algumas das funcionalidades oferecidas, ele possibilita a criação e edição de FAQs (Frequented Asked Questions). A ferramenta roda em plataformas da família UNIX e sua interface web é compatível com HTML 3.2.
  
  Alguns sites que rodam interfaces JitterBug são o site do Java Linux (http://www.blackdown.org/cgi-bin/jdk ) e o do WindowMaker ( http://windowmaker.org/cgi-bins/bugs ).

• Gnats:
  
  O Gnats pode ser encontrado em http://www.gnu.org/software/gnats/gnats.html . Trata-se de um grupo de ferramentas desenvolvido pela Gnu para o tratamento de avisos de bugs. Pode usar vários tipos de interfaces com usuário (tais como interfaces emacs, tcl/tk ou web) e ainda pode ser usado via comando de linha.

• Bugzilla:
  
  Desenvolvido pela Mozilla, o Bugzilla também é uma ferramenta para tratamento de avisos de bugs. Pode ser encontrado em http://www.mozilla.org/projects/bugzilla/ .

6. Conclusões

Ferramentas automáticas de atendimento a chamados constituem recursos importantes para se melhorar a credibilidade nos serviços de uma empresa. Estas ferramentas têm funcionamento simples e são baseadas no uso de correio eletrônico, que é uma das aplicações mais usadas durante o dia-a-dia dos profissionais de hoje. Usuários de plataformas UNIX têm a sua disposição vários sistemas gratuitos para atendimento automático de chamados e quase a totalidade deles oferece interface web, o que facilita operação e uso. Dentre estes sistemas, o Request Tracker (RT) demonstrou ser bastante simples e eficiente, o que o faz ser muito utilizado por várias empresas. Também a RNP adotou o RT como sistema de atendimento automático a chamados, e o utiliza como "front-end" para os chamados direcionados aos suportes locais de cada núcleo, para os chamados direcionados ao centro de engenharia e operações (CEO) e para registro dos chamados feitos pelo CEO junto à Embratel e à Ampath.