Ciclo de vida da solicitação do cliente: mapeie antes de criar as telas

Por que as telas falham sem um mapa de solicitações

Um formulário de solicitação bem elaborado ainda pode criar um processo confuso. Muitas equipes escolhem primeiro campos, botões e painéis, e só depois percebem que ninguém definiu o que acontece depois que um cliente clica em «Enviar».

As telas mostram momentos isolados. O ciclo de vida de uma solicitação do cliente mostra o caminho completo: onde a solicitação chega, quem a analisa, o que essa pessoa decide, quando o trabalho começa e o que significa encerrá-la. Sem esse mapa, cada tela pode fazer sentido por si só, enquanto o trabalho entre elas continua indefinido.

Pense em um formulário de suporte com um status chamado «Em andamento». Isso significa que alguém leu a solicitação, atribuiu a tarefa, entrou em contato com o cliente ou começou o trabalho de fato? Os funcionários podem usar o mesmo rótulo de maneiras diferentes. O cliente vê pouco progresso, e os gestores não conseguem saber onde as solicitações estão paradas.

Começar pelas telas também esconde os encaminhamentos. Uma solicitação pode passar do suporte para o faturamento e depois para um gerente de contas. Se a equipe não definir quem é o responsável em cada etapa, todos podem presumir que outra pessoa vai agir. As solicitações ficam na fila compartilhada até que o cliente faça um novo contato.

O mapeamento do fluxo de solicitações revela essas lacunas antes do início do design da interface. A equipe precisa decidir:

• Que informação inicia a solicitação?
• Quem é responsável pela próxima ação?
• Que estados podem seguir cada decisão?
• Quando um prazo começa, é pausado ou termina?
• Quem precisa receber uma notificação quando a solicitação muda?

O mapa também evita painéis enganosos. Uma contagem de solicitações «abertas» diz pouco se incluir itens novos, solicitações que aguardam informações do cliente e tarefas bloqueadas por outra equipe. Estados separados dão à equipe uma linguagem comum e oferecem ao cliente uma atualização mais honesta.

O mapa não precisa ser complicado. Ele precisa descrever o trabalho que as pessoas realmente fazem, incluindo informações ausentes, solicitações rejeitadas e casos reabertos. Quando o caminho está claro, fica mais fácil criar as telas, porque cada página tem uma função específica: coletar informações, ajudar o responsável a agir ou mostrar ao cliente em que ponto está a solicitação.

Comece com uma solicitação e um resultado claro

Comece pela solicitação que sua equipe recebe com mais frequência. Pode ser um pedido de reembolso, um relato de entrega danificada ou uma solicitação de alteração de dados da conta. Não tente mapear todas as necessidades dos clientes em um único diagrama. Mapas muito abrangentes ficam vagos rapidamente.

Escreva o evento inicial em linguagem simples. Por exemplo: «Um cliente envia pelo formulário de suporte uma solicitação de reembolso de um pedido». Isso define quando o ciclo de vida começa. Também evita uma discussão comum mais tarde: a solicitação começa quando o cliente a envia, quando o suporte a lê ou quando alguém cria um chamado?

Depois, defina o ponto final dos dois lados. Uma solicitação de reembolso concluída significa que o cliente recebeu uma decisão clara e, se o pedido foi aprovado, a equipe de pagamentos emitiu o reembolso. A equipe de suporte também precisa registrar a decisão, o motivo, o valor e a data. Esses detalhes são mais importantes do que uma tela que mostra «Concluído».

Mantenha o resultado separado da interface. «Mostrar uma mensagem verde de sucesso» descreve uma tela. «O cliente recebe uma confirmação com o valor do reembolso e a data prevista do pagamento» descreve o trabalho que precisa acontecer. A tela pode mudar durante uma reformulação. O trabalho por trás dela deve continuar igual, seja o cliente usando um portal web, um aplicativo móvel ou o e-mail.

Uma definição curta costuma revelar regras ausentes antes do início do design:

• Tipo de solicitação: reembolso de um pedido pago
• Início: o cliente envia um formulário ou entra em contato com o suporte
• Fim: o cliente recebe uma decisão de aprovação ou recusa, e a equipe a registra
• Exceção: o suporte solicita os dados do pedido que estão faltando antes de tomar uma decisão

Suponha que um cliente relate uma cobrança duplicada na segunda-feira. A solicitação só deve terminar depois que a equipe confirmar se a cobrança foi duplicada, enviar a decisão e registrar qualquer reembolso. Fechar o chamado depois da primeira resposta deixa o trabalho real sem solução.

Quando esse caminho tem um início e um fim precisos, a equipe pode acrescentar estados, responsáveis, prazos e notificações sem fazer suposições. Mais tarde, o AppMaster pode transformar esse mapa em processos de negócio e telas, mas o mapa deve definir o trabalho primeiro.

Liste os estados que uma solicitação pode assumir

Um estado informa a todos em que ponto a solicitação do cliente está. Mantenha a lista concentrada em momentos importantes do trabalho, em vez de registrar cada pequena ação. Ao ler um status, os funcionários devem saber o que precisa acontecer em seguida.

Uma solicitação típica de suporte ou serviço pode incluir estes estados:

• Nova: o sistema recebeu a solicitação, mas ninguém a analisou.
• Em análise: um membro da equipe verifica os detalhes e decide como tratá-la.
• Aguardando o cliente: a equipe precisa de uma resposta, arquivo ou confirmação do cliente.
• Em andamento: alguém aceitou o trabalho e está agindo sobre ele.
• Aguardando aprovação ou trabalho externo: o progresso depende de um gestor, fornecedor, provedor de pagamentos ou outra parte.
• Resolvida: a equipe concluiu o trabalho solicitado.
• Fechada: o cliente aceitou o resultado, ou a equipe fechou a solicitação após o período definido.

Use nomes que correspondam à linguagem já usada pelas pessoas. «Aguardando o cliente» é mais claro do que «Aguardando informações». «Em andamento» costuma ser mais claro do que «Ativa». O cliente não deveria precisar consultar um glossário interno para entender o status exibido no portal.

Os estados de espera exigem atenção especial. Eles separam o trabalho que sua equipe pode fazer hoje daquele que depende de outra pessoa. Uma solicitação de reembolso pode passar de «Em análise» para «Aguardando o cliente» quando é necessário que o cliente forneça um comprovante. Se um gerente financeiro precisa aprovar o valor, ela passa para «Aguardando aprovação». Esses atrasos precisam de lembretes e regras de prazo diferentes.

Evite rótulos duplicados. «Aberta», «Atribuída» e «Sendo tratada» muitas vezes descrevem a mesma situação geral. Mantenha um único estado, a menos que cada rótulo mude o responsável, a ação da equipe ou o prazo aplicável. Menos estados e transições mais claros também tornam os relatórios mais confiáveis.

Teste cada solicitação com uma pergunta simples: ela pode estar em dois status ao mesmo tempo? Se a resposta for sim, os nomes podem estar se sobrepondo. Revise-os até que cada status descreva uma condição clara.

Desenhe as transições e defina quem as aciona

O nome de um estado não explica um fluxo de trabalho por si só. Registre como a solicitação muda, quem pode fazer essa mudança e o que precisa ser verdade antes que ela aconteça. Assim, um botão da tela não muda a solicitação no momento errado.

Escreva cada transição como uma frase simples. Por exemplo: «Um agente de suporte move uma solicitação de Nova para Em análise depois de verificar se o cliente incluiu o número do pedido». A frase informa a ação, o responsável e a condição.

Um mapa simples pode incluir estas mudanças:

• O cliente envia uma solicitação, que é criada com o estado Nova.
• Um agente de suporte a atribui a um especialista e muda seu estado para Em análise.
• O especialista muda o estado para Aguardando o cliente quando faltam detalhes.
• Uma resposta do cliente faz a solicitação voltar para Em análise.
• O especialista marca a solicitação como Resolvida depois de concluir o trabalho.
• O cliente ou o líder de suporte fecha a solicitação após a confirmação.

Defina o responsável autorizado para cada seta. «Equipe» é vago demais. Use funções como cliente, agente de suporte, especialista de faturamento, líder de equipe ou automação. Uma regra do sistema também pode acionar uma mudança. Por exemplo, a automação pode mover uma solicitação de Aguardando o cliente para Fechada depois de 14 dias sem resposta, se isso estiver de acordo com sua política.

As exceções precisam de transições próprias. O cliente pode cancelar uma solicitação Nova, mas não uma que já foi concluída. Um líder de equipe pode reabrir uma solicitação Fechada se o problema voltar. Um agente pode mover uma solicitação de Em análise de volta para Nova somente quando alguém a tiver atribuído por engano. Essas regras protegem a responsabilidade pela solicitação e explicam por que algumas mudanças de status não estão disponíveis.

Desenhe o caminho com caixas e setas antes de criar as telas. Procure ciclos que nunca terminam, como duas funções enviando repetidamente uma solicitação de volta uma para a outra. Verifique também os becos sem saída. Se uma solicitação entrar em Aguardando aprovação, defina quem aprova e o que acontece depois da aprovação ou da recusa.

No AppMaster, o mapa pode depois se transformar na lógica dos processos de negócio, enquanto as funções controlam quais ações cada usuário vê. Mantenha o mapa legível o suficiente para que um novo membro da equipe consiga acompanhar uma solicitação desde o envio até o fechamento.

Atribua responsáveis a cada encaminhamento

Uma solicitação precisa de um responsável definido sempre que o trabalho estiver ativo. Essa pessoa não precisa concluir todas as tarefas sozinha. Ela precisa saber o status atual, fazer a solicitação avançar e responder quando alguém pedir uma atualização. A responsabilidade compartilhada muitas vezes significa que ninguém age.

O responsável pode mudar conforme a solicitação avança. Um agente de suporte pode ser responsável por uma solicitação nova, um especialista pode cuidar da investigação e um gerente de contas pode ficar responsável pela resposta final ao cliente. Coloque cada mudança no mapa para que a equipe não precise deduzir quem deve agir.

Mantenha o responsável pela solicitação separado dos revisores e aprovadores. Um líder financeiro pode aprovar um reembolso, mas o agente de suporte ainda pode continuar responsável pela solicitação. O agente pede a aprovação, acompanha a resposta e informa o resultado ao cliente. O líder financeiro não deve assumir todos os acompanhamentos apenas porque clicou em «Aprovar».

Em cada encaminhamento, registre o responsável e a equipe ativos, o gatilho da mudança de responsabilidade, o trabalho necessário antes da próxima transição e quem assume se o responsável estiver indisponível.

Planeje as ausências antes que elas causem atrasos. Use uma fila da equipe, um substituto definido ou uma regra que reatribua as solicitações depois de um período determinado. Se um especialista estiver de licença, outra pessoa deve encontrar a solicitação na própria fila, em vez de deixá-la com alguém que não pode responder.

Torne a responsabilidade visível no aplicativo. Mensagens privadas e conversas por e-mail podem apoiar o trabalho, mas não devem definir o fluxo. Cada registro de solicitação deve mostrar o responsável atual, o encaminhamento anterior, o horário da atribuição e o motivo da reatribuição. Os gestores conseguem identificar solicitações que esperaram tempo demais, e a equipe que fala com os clientes pode dar atualizações sem procurar em várias mensagens.

Por exemplo, quando um cliente relata um erro de faturamento, o agente de suporte fica responsável até confirmar que o financeiro precisa analisar o caso. O analista financeiro então assume a investigação. Depois que o financeiro registra uma decisão, a responsabilidade volta para o suporte, que responde ao cliente e fecha a solicitação. Isso evita que duas pessoas enviem respostas diferentes ou que ambas pensem que a outra já respondeu.

Ao criar o fluxo no aplicativo, inclua as mudanças de responsável na própria transição de estado. O AppMaster pode conectar uma mudança de status, uma regra de atribuição e um registro de auditoria em um único processo de negócio. Isso ajuda a manter a responsabilidade clara à medida que a equipe cresce.

Defina prazos que correspondam ao trabalho

Uma solicitação muitas vezes precisa de dois prazos. O prazo de resposta cobre a primeira resposta relevante, como confirmar que um agente de suporte leu a solicitação e precisa de mais detalhes. O prazo de conclusão cobre o momento em que a equipe resolve a solicitação ou entrega o resultado combinado.

Manter essas datas separadas evita um problema comum: o cliente recebe uma confirmação rápida, mas a solicitação fica parada por dias. Uma solicitação de acesso pode exigir resposta em quatro horas úteis e conclusão em dois dias úteis. Uma disputa complexa de faturamento pode exigir resposta em um dia útil e um prazo maior para a conclusão.

Escreva exatamente quando cada relógio começa. Muitas equipes iniciam o prazo de resposta quando o sistema recebe a solicitação. O prazo de conclusão pode começar no mesmo momento ou somente quando a equipe tiver informações suficientes para trabalhar. Escolha uma regra e aplique-a de maneira consistente.

Defina as pausas com o mesmo cuidado. O relógio pode parar enquanto a solicitação aguarda uma resposta do cliente, um terceiro aprovado ou uma janela de manutenção programada. Ele deve voltar a correr quando as informações chegarem ou o bloqueio terminar. Não pause um prazo porque a pessoa responsável está ocupada ou ausente. O responsável ou o gestor deve redistribuir o trabalho.

Inclua um escalonamento antes que o prazo se aproxime. Um lembrete ao responsável quando 75% do tempo permitido tiver passado dá tempo para agir. Aos 90%, notifique o gestor ou a próxima equipe responsável. Se o prazo vencer, marque a solicitação como atrasada e informe a próxima ação.

Uma política simples pode funcionar assim:

• O prazo de resposta começa quando o cliente envia uma solicitação.
• O prazo de conclusão é pausado depois que a equipe faz uma pergunta específica e a solicitação entra em Aguardando o cliente.
• Quando o cliente responde, o prazo volta a correr e a solicitação retorna ao responsável atual.
• Perto do prazo, o responsável recebe um lembrete e depois o gestor recebe um escalonamento.
• Para uma solicitação atrasada, o gestor define um plano de recuperação e atualiza o cliente.

Use apenas o horário comercial se todos aceitarem a agenda definida. Uma equipe que promete atendimento sete dias por semana não deve parar silenciosamente o relógio todas as noites. Se o suporte funciona de segunda a sexta-feira, defina no fluxo o horário de trabalho, os feriados e o fuso horário. Regras claras tornam as notificações de prazo justas para clientes e funcionários.

Planeje as notificações sem criar ruído

As notificações devem responder a uma pergunta prática: alguém precisa saber ou fazer alguma coisa agora? Se não, mantenha a atualização dentro do registro da solicitação. Uma caixa de entrada barulhenta faz clientes e funcionários ignorarem mensagens, inclusive as importantes.

Envie uma mensagem ao cliente quando a solicitação mudar de uma maneira que o afete. Os momentos mais comuns incluem confirmar o recebimento, pedir mais informações, aprovar ou recusar uma solicitação, alterar a data prometida de conclusão e concluir o trabalho. Não notifique o cliente porque um funcionário corrigiu um erro de digitação, adicionou uma nota interna ou redistribuiu uma tarefa sem alterar o resultado esperado.

Os alertas internos também precisam de um responsável e de um motivo para agir. Quando uma solicitação passa para «Precisa de análise», notifique o revisor. Quando um cliente responde a uma pergunta, avise a pessoa responsável pelo acompanhamento. A equipe inteira não precisa receber um alerta para nenhum desses eventos.

Mantenha as mensagens simples e específicas. Informe qual é a solicitação, seu status atual e o que acontecerá em seguida. Por exemplo:

• Cliente: «Recebemos sua solicitação de equipamento nº 1842. Vamos analisá-la até terça-feira.»
• Revisor: «A solicitação nº 1842 precisa da sua aprovação até terça-feira, às 15h.»
• Cliente: «Sua solicitação nº 1842 foi aprovada. Nossa equipe agendará a entrega e atualizará você até sexta-feira.»

O momento da mensagem é tão importante quanto o texto. Um lembrete de prazo deve chegar cedo o suficiente para permitir uma ação, não cinco minutos antes do vencimento. Para uma janela de análise de dois dias, um lembrete no dia anterior e outro depois do vencimento costumam ser suficientes. Quando o responsável conclui o trabalho, o aplicativo deve interromper os lembretes pendentes.

Registre as regras de notificação ao lado de cada transição no mapa. Anote quem recebe a mensagem, qual evento a aciona, qual é o canal de entrega e se o aplicativo precisa enviar um lembrete. Assim, o comportamento fica claro antes que alguém crie uma tela ou escreva uma automação.

Acompanhe uma solicitação simples de cliente

Um cliente relata uma cobrança duplicada por meio de um formulário de suporte. O formulário cria a solicitação nº 4821 com o estado «Nova» e a atribui à fila de suporte. O cliente recebe uma confirmação imediata com o número da solicitação e a informação de que a equipe analisará o caso em até um dia útil.

Um agente de suporte abre a solicitação, verifica o pedido e o registro de pagamento e muda o estado para «Em análise». O agente fica responsável pela solicitação. Se os registros de pagamento não tiverem detalhes suficientes, ele seleciona «Aguardando o cliente» e pede uma captura de tela do extrato bancário ou os quatro últimos dígitos do cartão.

Esse estado precisa de um prazo. O aplicativo pode lembrar o cliente depois de três dias e fechar a solicitação depois de sete dias sem resposta. O agente deve receber uma notificação quando o cliente adicionar as informações que faltavam, para que a solicitação não permaneça esquecida em uma fila.

Quando o cliente responde, a solicitação volta para «Em análise» e retorna ao mesmo agente sempre que possível. A continuidade é importante porque um novo agente não deve repetir as mesmas perguntas.

Se o agente confirmar a cobrança duplicada, ele move a solicitação para «Decisão sobre o reembolso» e a atribui a um revisor financeiro. O financeiro tem dois dias úteis para aprovar ou recusar o reembolso. Um lembrete um dia antes do prazo dá ao revisor tempo para agir antes que o cliente precise cobrar uma atualização.

O revisor financeiro registra a decisão. Uma solicitação aprovada passa para «Processamento do reembolso», onde a equipe de pagamentos emite o reembolso e informa seu número de referência. Uma solicitação recusada volta para o suporte com um motivo que o agente possa explicar claramente.

O suporte envia a mensagem final somente depois que a equipe emite o reembolso ou explica a recusa. Em seguida, o agente muda o status para «Fechada». O cliente recebe um aviso de encerramento com o resultado, enquanto a equipe mantém um registro de cada responsável, decisão, prazo e mensagem.

Esse mapa evita uma lacuna comum: uma solicitação que parece concluída em uma tela, mas ainda aguarda uma ação na fila de outra equipe.

Erros comuns que confundem o fluxo

A maioria dos fluxos de solicitação fica confusa porque os rótulos parecem claros para quem os criou, mas não para quem os usa todos os dias. Um status chamado «Pendente» pode significar que o cliente não respondeu, que um gestor precisa aprovar o trabalho ou que um técnico aguarda peças. Cada situação exige uma próxima ação diferente.

Substitua rótulos vagos por estados que expliquem a espera. «Aguardando detalhes do cliente» informa ao solicitante o que fazer. «Aguardando aprovação do gestor» mostra ao gestor o que está bloqueando o progresso. Se a equipe não consegue dizer quem deve agir em seguida, renomeie o estado ou remova-o.

A responsabilidade é outra fonte frequente de problemas. Uma solicitação pode envolver suporte, financeiro e operações, mas vários nomes não criam responsabilidade compartilhada. Defina um responsável para cada estado ativo. Essa pessoa pode pedir contribuições a outras, mas continua responsável por fazer a solicitação avançar ou explicar o atraso.

Um prazo precisa estar ligado a uma ação. Uma data de vencimento que apenas envia um lembrete ajuda pouco quando ninguém responde. Defina o que acontece quando o tempo acaba: alertar o responsável, escalar para um gestor ou mover a solicitação para uma fila de análise. Relacione a ação ao impacto do atraso.

Não crie telas apenas porque um estado parece útil. Cada tela deve apoiar uma tarefa, decisão ou transferência clara. Uma tela de «Revisão de qualidade» só faz sentido se alguém verificar critérios definidos e aprovar a solicitação ou devolvê-la com um motivo. Se a equipe não consegue explicar essa ação com clareza, remova o estado em vez de esconder a incerteza atrás de outra página.

Antes de criar as telas, teste cada parte do ciclo de vida com quatro perguntas:

• O que exatamente esse status significa?
• Quem é responsável pela solicitação enquanto ela está aqui?
• Que evento a leva ao próximo status?
• O que acontece se o prazo vencer?

Essa verificação revela lacunas logo no início. Ela também facilita transformar o mapeamento do fluxo em um aplicativo, porque cada estado tem um propósito, um responsável e uma ação definida.

Faça uma verificação rápida antes de criar as telas

Um mapa de solicitações deve passar por uma revisão simples antes que alguém abra um construtor de interfaces. Leia-o como se você fosse um funcionário tratando de uma solicitação real em uma terça-feira movimentada. Se não conseguir saber o que acontece em seguida, uma tela não resolverá a lacuna.

Dê a cada estado uma função clara e pelo menos um caminho de saída. «Aguardando o cliente» significa que a equipe precisa de informações, então o estado deve mudar quando o cliente responder, cancelar ou não responder até a data combinada. Evite estados que descrevem apenas uma sensação geral, como «Em andamento», a menos que a equipe saiba exatamente que trabalho ocorre ali.

Revise cada transição perguntando o que a aciona e quem pode executá-la. Um agente de suporte pode marcar uma solicitação como resolvida depois de enviar uma resposta. O cliente pode reabri-la. Uma regra do sistema pode fechá-la depois de 14 dias sem resposta. Registre essas permissões para evitar mudanças acidentais.

Use esta lista de verificação:

• Todo estado tem um propósito, um caminho de saída e um próximo estado coerente.
• Toda transição informa seu gatilho e a pessoa ou regra autorizada a iniciá-la.
• Toda solicitação aberta tem um único responsável e uma data de vencimento ou prazo de resposta.
• Toda atualização ao cliente ocorre quando uma mudança de status o afeta.
• Todo caminho de atraso informa quem será alertado e o que essa pessoa deve fazer.

Verifique a responsabilidade nos encaminhamentos, onde a confusão costuma começar. Se um agente de suporte encaminhar um problema técnico para a engenharia, a solicitação precisa de um novo responsável definido. O agente original pode continuar como observador, mas os dois nunca devem presumir que o outro responderá.

Mantenha as notificações de prazo práticas. Envie um lembrete interno antes do vencimento e escale o caso somente se a solicitação continuar aberta. Informe ao cliente quando precisar da colaboração dele, quando a solicitação passar para outra equipe e quando ela for resolvida ou fechada. Não alerte o cliente sobre cada nota interna.

Quando o mapa estiver claro no papel, as telas terão uma função definida: mostrar o status, as ações, o responsável e o prazo corretos para a pessoa certa.

Transforme o mapa em um aplicativo

Quando o ciclo de vida da solicitação do cliente está claro, cada parte do mapa tem um lugar direto no aplicativo. Os estados se tornam um campo de status. Os responsáveis se tornam usuários ou equipes atribuídos. Os prazos se tornam campos de data e hora. As transições se tornam ações como «Atribuir», «Pedir detalhes», «Resolver» e «Reabrir».

Mantenha a primeira versão simples. Uma tela de solicitação normalmente precisa do cliente, tipo de solicitação, descrição, status atual, responsável atribuído, prazo, histórico de atividades e arquivos. Uma fila separada pode mostrar a cada pessoa as solicitações que precisam de sua atenção.

O fluxo deve controlar as ações, não apenas exibir um rótulo. Um agente de suporte pode mover uma solicitação de «Nova» para «Em análise». Somente o responsável pela resolução pode marcá-la como «Resolvida». Se o cliente responder depois da resolução, o aplicativo pode reabrir a solicitação e devolvê-la à fila adequada.

Antes de criar todas as telas, teste uma versão funcional com pessoas que recebem e resolvem solicitações reais. Peça que concluam casos comuns, um caso urgente e uma solicitação com informações ausentes. Observe os momentos em que elas não encontram uma ação, não sabem quem é o responsável ou precisam sair do aplicativo para fazer uma pergunta.

Use esse feedback para corrigir o mapa e a tela. Um encaminhamento que confunde duas equipes pode precisar de um estado como «Aguardando aprovação». Uma solicitação que fica parada por muito tempo pode precisar de uma data de vencimento mais clara ou de um lembrete para o responsável. Não adicione estados para descrever cada pequena atividade. Muitas opções tornam o fluxo mais difícil de acompanhar.

O AppMaster pode transformar esse design em um aplicativo de solicitações no-code. Seu Data Designer pode modelar solicitações, usuários, equipes, prazos e histórico de status. O Business Process Editor pode definir atribuições, mudanças de status, lembretes e escalonamentos, enquanto telas web ou móveis podem apoiar filas de solicitações, visualizações detalhadas e relatórios para gestores.

Comece com um tipo de solicitação e um pequeno grupo de usuários. Quando eles conseguirem criar, atribuir, atualizar e fechar solicitações sem soluções alternativas, adicione o próximo tipo. O resultado será um aplicativo que apoia o trabalho real em um dia movimentado, em vez de telas bonitas que deixam as pessoas sem saber o que fazer.