Para além de apresentar interfaces confusas o iPTicket também apresentava bastantes limita- ções na liberdade que dava aos seus utilizadores para fazerem o que precisassem e informá-los do estado do sistema. Há várias situações em que os utilizadores eram obrigados a muito trabalho para realizar uma simples tarefa ou obter uma informação e muitas vezes isso nem lhes era pos- sível, obrigando-os a telefonar a outro assistente ou à equipa de desenvolvimento para fazerem o que pretendiam. Para resolver estes problemas foi necessário desenvolver novas funcionalidades que ajudassem o utilizador a alcançar o seu objetivo.
A primeira nova funcionalidade introduzida foi a de permitir que os utilizadores pudessem inserir de uma só vez várias assistências para um ticket. É bastante normal que os problemas que passam da equipa de suporte para a de desenvolvimento demorem algum tempo a serem resolvidos pois as alterações no código tendem a prolongar-se por vários dias. Como geralmente as assistências apenas são inseridas no final do problema estar resolvido isso levava a que o utilizador tivesse de inserir várias individualmente, o que para além de ser incomodo, pois o utilizador tinha de repetir toda a informação várias vezes, também os fazia perder bastante tempo que podia ser aplicado a ajudar clientes. A solução encontrada para este problema passou por alterar o método de inserção de datas e horas, que em vez de se aplicar apenas a um dia permite inserir vários períodos de tempo. Na figura 5.9 podemos ver o exemplo de um utilizador que realizou assistências do dia três ou dia sete de junho num período das nove às doze horas e noutro das quatorze às dezanove. No caso representado nessa figura o sistema irá criar onze assistências, as cinco primeiras para cada um dos dias no intervalo indicado, as segundas cinco aplicadas ao segundo período e a última aplicada ao dia dez de junho. Antes destas alterações, ao submeter uma assistência, o utilizador era levado para a página da mesma, o que seria impossível no caso de o utilizador introduzir várias assistências. Após as alterações é verificado o número de assistências inseridas, sendo que no caso de ser apenas uma o sistema comporta-se da mesma maneira, mas no caso de serem inseridas mais é mostrada uma lista com ligações para as várias assistências e indicado o número total introduzido. Foram feitas alterações no HTML do formulário para mudar o nome e a organização
dos vários elementos da zona de introdução das datas para dar a entender que se tratavam de períodos de tempo e que o novo método de inserção era diferente do anterior. Foram também introduzidos símbolos coerentes com o funcionamento do restante sistema para adicionar uma nova linha na tabela com o conteúdo idêntico à anterior ou remover a última linha. Todo o PHP e JS que tratava das verificações e inserções das assistências passou a funcionar em ciclos tendo em conta o número máximo a introduzir e foi necessário alterar também o funcionamento dos calendários para alterarem apenas a data do elemento a que estavam associados.
Figura 5.9: Nova funcionalidade que permite a inserção de várias assistências de uma vez.
Por vezes os administradores precisam de verificar assistências que se realizaram já há bastante tempo, pelo que os utilizadores que as realizaram podem já não trabalhar na equipa de suporte. O filtro das assistências apenas mostrava os utilizadores que estavam ativos na sua interface de gestão pelo que limitava o trabalho dos administradores em casos como o referido. Foi então necessário alterar a query da base de dados para também ir buscar os utilizadores que já não estão ativos no iPTicket. Esses utilizadores foram marcados com o texto “(inativo)” de modo a chamar a atenção do utilizador para esta facto. Na figura 5.10 podemos ver a interface do filtro após esta alteração onde o utilizador asus não está ativo.
Para existir a possibilidade de separar os tickets entre o departamento de suporte e o de desen- volvimento e permitir uma gestão diferenciada dos mesmos foi necessário criar uma funcionali- dade de criação e edição de grupos de utilizadores. A interface da listagem dos grupos existentes é acessível através da interface de inserção ou remoção de utilizadores para promover a proximi- dade. Esta listagem é em tudo idêntica à listagem dos tipos e subtipos de problemas e assistências para que os utilizadores estejam habituados ao seu funcionamento. A interface de inserção e de
Figura 5.10: Interface do filtro de assistências com utilizadores inativos.
Figura 5.11: Wireframe da interface de inserção de um novo grupo.
edição deverá conter uma caixa de texto para introduzir o nome do mesmo e duas caixas de se- leção, uma contendo todos os utilizadores do sistema e outra contendo apenas os presentes nesse grupo, como representado no wireframe da figura 5.11. Ao construir a interface final presente na figura 5.12 foram ainda adicionados botões para limpar as caixas de texto, botões que permitem gerir os utilizadores nas caixas de seleção e a funcionalidade de filtrar os nomes presentes nas caixas de seleção enquanto o utilizador escreve. Foi dada a possibilidade ao utilizador de alterar apenas os utilizadores selecionados ou todos os presentes nas caixas de seleção recorrendo a bo-
tões que indicam esse modo de funcionamento e de limpar as seleções feitas através dos ícones em forma de cruz. Mais uma vez os símbolos, os elementos e o modo de funcionamento dos mesmos tiveram em conta o restante sistema. A funcionalidade de filtrar os nomes das caixas de seleção foi obtida através de uma função de JS, que ao verificar que o valor do texto é alterado filtra as opções, mostrando apenas as que contenham o que foi inserido e a estrutura da página recorrendo a HTML. Foi ainda necessário acrescentar uma tabela na base de dados que fizesse a associação entre um grupo e os seus utilizadores sendo utilizadas funções de PHP para alterar o seu conteúdo.
Figura 5.12: Interface de gestão de grupos.
As empresas revendedoras necessitavam de melhorar o seu controlo sobre quais dos seus cli- entes tinham acesso ao seu banco de horas. Para resolver este problema foi criada uma funcionali- dade em que é possível associar vários emails do mesmo domínio a uma entidade, permitindo que introduzam ticket em seu nome. Ao receber um problema por email o filtro compara o domínio e caso seja igual ao que está associado na base de dados vai verificar se o email pertence ao grupo dos utilizadores autorizados para lhe dar permissão. Caso o email não esteja autorizado o sistema irá passar o workflow do ticket inserido para o estado final, avisando o utilizador de que não tem permissões e alertando todos os utilizadores associados de que tentaram introduzir um problema em seu nome, sendo que estes problemas não são contabilizados nos dados estatísticos. A in- terface desta funcionalidade foi colocada no final do perfil dos utilizadores na zona dos externos por uma questão de proximidade e contem um pequeno campo de texto onde é possível escrever um ou vários emails separados por virgulas, uma lista com os emails permitidos e um botão para remover os selecionados, figura 5.13. O texto de ambos os emails pode ser alterado acedendo à interface de edição dos emails automáticos presente nas configurações. Também neste caso foi necessário desenvolver uma nova tabela na base de dados para associar o número que identifica a entidade aos vários emails e ao domínio associado e as respetivas funções de PHP para a editar. O código utilizado para o editor do email automático é igual ao que já existia no iPTicket e permite ao utilizador inserir e editar o texto a enviar, a sua formatação e colocar tags com os campos a trocar pela informação especifica do problema e do utilizador. Antes de enviar o email automático
este texto irá passar por um script feito para alterar as tags pelo valor pretendido, sendo que no final do mesmo os campos do email devem estar todos corretos para se proceder ao seu envio para o utilizador.
Figura 5.13: Interface de gestão do perfil de um utilizador externo.
Para permitir que o tempo de resolução de um problema a cobrar a um cliente não fosse afetado pelo tempo que um assistente fica à espera de mais informações foi necessário desenvolver uma funcionalidade para pausar tickets. Esta funcionalidade implicou criar mais um separador na lista de ações a realizar contendo os problemas pausados onde também é possível ao administrador ver e retomar todos os que se encontram nesse estado através de um alternador, figura 5.14. Para além da informação normal das ações foi acrescentada uma coluna com o tempo em pausa e ,no caso de a interface mostrar todos os tickets pausados, a pessoa que realizou essa ação. Nas ações encaminhadas e na lista de problemas foi adicionado um ícone para realçar estes tickets. A opção de pausar o problema foi colocada na página de cada problema, figura 5.15, e contem uma caixa de seleção para o utilizador colocar uma mensagem com a razão para o ter feito, sendo esta informação mostrada no esquema cronológico. Todas as restantes ações, mudanças de workflow e realização de assistências ficam bloqueadas durante o período de pausa sendo que foram criados avisos a indicar essas limitações nas suas interfaces. Foi também criado um email automático com a informação que um determinado problema passou o limite de tempo em pausa, sendo depois reenviado passado algum tempo. Tanto o limite de tempo em pausa como o intervalo de tempo entre os emails são campos que podem ser definidos na interface das definições gerais do iPTicket e a mensagem do email é possível editar acedendo à respetiva opção das configurações. As ações de pausar e retomar um problema tiveram de ser adicionadas aos templates da base de dados e foi necessário proteger o sistema tanto nos problemas acedidos por email como pela interface web de modo a que este novo desenvolvimento não interferisse com os seus workflows. O alternador criado após o evento de mudança chama uma função de JS que recarrega a mesma página com uma flag, sendo que ao ir buscar as ações é feito por PHP uma verificação do tipo de informação
a ir buscar à base de dados.
Figura 5.14: Interface de dos tickets pausados.
Figura 5.15: Interface onde é possível pausar problema.