Um catálogo, não uma caixa de texto vazia
Serviços e produtos são publicados como itens que se podem pedir, por isso as pessoas escolhem em vez de descrever. Voltam menos pedidos para esclarecimento porque o formulário já fez as perguntas certas.
Pedidos que se resolvem sozinhos
Publique um catálogo a partir do qual as pessoas possam realmente pedir, e deixe as regras encaminhar, aprovar e fechar os pedidos de rotina. Acessos, hardware, onboarding, um passe de estacionamento, na mesma fila dos seus incidentes.
Perguntar uma vez, na forma certa
Formulários de entrada com perguntas reais
Cada tipo de pedido leva as suas próprias perguntas, campos obrigatórios e valores por omissão, para que um pedido de portátil recolha o modelo e o centro de custo, e um de acesso o sistema e o motivo.
A aprovação como passo, não como canal paralelo
A aprovação é um estado do workflow, com o aprovador, a hora e o tempo que levou registados no pedido. Deixa de andar atrás de uma decisão que vive numa caixa de correio.
Um pedido, várias tarefas
Um onboarding nunca é um só trabalho. Um pedido ramifica-se nas tarefas que são realmente necessárias, cada uma para o seu grupo de trabalho, e fecha quando todas estão feitas.
Para onde vai o tempo de facto
- Encaminhado para o grupo certo por regra, não por um turno de triagem
- Aprovado dentro do fluxo, com o tempo de aprovação medido
- Os pedidos resolvidos registam o ativo que criaram
- Respondidos pela base de conhecimento quando não é preciso trabalho
- Fechados automaticamente quando cada tarefa por baixo está feita
A mesma fila do resto do trabalho
Um backlog entre linhas de serviço
Um passe de estacionamento, um portátil e um radiador avariado chegam ao mesmo sistema com a mesma lógica de SLA, por isso ninguém tem de saber que departamento é dono de que formulário.
SLA que respeita o seu calendário
Os objetivos dos pedidos correm no mesmo motor de SLA dos incidentes, com horário de trabalho e calendários de feriados, para que uma encomenda de sexta à tarde não apareça atrasada na segunda.
A IA responde antes de abrir
Quando a resposta já existe, a IA entrega-a e não se cria pedido nenhum. O que sobra é o trabalho que precisa mesmo de uma pessoa ou de uma encomenda.
Os custos caem onde devem
Como o item de catálogo leva o seu preço e centro de custo, os pedidos resolvidos alimentam diretamente a estrutura financeira em vez de serem reconstruídos no fecho do trimestre.
Perguntas sobre gestão de pedidos
Gestão de pedidos de serviço
É um produto separado do service desk?
Não. Os pedidos são os mesmos registos dos seus incidentes, com tipos, formulários e workflows próprios. Uma fila, um motor de SLA, um modelo de reporte.
Podemos exigir uma aprovação antes de acontecer algo?
Sim. A aprovação é um estado no workflow do pedido, por isso decide por tipo se é necessária, e o aprovador e o tempo ficam registados no registo.
Um pedido pode criar vários trabalhos?
Sim. As regras podem ramificar um pedido em tarefas, cada uma com o seu grupo de trabalho e prazo, e o pedido fecha quando a última termina. É assim que corre o onboarding.
Os utilizadores finais precisam de licença para abrir um pedido?
Não. O preço é por agente e os utilizadores finais são ilimitados, por isso abrir o catálogo a toda a organização não muda o que paga.
Transforme os seus formulários num catálogo
Agende uma primeira conversa e modelamos dois dos seus tipos de pedido durante a sessão.
Agendar uma primeira conversa