Atendimento ao cliente e gestão de solicitações
Acompanhar solicitações internas entre equipes
Projeto ilustrativo
Cenário ilustrativo. Os dados e cálculos são hipóteses utilizadas para explicar a aplicação.
Aplicação: Atendimento ao cliente e gestão de solicitações
Tipo de empresa: Empresa com várias unidades
Decisão principal: Quem deve atender cada solicitação, de quais informações precisa e quando o caso deve ser encaminhado a outro responsável.
O contexto e a necessidade
A empresa administra várias unidades e recebe solicitações internas de manutenção, mobiliário e serviços gerais. Os funcionários procuram pessoas diferentes; algumas solicitações se duplicam, enquanto outras passam entre departamentos sem um responsável visível. Quando alguém pede uma atualização, a Administração reconstrói conversas e procura arquivos.
A prioridade é organizar o recebimento, reunir informações suficientes e garantir o acompanhamento. Uma lâmpada quebrada, uma mudança de layout e um reparo que exige um prestador externo não deveriam seguir exatamente o mesmo processo. A equipe precisa distinguir urgência operacional, informações incompletas e decisões que envolvem gastos. Uma classificação de prioridade jamais deveria, por si só, valer como autorização de compra.
Entradas e permissões
O escopo poderia incluir formulários, uma caixa de entrada interna autorizada, um diretório de unidades, um catálogo de serviços, responsáveis, horários de trabalho e regras de atendimento. Se houver um sistema de chamados, sua integração seria avaliada. Caso contrário, seria definido um registro controlado, adequado ao volume e às necessidades de acompanhamento.
Cada solicitação precisaria de local, descrição e contato. Fotos ou documentos seriam solicitados somente quando fornecessem contexto necessário. Os funcionários veriam seus próprios casos, enquanto cada equipe veria o necessário para atendê-los. Solicitações com dados pessoais sensíveis seriam separadas e encaminhadas ao canal apropriado. As regras de acesso não seriam inferidas apenas do texto do solicitante.
O fluxo proposto
A STRTGY poderia estruturar um processo compartilhado de recebimento que sugerisse categoria e responsável, identificasse informações ausentes e reunisse registros de contexto autorizados. A solução prepararia resumos para quem recebe o trabalho e manteria um status compreensível para o solicitante. Transferências entre sistemas dependeriam de integrações e permissões confirmadas durante o desenho da solução.
Os critérios de prioridade seriam acordados com Operações. Uma possível emergência sairia do fluxo comum e seguiria o protocolo estabelecido, conduzido por pessoas. Casos ambíguos iriam para uma fila de revisão. Compras, contratação de prestadores, acesso a instalações e mudanças de segurança manteriam suas autorizações específicas. O fluxo poderia preparar informações sem substituir essas decisões.
Como um caso seria tratado
O funcionário descreve a necessidade. O recebimento registra a unidade, o local e o contato e explica quais informações faltam para o trabalho continuar.
A solução prepara uma classificação. Sugere um serviço e um responsável, mostrando quais detalhes da solicitação sustentam a proposta.
A coordenação confirma o encaminhamento. Revisa ambiguidades, duplicidades e solicitações urgentes. Possíveis incidentes críticos seguem o protocolo definido.
O responsável avalia o caso. Analisa o histórico e determina se pode atender, se precisa de uma visita ao local ou se necessita de aprovação adicional.
Uma pessoa autorizada decide. Se houver gastos ou uma intervenção restrita, analisa o caso pelo processo existente. Uma negativa devolve o caso com um motivo e um próximo passo.
A equipe de atendimento atualiza o registro. Registra o progresso e as evidências. O fluxo prepara atualizações de status para comunicação pelos canais autorizados.
O solicitante confirma o resultado. Confirma a conclusão do serviço ou explica o que ainda está pendente. O encerramento e eventuais reaberturas preservam um histórico com responsáveis identificados.
O que os usuários veriam
Os funcionários veriam o status, o responsável, a última atualização e as informações que precisam fornecer. A coordenação teria uma fila organizada por tempo em aberto e motivo do bloqueio, distinguindo casos que aguardam o solicitante, uma aprovação ou a execução. Os responsáveis teriam acesso a um resumo junto às fontes originais. A interface evitaria apresentar um prazo estimado como promessa quando ainda dependesse de uma visita ou de um prestador externo.
Ilustração fotográfica da coordenação para esclarecer o contexto de uma solicitação e confirmar quem deve atendê-la.
Entregas e implantação
O projeto poderia entregar um catálogo de serviços, regras de encaminhamento, matriz de permissões, formulários, registro de acompanhamento e cenários de teste. O trabalho começaria com uma unidade e categorias representativas, validando casos comuns e exceções. O piloto incluiria revisão humana do encaminhamento e conciliação com o sistema de origem. A expansão dependeria da aceitação das equipes responsáveis e de sua capacidade real de atendimento, sem assumir datas antes da avaliação inicial.
O que medir
Uma linha de base seria estabelecida com solicitações comparáveis, registrando também o volume que hoje chega fora do canal principal.
Atribuição correta: solicitações aceitas pelo primeiro responsável designado / solicitações atribuídas × 100.
Tempo até a atribuição: mediana de horas entre o recebimento e a confirmação de um responsável.
Solicitações abertas em atraso: solicitações abertas que excedem o critério de atendimento acordado / solicitações abertas × 100.
Transferências: número de mudanças de departamento por solicitação, excluindo etapas de aprovação planejadas.
Reabertura: solicitações reabertas / solicitações encerradas elegíveis dentro da janela acordada × 100.
Exemplo econômico hipotético
Se 400 solicitações mensais exigirem dez minutos de classificação e acompanhamento administrativo cada, totalizam aproximadamente 66,7 horas. Se um piloto verificasse seis minutos por solicitação, incluindo revisão, a diferença seria de 400 × (10 − 6) / 60 ≈ 26,7 horas. Com um custo interno hipotético de MXN 240 por hora, isso equivaleria a MXN 6.400 mensais em capacidade de trabalho, calculados antes do arredondamento das horas. O trabalho de reparo está excluído e não se pressupõe que desapareça. Custos operacionais, manutenção e investimento inicial precisam ser avaliados separadamente. Uma organização melhor também não aumenta automaticamente a capacidade dos prestadores.
Em que ponto as solicitações da sua equipe perdem andamento hoje? Vamos analisar responsáveis, canais de entrada e exceções.