Resposta direta
Um pedido simples escala quando falta permissão, dado ou autorização de exceção, e não quando falta competência técnica. A implementação começa por separar esses três motivos em campo próprio, no registro do atendimento. Com o motivo visível, a operação define alçada por tipo de pedido, dá leitura ao atendimento dos campos que hoje exigem repasse e nomeia quem aprova exceção. O que sobra para escalonar passa a ser exceção real, com dono e registro. A revisão dos motivos, em periodicidade definida, mantém o ajuste vivo.
- Objetivo
- Orientar implementação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o escalonamento pelo motivo do bloqueio, não pelo tamanho do pedido, e diz o que ajustar em alçada, dado e exceção.
Pedido simples não é pedido fácil
Pedido simples é curto, previsível e de baixo valor, mas ainda depende de uma decisão que o atendimento não pode tomar sozinho. O escalonamento aparece quando falta permissão, dado ou autorização de exceção. Nada disso tem relação com a complexidade do pedido.
Por isso, classificar por dificuldade não ajuda. O caminho é classificar por causa do bloqueio. Uma segunda via e um pedido de desconto podem ter o mesmo tamanho e travar por motivos diferentes. Tratar os dois como caso complexo esconde a origem do desvio.
Alçada, dado e exceção como três campos do processo
Definir alçada é dizer, por tipo de pedido, até onde o atendimento decide e a partir de onde precisa de aprovação. Isso exige lista de tipos de pedido, condição de corte e o nome de quem responde por cada exceção. Sem essa lista, cada atendente cria a própria regra.
O segundo ajuste é o dado. Muitos escalonamentos existem porque o campo necessário está em outro sistema ou em outro setor. Se o atendimento tem leitura desse campo, o pedido segue sem repasse. Registrar o motivo do escalonamento em campo próprio é o que permite revisar a regra depois, com base na operação real.
O que esse ajuste não resolve
Esse ajuste não elimina o escalonamento. Exceção de política, decisão de valor e pedido fora do padrão vão continuar subindo. A meta não é zerar o repasse, e sim tirar do repasse o que já tem regra clara. Também não funciona quando o problema é de sistema: liberar permissão sem corrigir a regra de negócio só transfere o erro.
Além disso, alçada sem acompanhamento volta ao estado anterior em pouco tempo. Se ninguém revisa os motivos registrados, a exceção de hoje vira rotina e a fila de escalonamento cresce de novo. A revisão precisa de dono e de periodicidade definida, não de boa intenção.
Recurso prático
Motivo do bloqueio e ajuste correspondente
| Motivo pelo qual o pedido simples escala | Ajuste na operação |
|---|---|
| Atendente não tem permissão no sistema para concluir a ação | Definir alçada por tipo de pedido e liberar a permissão no sistema para os casos já previstos |
| Informação necessária está em outro setor e não há acesso | Padronizar o campo que falta e dar leitura ao atendimento, sem depender de pedido interno |
| Pedido foge da política vigente e exige exceção | Nomear quem aprova exceção, com prazo de resposta e registro do motivo |
| Regra escrita de forma genérica e cada pessoa interpreta de um jeito | Reescrever a regra com um exemplo de caso que aprova e um de caso que não aprova |
| Ninguém sabe quem responde depois do repasse | Definir dono por tipo de escalonamento e registrar a devolutiva no mesmo protocolo |
O erro mais comum é medir escalonamento como volume e não como motivo: sem registrar a causa, a operação trata o caso seguinte do mesmo jeito e o pedido simples volta a escalar.
Conceitos usados nesta página
- Alçada de decisão — Alçada de decisão é o limite explícito de autonomia de cada papel: o que a pessoa decide sozinha, o que decide com apoio e o que obrigatoriamente sobe para outra instância.
Sobre o que está escrito aqui
Conceitos relacionados: alçada de decisão · motivo de escalonamento · exceção de política · permissão no sistema · protocolo de atendimento. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Atendimento, relacionamento e retenção — Página central do tema
- Canais fragmentados: onde o histórico se perde — canais fragmentados
- Canais dispersos: como ordenar o fluxo de ent… — canais fragmentados
Páginas relacionadas
O mesmo problema em outro objetivo
- Pedido simples que exige escalonamento: onde investigar — Diagnosticar
- Pedido simples que exige escalonamento: onde ele trava — Organizar um processo
- Pedido simples que exige escalonamento: o que comparar — Comparar alternativas
- Pedido simples que vira escalonamento: o que medir — Explicar medição
- Pedido simples que exige escalonamento: o que contratar — Orientar avaliação e contratação
Outras leituras em Atendimento, relacionamento e retenção
- Atendente sem autonomia: o que medir além do tempo de resposta — Medição de autonomia no atendimento: tempo de espera por aprovação, motivo de escalonamento e reabertura como sinais de alçada.
- Alçada de exceção indefinida: como comparar caminhos — Compara formas de definir alçada de exceção no atendimento: decisão concentrada, matriz por valor e risco, delegação com registro e recusa de exceção.
- Atendimento fora do horário: como contratar suporte humano — Critérios operacionais para avaliar e contratar cobertura humana fora do horário comercial, analisando volume, custo de escala e autonomia de resolução.
- Atendimento humano: o que a pessoa pode decidir — Define o que sustenta o atendimento humano: alçada de decisão, preparo, informação disponível e responsável pelo caso depois do contato.
- Encaminhamento sem prazo: quatro alternativas comparadas — Quatro formas de tratar pedidos encaminhados a especialistas sem data de retorno, com critério de escolha, o que registrar em cada uma e onde elas falham.