Comparação de funcionalidades

Basic e Professional em detalhe. O Professional inclui tudo o que está no Basic, sem limites. A tabela abaixo mostra todas as funcionalidades das duas licenças de relance.

FuncionalidadeBasicProfessional
Personalização e administração
Multilingue: podem ser ativados 30 idiomas; as traduções passam pela exportação e importação de um ficheiro JSON – assim ficas exatamente com as palavras que a tua casa entendeManual
Marca própria: logótipo, favicon, esquema de coresManual
Modo escuro / modo claro, design adaptávelManual
O formato de data e hora da tua instalação é escolha tua – ordem, separador e relógio de 24 ou de 12 horasManual
Aviso de manutenção e de avaria para toda a gente – na página de início de sessão e, se quiseres, também por e-mailManualsó na página de início de sessãopágina de início de sessão + e-mail
Aviso precoce antes de o disco encher: um aviso a partir de 90 %, um alerta a partir de 95 % – quem trata das atualizações vê os números e o que fazer, os utilizadores com sessão iniciada recebem uma frase curta; nada disto aparece na página de início de sessãoManual
Arquivo de tickets fechados (incl. reposição) – mantém o conjunto de trabalho pequeno, por exemplo passando um ano antigo para o arquivoManual
Atualizar com o carregar de um botão – o sistema faz primeiro uma cópia de segurança (dados, anexos, arquivos) e verifica se há espaço livre suficiente em disco; se não houver, recusa a atualização com um motivo em vez de falhar a meioManual
Exportar e importar as tuas listas de dados mestre em JSON – departamentos, cargos, locais e categorias; preenche-as de uma vez em vez de escrever linha a linhaManual
Equipas e utilizadores
EquipasManual1 equipaIlimitadas
Administradores e agentesManual2 utilizadores internos (1 administrador + 1 agente, ou 2 administradores)Ilimitados
Contas de clienteManualIlimitadasIlimitadas
Três funções – administrador, agente, cliente – com uma matriz de permissões livremente configurável: nenhum direito está fixado no códigoManual
Departamentos, cargos, locais (incl. traduções)Manual
Integração de e-mail
E-mail para ticket (recolha por IMAP)Manual
Envio por SMTP (notificações, resposta automática)Manual
Fluxos de trabalho de e-mail com condições e açõesManual
Cada equipa pode ter a sua caixa de correio. As mensagens para essa caixa criam um ticket nessa equipaManual
Lista de bloqueio de e-mail: bloqueia endereços soltos ou domínios inteiros – os remetentes bloqueados não criam ticket, e também não lhes é enviada respostaManual
Respostas automáticas e modelos de e-mail multilinguesManual
Autenticação e segurança, incluindo SSO
Início de sessão local (nome de utilizador/palavra-passe) + JWT; o início de sessão em dois passos (TOTP com códigos de recuperação) é opcional – desligado, obrigatório só para o pessoal interno, ou obrigatório para toda a genteManual
Proteção contra ataques de força bruta (bloqueio)Manual
SSO por OIDC (OpenID Connect) / OAuth2 e SAML 2.0 – ligação a fornecedores como Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 ou ADFS – além de LDAP / Active Directory e LINE, Kakao, Naver, WeChat, WeCom e DingTalkManual
No primeiro início de sessão por SSO, a conta é criada automaticamente (como cliente, sem ocupar um lugar de pessoal interno); cada início de sessão por SSO fica registadoManual
Gestão de tickets
Criar e editar tickets; a eliminação só acontece através do arquivoManual
Editor de texto formatado: mostra imagens embutidas e ligações (descrição e comentários)Manual
Ficheiros anexos com pré-visualização (leitor de PDF, ampliação de imagens, até 50 MB por ficheiro)Manual
Histórico do ticket / registo de auditoriaManual
Fluxo de estados com estados e transições configuráveisManual
Prioridades, estados, funções, locais, cargos e departamentos são configuráveisManual
As categorias principais e as subcategorias configuram-se livremente por equipaManual
Como o ticket entrou: o sistema deteta sozinho o portal do cliente e o e-mail (o e-mail exige Professional). O telefone e a criação por um agente são introduzidos pelo agenteManual
Pesquisa em texto integralManual
Os tickets podem ser escalados para outras equipas – o agente mantém sempre a visão de conjuntoManual
Podem criar-se campos personalizados por equipa (texto, número, data, sim/não …) e marcá-los como obrigatórios – se quiseres, apenas em modelos de ticket concretosManual
Observadores: recebem um e-mail sempre que um ticket é atualizadoManual
Estado do agente (disponibilidade)
Disponível / Ocupado / Ausente – os agentes definem-no eles próprios e, ao atribuir, toda a gente vê quem está indisponível neste momentoManual
Os administradores registam baixas ou férias, com uma data de «ausente até»Manual
«Ocupado» volta sozinho a disponível ao fim de uma horaManual
Sem histórico de disponibilidade, sem avaliação por pessoaManual
Atribuição automática de tickets
Quando está ligada: os tickets novos são atribuídos automaticamente a um membro da equipa no momento em que são criados – agente ou administradorManual
À vez ou a quem tem menos trabalho – por equipa, desligado de origemManual
Os agentes ocupados ou ausentes são saltadosManual
Vale também para os tickets vindos da caixa de correio; os tickets atribuídos por uma pessoa nunca são tocados, e cada atribuição automática fica registada no histórico do ticketManual
Relatório: quem recebeu quantos tickets – e quantas vezes não havia ninguém disponívelManual
Pedidos com tarefas e aprovação
Um pedido é um ticket que cria as suas próprias tarefas – um ticket por item, na equipa que o trata; as aprovações são possíveis, mas não obrigatóriasManual
Quem pede assinala o que precisa enquanto cria o pedidoManual
Progresso do pedido: «3 de 5 concluídos» – cada tarefa com a sua equipa, o seu responsável e um clique para o respetivo ticketManual
Uma aprovação para todo o pedido – uma mensagem em vez de muitas aprovações parciaisManual
Uma fase de aprovação adicional para tarefas isoladas e sensíveisManual
Quem aprova decide através de uma ligação com prazo enviada por e-mail. Não precisa de conta no sistema de ticketsManual
As tarefas ficam bloqueadas até a aprovação chegarManual
Lembretes para aprovações em aberto – nunca uma aprovação por decurso do prazoManual
Uma recusa chega a quem pediu, com o motivo indicadoManual
Rasto de auditoria no ticket: quem decidiu, quando e com que comentárioManual
Quem aprova está de férias? Um administrador passa o pedido a outra pessoa – todas as alterações ficam registadasManual
Modelos de resposta e de ticket
Modelos de resposta: texto + ações de campo (estado, atribuição, prioridade …) numa só escolhaManual
Ações sugeridas, desmarcáveis uma a uma antes de enviarManual
Variáveis (quem pediu, número do ticket, título …) – ao inserir o modelo, os valores reais entram no texto, antes de alguma coisa ser enviadaManual
A resposta pode ser enviada como e-mail a quem pediu – só o envio precisa do canal de correio; os anexos do modelo são acrescentados ao ticket em todas as ediçõesManual
Criar um modelo diretamente a partir de um ticket existenteManual
Os rascunhos ficam privados até serem publicados; âmbito por equipa ou globalManual
Modelos de ticket: formulário de novo ticket pré-preenchido (título, descrição, categoria, prioridade, equipa)Manual
Os modelos de ticket podem ser libertados para os clientes, um a um — um ticket que chega já qualificado pode encurtar o tempo de tratamentoManual
Cada utilização fica rastreável no histórico do ticketManual
Automatização e seguimentos
Seguimento num ticket, definido à mão (data + nota, filtros Hoje/Esta semana/Em atraso)Manual
Regras baseadas em tempo – reagir à AUSÊNCIA de uma açãoManual
Editor de regras QUANDO/SE/ENTÃO com uma frase em linguagem corrente em diretoManual
Quatro regras de exemplo incluídas (desligadas na instalação, liga as que quiseres)Manual
Pré-visualização antes de ligar: mostra que tickets a regra afetaria neste momento – sem alterar nadaManual
Ações: e-mail, estado, prioridade, atribuir, passar para outra equipa, definir um seguimentoManual
Intervalos de tempo escolhidos por condição: em horas e dias úteis do calendário da equipa – ou a correr a toda a horaManual
Registo por regra + o nome da regra como autor no histórico do ticketManual
Quota mensal de execuçõesilimitadailimitada
Ações em massa na lista de tickets
Mudar o estado de vários tickets ao mesmo tempo – mais campos através de um modelo de respostaManual
Vários tickets podem ser atribuídos a um agente de uma só vezManual
Os modelos de resposta podem ser aplicados a vários tickets ao mesmo tempo – as variáveis são resolvidas por ticketManual
Pré-visualização antes de executar e resultado depois: a quantos dos tickets selecionados a ação se aplica e porque é que alguns foram saltados – os tickets saltados ficam selecionadosManual
O e-mail a quem pediu está desligado de origem; liga-o e a janela indica quantos destinatários alcançariaManual
Cada alteração em massa aparece no histórico do ticket individual – com o nome do agente que a desencadeouManual
Relatos múltiplos e avarias
Fundir dois relatos da mesma pessoa num só ticket – os comentários, os anexos e a descrição acompanham, e nada é apagadoManual
Se alguém responder por e-mail ao número de ticket antigo, a resposta cai no ticket fundidoManual
Guarda: os tickets de pessoas diferentes não podem ser fundidosManual
Juntar muitos relatos sobre uma avaria num único incidente – cada relato mantém quem o abriu, o seu estado e o seu prazo, e uma resposta chega a todas as pessoas afetadas com o seu próprio e-mailManual
O incidente aparece como faixa de aviso e como nota na resposta automática – a faixa desaparece sozinha assim que o incidente for resolvidoManual
SLA, calendário e escalonamentos
Políticas de SLA com prazos para a primeira resposta e para a resoluçãoManual
Calendário de horário laboral por equipa (fuso horário próprio, várias janelas por dia)Manual
Feriados por importação de .ics ou introduzidos à mãoManual
O relógio para enquanto se espera por quem pediu (configurável por prazo)Manual
Tempo restante na lista de tickets – ordenável, com um filtro para prazos incumpridosManual
Em caso de incumprimento: notificar ou passar o ticket automaticamente para outra equipaManual
Métricas de SLA nos relatórios (taxa alcançada, incumprimentos, tempo médio usado)Manual
Registo de tempos por ticket
Pode ser ligado ou desligado por equipa; desligado de origemManual
Registar esforço por ticket – botões rápidos configuráveis (por exemplo 15m, 30m, 1.5h) ou introdução livre (arredondada pela regra de arredondamento, onde estiver ligada)Manual
Cronómetro no ticket – propõe o tempo decorrido e a entrada só é criada quando uma pessoa a confirma; abrir outro ticket põe-no em pausaManual
Vários agentes podem registar tempo no mesmo ticket – cada entrada traz a sua data, a sua nota e o nome do agenteManual
Faturável / não faturável por entrada – o tempo é registado uma vez; o ticket mostra os dois totais: tudo o que foi registado e a soma faturável (apenas as entradas assinaladas, depois do arredondamento)Manual
Faturar ao minuto ou arredondar para cima – configurável (intervalo e mínimo por entrada, por exemplo blocos de 15 minutos), ao minuto de origemManual
O tempo registado e o faturado ficam separados – alterar o arredondamento nunca falsifica dados passadosManual
Exigir uma entrada de tempo antes do fecho – desligado de origem; aplica-se apenas quando é uma pessoa a mudar o estado, nunca ao fecho automático, à fusão ou às ações em massaManual
Uma coluna «Time» na lista de tickets – aparece assim que houver tempo registado num ticket da listaManual
Relatório por quem pediu, equipa, categoria e campo personalizado – fatura por empresa ou centro de custoManual
Exportação das entradas individuais: CSV e Excel para a contabilidade (os dois completos) e PDF para entregar, por exemplo ao clienteManual
Os clientes nunca veem o tempo registado – o registo viaja com a fatura como exportação (recomenda-se o PDF), não para o ticket no portal do clienteManual
A repartição por agente pode ser desligada – desligada de origem, imposta no servidor em vez de apenas escondidaManual
Relatórios e painéis
Painel com o retrato atual: tickets por estado, os três casos abertos mais antigos, distribuição por agente e por categoriaManual
Um painel próprio por equipa – cada equipa vê o seu retrato, com a sua própria permissãoManual
Relatório com filtros livres – período, equipa, estado, agente, quem pediu, local, prioridade, categoria principal e subcategoria, canal, texto integral; os filtros combinam-seManual
Filtrar e agrupar também pelos teus próprios campos – empresa, centro de custo, contratoManual
As colunas que o relatório mostra são configuráveis por função – um cliente tem uma vista diferente da de um agenteManual
Os clientes podem tirar o seu próprio relatório – limitado aos seus ticketsManual
Exportação em CSV, Excel e PDF – o Excel com duas folhas (números-chave e tickets), os gráficos estão no PDFManual
O PDF imprime os números ao lado dos gráficos – uma imagem sozinha não pode ser verificadaManual
O CSV e o Excel são completos; o PDF pára nas 20 000 linhas e mostra isso no documentoManual
Inquéritos de satisfação (CSAT)
Depois de o ticket ser fechado: um e-mail com uma avaliação por estrelas, um clique é a resposta inteiraManual
Não é precisa conta de cliente – a ligação funciona sem iniciar sessão, o comentário é opcional, e a avaliação aparece no ticket para a equipa que o tratouManual
Relatório: média, taxa de satisfação e taxa de resposta – incluindo os tickets fechados a que nunca se perguntou nadaManual
A repartição das avaliações por agente pode ser desligada e está desligada de origem – a avaliação individual no ticket está sempre visível para a equipaManual
Limite configurável – de todos os tickets até, no máximo, uma vez por semanaManual
Uma má avaliação pode desencadear uma regra de automatizaçãoManual
Base de conhecimento
Mosaicos de tema com artigos em texto formatado e ficheiros anexosManual
Pesquisa em texto integral em todos os artigosManual
Visibilidade por tema: apenas interno ou virado para o clienteManual
Sugestões de solução enquanto se cria um ticketManual
Transformar um ticket num artigo com o carregar de um botãoManual
As entradas de um agente esperam pela aprovação do administradorManual
Histórico de alterações de entradas e temas (para administradores)Manual
Cópia de segurança e reposição
A instalação configura sozinha a cópia diária (23:00) – são mantidos 14 dias, 4 semanas, 12 meses, 4 trimestres e 5 anos, e as cópias que criaste à mão são mantidas para sempre; as tuas alterações ao horário sobrevivem a uma atualizaçãoManual
O agendamento é feito pelo próprio sistema operativo – o Agendador de Tarefas no Windows, o cron no Linux; sem serviço extraManual
A cópia corre sem ninguém com sessão iniciada – o cron no Linux e, no Windows, um serviço que também arranca com a máquina sem sessão; nunca é pedida a palavra-passe do WindowsManual
A cópia abrange tudo o que forma o estado: a base de dados, os ficheiros anexos, o arquivo e as chaves que decifram as credenciais guardadasManual
Uma reposição traz, por isso, tudo de volta. Regra geral, o sistema volta a estar operacional pouco depoisManual
Uma aplicação dedicada à cópia de segurança e à reposição, para Windows e Linux, com atalho no ambiente de trabalho – criar uma cópia, percorrer a lista, reporManual
Num servidor sem ambiente de trabalho, as mesmas funções como comandos – guardar, listar, repor, definir o horárioManual
As cópias ficam na mesma máquina – protegem contra enganos e outros problemas, não contra a avaria de um disco; para o pior dos casos, guarda também os ficheiros de cópia noutro sítioManual
Antes de cada atualização, o sistema faz uma cópia adicional própria – independente do horárioManual

incluídonão incluídoTodas as informações se referem à versão atual 1.x.

Um olhar mais atento

Funcionalidades em que uma única linha de tabela não diz o suficiente.

Pedidos com tarefas e aprovação

Professional

Alguns pedidos não são um pedido, são meia dúzia. «Entra um colega novo na segunda-feira» significa: conta Windows, caixa de correio, acesso ao ERP, telefone, cartão de acesso — cada um tratado por uma equipa diferente, cada um com o seu responsável, e a chefia tem de dizer que sim primeiro. Hoje alguém escreve isso cinco vezes e depois anda atrás do assunto de sala em sala. Aqui defines o fluxo uma vez: quem pede preenche um formulário, o sistema cria os tickets individuais nas equipas certas, recolhe a aprovação e mostra-te num único sítio o que já está feito.

Um pedido, muitas tarefas

Cada item torna-se um ticket próprio — na equipa que o trata, com o seu responsável, o seu tempo de execução e as suas instruções. Duas tarefas podem ir para a mesma equipa: um centro de serviços que trata de três aplicações recebe três tickets, não um com três pontos. O pedido em si mostra «3 de 5 concluídos», cada linha salta para o seu ticket, e o pedido é o último a fechar.

Quem pede escolhe O QUE precisa, não quem o faz

Para cada tarefa decides se corre sempre, se vem pré-selecionada ou se tem de ser assinalada de propósito. No formulário, quem pede vê apenas uma lista do que pode encomendar — a tua estrutura de equipas fica de fora. E «que aplicação pertence a que equipa» não obriga a manter um segundo conjunto de dados mestre: está na própria tarefa.

Uma aprovação, não oito

A aprovação pertence ao pedido, não a cada tarefa. Oito contas pedidas dão, por isso, um e-mail à chefia em vez de oito — é exatamente aí que fluxos destes costumam morrer no dia a dia. Se uma tarefa sensível precisar também do sim de um departamento especializado, acrescentas uma segunda fase só a essa tarefa. As duas são perguntadas ao mesmo tempo e, se o departamento disser que não, só a sua tarefa é afetada; o resto continua.

A chefia não precisa de conta

Recebe um e-mail com uma ligação, vê quem pediu e que tarefas estão abrangidas, e decide com um clique — sem iniciar sessão e sem ocupar um lugar de agente. O e-mail leva de propósito apenas essa ligação e nenhum endereço de «aprovar» já pronto: os antivírus e os serviços de pré-visualização abrem todos os URL de uma mensagem, e uma aprovação criada assim seria indistinguível de uma verdadeira. Recusar exige um motivo, e quem pediu fica a saber qual foi.

Nada acontece antes da libertação

As tarefas aparecem logo, para que as equipas especializadas vejam o que aí vem — mas estão bloqueadas, ninguém está atribuído a elas e não podem ser movidas enquanto faltar a aprovação. Isso é imposto no servidor, não apenas esbatido no ecrã: as ações em massa e as regras de automatização também não têm forma de contornar. Se ninguém reagir, sai um lembrete — não há aprovação por decurso do prazo, porque é exatamente isso que um auditor contesta mais tarde.

Quem decidiu e quando fica registado

Cada fase é listada no pedido com o aprovador, a data e hora e o comentário — o rasto de auditoria que leva as empresas a introduzir fluxos destes. Ninguém pode aprovar em nome de outra pessoa, nem sequer um administrador. Para as férias há a reatribuição: um administrador envia o pedido em aberto a um substituto, a ligação antiga morre de imediato e o histórico regista quem o passou de quem para quem, e quando.

Vê no manual

Modelos de resposta e de ticket

Basic e Professional

A décima reposição de palavra-passe da semana não precisa de uma resposta escrita de novo — precisa da boa resposta que a tua equipa já escreveu, enviada em segundos e sem os erros que aparecem às quatro da tarde. Um modelo de resposta preenche o texto E a rotina que o acompanha: definir o estado, atribuir a mim, pôr um seguimento. O botão de enviar continua a ser teu.

O texto e a rotina à volta dele, numa só escolha

Um modelo não cola apenas texto. Sugere as alterações de campos que acompanham sempre essa resposta: estado para Resolvido, prioridade para baixo, atribuir a mim, seguimento daqui a três dias. Cada sugestão aparece como um selo próprio e pode ser riscada individualmente — este ticket é quase o caso padrão, só que desta vez ainda não o queres fechar.

Nada é enviado até seres tu a enviar

Escolher um modelo apenas preenche o editor. O texto fica à tua frente, editas e envias com o mesmo botão de sempre. Uma macro que dispara de imediato envia a resposta errada a um cliente real assim que erras o clique — e um e-mail não se pode desenviar. Este segundo a mais é intencional.

Variáveis em que podes confiar

Escreve «Olá {requesterName}» uma vez e cada aplicação preenche a pessoa certa, o número do ticket, o título, o teu nome. É resolvido no momento em que escolhes o modelo — por isso, o texto final é o que vês no editor, não uma surpresa na caixa de entrada do cliente. Uma variável mal escrita é recusada ao guardar o modelo, não descoberta pelo cliente.

A resposta chega por e-mail a quem pediu

Basta um visto e o teu comentário sai como e-mail para a pessoa que está por trás do ticket, que o sistema descobre por ti. Os anexos guardados no modelo são acrescentados ao ticket ao mesmo tempo: põe lá o PDF com as instruções uma vez, em vez de o procurares sempre na pasta de transferências.

Os bons modelos nascem de respostas reais

O melhor modelo é a resposta que acabaste de escrever. Um clique num comentário transforma-o num rascunho de modelo — com o texto preenchido e com o nome, o endereço e os ficheiros do cliente deixados de fora de propósito. Dás-lhe um nome, lês uma vez com olhos frescos, e só então passa a existir. Até o publicares, mais ninguém o vê.

Modelos de ticket: tickets recorrentes sem escrever tudo

A entrada de um novo colaborador, o abate de um equipamento, a chamada telefónica — alguns tickets são criados vezes sem conta com a mesma forma. Um modelo de ticket preenche o formulário: título, descrição, categoria, prioridade, equipa responsável. O agente acrescenta o que é específico e submete. Nada é criado antes disso.

Conhecimento da equipa, não uma gaveta privada

Os modelos pertencem a uma equipa ou a toda a gente, não à gaveta de uma pessoa. Quando alguém sai, as suas melhores respostas ficam. E cada aplicação fica registada no histórico do ticket: semanas depois ainda vês que um ticket foi resolvido com a resposta padrão, e com qual delas.

Incluído nas duas edições

Os modelos estão totalmente incluídos no Basic — sem limite de quantidade e sem nada guardado para a edição superior. As ferramentas que poupam mais tempo à tua equipa no dia a dia não devem estar atrás de uma barreira de pagamento.

Vê no manual

Automatização e seguimentos

Professional

Num helpdesk, a maioria das coisas corre mal não porque alguém fez a coisa errada, mas porque ninguém fez nada. Um ticket espera por uma resposta que nunca chega; um pedido fica sem responsável durante a hora de almoço; um caso é resolvido e depois simplesmente esquecido. A automatização reage exatamente a isso — à ausência de uma ação. Verifica a cada minuto e faz o que tu terias feito, se tivesses reparado.

Quatro regras já estão lá — desligadas

Não começas com um ecrã vazio. O sistema traz quatro exemplos que cobrem os casos do dia a dia: lembrar quem pediu ao fim de três dias úteis de silêncio; fechar um ticket ao fim de dez dias sem qualquer resposta; subir a prioridade de um ticket que ninguém pegou em quatro horas de trabalho; e pôr um seguimento em tudo o que não teve atividade durante uma semana. As quatro estão desligadas. Liga uma, ajusta os números ou usa-a como ponto de partida para a tua.

Escolhes, não escreves

Todos os valores vêm dos teus próprios dados: os teus estados, as tuas prioridades, as tuas equipas, as tuas categorias — escolhidos numa lista. Não há um campo onde escrevas o nome de um campo, não há linguagem de consulta, não há expressão cron. Uma regra lê-se QUANDO alguma coisa não acontece há algum tempo, SE o ticket for assim, ENTÃO faz aquilo.

A regra diz-te em linguagem corrente o que vai fazer

Por cima do editor, uma frase acompanha as tuas escolhas: «Quando um ticket tem o estado Waiting for User Response e não tem resposta de quem pediu há mais de 3 dias úteis, então envia um e-mail a quem pediu.» Lê-a antes de ligares seja o que for. Essa única frase apanha a configuração errada que, de outro modo, só notarias num ticket de cliente já fechado.

Vê quem seria afetado — antes de o ser

Cada regra tem um botão «que tickets seriam afetados neste momento?». Recebes a lista e mais nada acontece: nenhum e-mail, nenhuma mudança de estado, nem sequer uma entrada no registo. É este o passo que faz a diferença entre experimentar e nunca se atrever.

Um lembrete não se transforma numa enxurrada

«Sem resposta há 24 horas» volta a ser verdade a cada minuto a partir da hora 24 — construído de forma ingénua, são 1440 e-mails por dia. Por isso, uma regra dispara uma vez por situação e depois fica quieta. Só volta a disparar depois de a condição ter desaparecido e voltado a ocorrer: o cliente responde, volta o silêncio, e só então sai o lembrete seguinte.

Contam as horas de trabalho, não os dias de calendário

«Três dias úteis» usa o mesmo calendário de horário laboral que os teus prazos, por equipa — um ticket de sexta-feira à noite não está atrasado na segunda de manhã. Se preferires contar tempo decorrido, também existem minutos, horas e dias. É uma escolha por condição, não uma definição global.

Nunca há uma quota de execuções

Alguns sistemas cobram a automatização por execução: uma dotação mensal e, assim que se esgota, todas as tuas regras param até ao dia 1 do mês seguinte. Aqui não existe esse contador. Os únicos limites são travões de segurança por ticket, para que uma regra não acorde outra em ciclo — existem para proteger os teus tickets, não para te medir.

Nada acontece de forma invisível

Cada ação é escrita no histórico do ticket com o nome da regra que a provocou, para que ninguém tenha de se perguntar porque é que um ticket se fechou sozinho. Cada regra guarda também o seu próprio registo: que ticket, quando e qual foi o resultado, incluindo as falhas. E se uma licença caducar, as regras ficam exatamente onde estão e limitam-se a parar; a página diz isso em vez de emudecer.

Os seguimentos manuais estão em todas as edições

Pôr uma data e uma nota curta num ticket para o trazer de volta mais tarde — «voltar a ligar na quinta-feira» — faz parte do Basic, incluindo os filtros Hoje / Esta semana / Em atraso na lista de tickets. Quem faz o pedido nunca vê isso. O Professional é o passo entre os teus agentes definirem seguimentos e o sistema defini-los por ti.

Vê no manual

Relatos múltiplos e avarias

Basic e Professional

Duas situações que na caixa de entrada parecem iguais e têm de ser tratadas de formas completamente diferentes. Uma: a mesma pessoa relata o mesmo problema duas vezes, uma por e-mail e outra por telefone, porque não tinha a certeza de que o e-mail tinha chegado. A outra: falha um switch e, em quinze minutos, há trinta relatos de trinta pessoas diferentes. Há um caminho para cada uma, e são de propósito dois caminhos diferentes.

A mesma pessoa, dois tickets

Assinalas as duas linhas e decides qual o ticket que fica — o mais antigo vem pré-selecionado, para que o prazo corra a partir do primeiro contacto e não da segunda tentativa. Os comentários, os anexos e a descrição do segundo passam para o primeiro; nada se perde. Antes de confirmares, é-te dito por escrito: «#124 será fechado e passado para #122.»

Uma avaria, trinta relatos

Agrupas os trinta tickets sob um único ticket de incidente. Cada um deles mantém quem o abriu, o seu estado e o seu prazo — nenhum desaparece. Os retardatários podem ser acrescentados um a um, e a quem abrir um ticket novo enquanto o incidente está a decorrer é oferecida a ligação, em vez de ter de a procurar.

Porque é que estas duas coisas não são a mesma

Se simplesmente fundisses esses trinta relatos, vinte e nove pessoas perderiam o seu ticket e nunca mais saberiam de nada. E como vinte e nove casos seriam fechados sem nunca terem recebido resposta, os teus números pareceriam depois melhores do que a realidade. Por isso o sistema verifica quem está por trás de cada ticket: se forem pessoas diferentes, nem sequer oferece a fusão e encaminha-te para o incidente.

Responder uma vez em vez de trinta

Assim que a causa estiver resolvida, escreves a solução uma única vez. Cada ticket ligado recebe-a como comentário e é fechado, e cada pessoa afetada recebe o seu próprio e-mail — sem lista de distribuição e sem que ninguém veja o endereço de outra pessoa. Se alguém ainda assim responder, é reaberto o seu ticket, não o incidente inteiro.

Ninguém perde o seu número de ticket

Um relato fundido nunca é apagado. Se quem o abriu responder ao e-mail antigo semanas depois, a resposta continua a encontrar o ticket certo — quer responda à mensagem, quer deixe o número antigo no assunto, ou ambos. Caso contrário, acreditaria que a sua resposta tinha chegado enquanto ela ficava num caso fechado para onde ninguém olha.

O aviso desaparece sozinho

Um incidente pode ser anunciado com um visto: passa a aparecer para toda a gente como faixa de aviso e como nota na resposta automática — quem relata por e-mail nunca vê uma página de início de sessão. Quando o resolves, a faixa desaparece por si. Uma janela de manutenção anunciada para sábado fica visível ao lado, em vez de ser posta de parte.

Vê no manual

SLA, calendário e escalonamentos

Professional

Um SLA é uma promessa: «respondemos a um pedido em duas horas e resolvemo-lo em oito». O sistema de tickets desmonta essa promessa, põe um relógio em cada ticket correspondente e diz-te quanto tempo falta — antes de o prazo passar, não depois.

Os prazos só correm durante o teu horário de trabalho

Um prazo de oito horas que começa numa sexta-feira à tarde não pode expirar no sábado de manhã. Por isso, cada prazo está ligado a um calendário de horário laboral: horas de funcionamento por dia da semana, fuso horário próprio, várias janelas por dia para pausas de almoço ou turnos partidos — incluindo turnos noturnos que passam da meia-noite. Cada equipa pode ter o seu próprio calendário; noites, fins de semana e feriados não contam.

Os feriados decides tu, não nós

Os feriados dependem do sítio onde estás, não da língua que usas — 16 estados alemães, 26 cantões suíços, 50 estados dos EUA. Em vez de entregarmos uma lista que mais tarde estará errada para a tua região, importas o ficheiro .ics oficial do teu local ou introduzes os dias à mão. A importação diz-te depois quantos dias foram assumidos e quantos foram ignorados. Se um calendário não tiver um único dia fechado nos próximos doze meses, a página de definições avisa — caso contrário o sistema calcularia em silêncio por cima de todos os feriados.

O que conta como resposta — e o que não conta

É aqui que a métrica significa alguma coisa ou não significa nada. O relógio da primeira resposta só para com um comentário público escrito por um agente. A confirmação automática não conta, as notas internas não contam, e o e-mail que chega do cliente muito menos. Construído de outra maneira, todos os prazos seriam «cumpridos» em segundos e os teus relatórios mostrariam 100 % permanentes quando, na verdade, ninguém tinha respondido.

À espera do cliente, o relógio para

Quando fazes uma pergunta e ficas à espera de quem pediu, o prazo deixa de correr — não pagas por tempo de espera que não controlas. Se um prazo faz pausa é definido por meta, porque a resposta não é forçosamente a mesma para «primeira resposta» e para «resolução». Se um ticket resolvido for reaberto, começa um novo ciclo; o antigo fica registado para os relatórios em vez de marcar logo o ticket como incumprido.

Quando um prazo é ultrapassado

Decides por prazo o que acontece: apenas registar, notificar quem tem o ticket e quem o observa, ou passar o ticket automaticamente para outra equipa — o clássico escalonamento do 1.º para o 2.º nível. A passagem não é a opção predefinida de propósito, porque muda a responsabilidade e liberta quem tinha o ticket; isso não deve apanhar ninguém de surpresa logo no primeiro incumprimento. O que escolheres corre exatamente uma vez, mesmo depois de um reinício.

Que prazo se aplica a que ticket

Crias políticas e colocas-las por ordem; a primeira que corresponder ganha. As condições são a equipa, a prioridade e a categoria — listas pendentes, não uma linguagem de consulta que tens de aprender primeiro. Um campo vazio significa «qualquer um», não «nenhum»: uma política sem equipa aplica-se a todas as equipas.

O que vês depois

O tempo restante na própria lista de tickets, ordenável por «expira primeiro» e filtrável por «incumprido», além do prazo no próprio ticket. Os relatórios mostram a taxa de cumprimento, o número de incumprimentos e o tempo médio usado por prazo. A taxa conta apenas prazos já decididos — os que ainda correm não a diluem, caso contrário todas as promessas recém-introduzidas pareceriam desastrosas ao início e melhorariam sozinhas.

Até criares uma política, nada muda

Sem uma política ativa não há relógio, não aparece nenhuma coluna adicional e os teus tickets existentes ficam exatamente como estão. Nenhuma meta predefinida, nenhum caso antigo incumprido de um dia para o outro. Os tickets sem prazo mostram um traço neutro, não «incumprido».

Vê no manual

Registo de tempos por ticket

Professional

Quem fatura esforço precisa de o registar onde ele acontece: no caso. Um agente escreve «20» ou carrega num botão predefinido e, no fim do mês, os totais estão prontos por cliente, centro de custo ou contrato — como tabela no ecrã e como CSV para a fatura. O que isto de propósito NÃO é: um relógio de ponto. Regista o esforço num caso, nunca a assiduidade de uma pessoa.

Escrever é mais rápido do que qualquer cronómetro

O caminho principal é a entrada rápida: quatro botões livremente configuráveis e um campo que entende «90», «1.5h» e «1h 30m» da mesma maneira. Num caso de três minutos, dois cliques num cronómetro custam mais do que o próprio número. Se as tuas sessões forem longas, liga também o cronómetro — ele propõe, e nada é guardado até uma pessoa confirmar.

Registado e faturado são coisas separadas

Defines livremente o intervalo de arredondamento e o mínimo — em blocos de 15 minutos, 17 minutos tornam-se 30. Mas só o valor faturado é arredondado, sempre por entrada, nunca sobre o total. O que foi realmente trabalhado fica intacto, para que possas mudar o arredondamento mais tarde sem que os meses passados se alterem.

Fatura por empresa, centro de custo ou contrato

O relatório agrupa o tempo por quem pediu, por equipa, por dia — e por qualquer campo personalizado que tenhas criado. Assim faturas exatamente pelo termo que a tua organização usa, e não por um que nós inventámos. A página mostra os maiores grupos e avisa quando corta a lista; a exportação em CSV das entradas individuais nunca é cortada, porque um total de fatura tirado de uma lista encurtada não está incompleto, está errado.

O período diz respeito ao trabalho, não ao ticket

Um ticket de junho em que se trabalhou em julho pertence à fatura de julho com essas horas. É exatamente assim que o relatório corta: pela data da entrada, não pela data de criação do ticket. Parece óbvio, e é precisamente o ponto em que uma fatura mensal falha em silêncio.

Vários agentes, tudo rastreável

Cada entrada tem data, autor, nota e a marca de faturável. Quem pode alterar as entradas de outras pessoas e quem as pode corrigir depois do fecho são direitos separados, porque quem muda o tempo dos outros muda as faturas dos outros. Quando dois tickets são fundidos, o tempo vai com eles; não deve ficar para trás no ticket gémeo que foi fechado.

A avaliação por agente pode ser desligada

O tempo por pessoa é um dado de desempenho e de comportamento. Por isso a repartição por agente é um interruptor próprio, desligado de origem — e o bloqueio está no servidor, não apenas no ecrã. Nos fornecedores de nuvem esta avaliação não se pode desligar de todo; para uma organização com comissão de trabalhadores, essa é a diferença entre avançar e ter de negociar primeiro.

Os teus clientes não veem o tempo

De origem, o esforço registado fica interno. «Cinco minutos, para isto?» é uma discussão que ninguém quer, e só começa porque o número estava à vista. Se quiseres o contrário, liberta o campo de propósito; a predefinição não decide isso por ti.

Ligável e desligável, também por equipa

O registo de tempos está desligado de origem — se não precisares dele, não vês campo, nem coluna, nem mosaico. Depois de ligado, todas as equipas participam e vais excluindo as que quiseres: a equipa de TI interna não precisa de registar, a equipa de serviço ao cliente precisa. Se quiseres, torna obrigatória uma entrada de tempo antes do fecho; os fechos automáticos ficam de fora, caso contrário haveria tickets que ninguém consegue fechar.

Vê no manual

Inquéritos de satisfação (CSAT)

Professional

No fim, só uma pessoa sabe se o teu helpdesk fez um bom trabalho: aquela que foi ajudada. Depois de um ticket ser fechado, recebe um e-mail com cinco estrelas — um clique e está feito. A avaliação vai depois para onde pertence: para o ticket, para a frente de quem fez o trabalho e para o relatório como número. Os inquéritos estão desligados até os ligares; decides tu se e quando alguém é perguntado.

Um clique, não se pergunta mais nada

O e-mail leva cinco estrelas como ligações. Clicar na terceira é a resposta inteira — sem conta, sem iniciar sessão, sem um formulário repartido por dois ecrãs. Quem quiser pode acrescentar uma frase na página seguinte, e essas frases costumam ser a parte mais interessante de todo o relatório. Um clique na estrela errada pode ser corrigido enquanto a ligação for válida.

A taxa de resposta está ao lado da média

Um 4,6 não significa nada enquanto ninguém escrever ao lado que assenta em doze respostas em quatrocentas. Por isso o relatório mostra os dois números — e junto deles o número de tickets fechados a que nunca se perguntou nada. Um número que esconde a sua própria amostra vale menos do que nenhum número.

Medir sem vigiar o pessoal

As avaliações por pessoa são dados de desempenho e de comportamento — em muitas empresas, um assunto da comissão de trabalhadores. Aqui, avaliar por agente é um interruptor separado, desligado de origem, e é imposto no servidor: desligado significa desligado, também na exportação. A avaliação no ticket individual continua visível, porque quem tratou do caso é a primeira pessoa que pode aprender com ela.

Ninguém fica soterrado

Cada ticket é inquirido no máximo uma vez. A frequência com que a mesma pessoa pode ser perguntada depende de ti – de origem, no máximo uma vez em sete dias: quem relata cinco coisas numa manhã recebe assim um e-mail em vez de cinco. Um balcão com muitos remetentes diferentes põe o limite a zero e pergunta em cada ticket. Se um ticket for reaberto pouco depois de fechado, não sai nenhum — a pergunta só chega quando o caso estiver mesmo terminado.

Uma avaria não distorce o número

Os relatos ligados a um incidente coletivo não são inquiridos, de propósito. Um clique em «incidente resolvido» dispararia duzentos inquéritos sobre um único trabalho, e o mês acabaria por descrever a avaria em vez do teu serviço. Pergunta-se sobre o incidente; às duzentas pessoas afetadas não.

Uma má avaliação é um caso, não um dado

Uma estrela não pertence ao resumo da semana seguinte — pertence à secretária no próprio dia. Uma regra de automatização pode reagir assim que a avaliação chega: subir a prioridade, atribuir ao responsável da equipa, enviar um e-mail. O mesmo motor de regras, o mesmo tratamento; a avaliação é apenas mais uma condição.

A ligação dá direito a avaliar, não a ler

A página do inquérito mostra o número e o título do ticket e mais nada — sem descrição, sem comentários, sem anexos. Ligações destas são reencaminhadas ou vão parar a uma caixa de correio partilhada; quem a tiver pode avaliar, não ler o caso. Ao fim de 30 dias caduca e, visto de fora, caducada e desconhecida têm exatamente o mesmo aspeto.

Os antivírus também não avaliam

Uma ligação de estrela que conta a simples abertura é clicada automaticamente pelos verificadores de ligações dos grandes fornecedores de correio — a pontuação seria pura invenção e indistinguível na base de dados de respostas reais. Aqui, abrir a ligação apenas mostra a página; nada é guardado enquanto não estiver uma pessoa à frente dela. Para essa pessoa, continua a ser um só clique.

Vê no manual