No Glint, a maior lacuna diante do mercado era um processo manual: o reembolso pedido por e-mail. Priorizar foi achar esse trabalho, ordenar o resto pelo que dependia do quê e escrever o que ficava na mão, de propósito.
Anderson Silveira · 21 de setembro de 2026
O Glint é uma plataforma de eventos que construí em cerca de três semanas: venda, portaria, relacionamento e pós-venda no mesmo produto. Em três semanas, o que não falta é pedido. Cada leva trazia funcionalidade nova, e cada uma parecia a mais importante.
O ponto de virada foi um comparativo com uma plataforma concorrente. A conclusão tinha dois lados. O Glint já tinha mais de 24 recursos que o concorrente não tinha: setores, CRM, automação, certificados, afiliados com portal. E o concorrente levava vantagem em cinco pontos, com um deles à frente de todos: o reembolso self-service. Pelo direito de arrependimento, o participante tem sete dias; no Glint, isso ainda era um processo manual, por e-mail, lento e cheio de atrito para os dois lados.
A leitura ingênua do comparativo seria comemorar os 24. A leitura útil foi a outra: mais um recurso onde o produto já ganhava movia pouco; fechar a lacuna número um mudava a conversa de venda. O pós-venda entrou no ar dois dias depois: dentro do prazo, o participante pede no app e o estorno sai na hora; fora do prazo, o pedido vira uma solicitação para o organizador aprovar ou recusar. A regra ficou automática. A exceção continuou humana.
Este artigo é sobre o método por trás desse tipo de escolha: qual trabalho manual automatizar primeiro, em que ordem, e o que deixar na mão de propósito.
Prioridade para quê
Nenhuma técnica funciona sem saber impacto em quê. No Glint, o critério que atravessou tudo foi uma separação feita antes de qualquer tela: núcleo e extras. O que todo organizador precisa (evento, ingresso, checkout, check-in, financeiro) é núcleo. O resto é extra.
Essa separação virou regra de priorização e, depois, regra comercial. O modelo tem três planos, e o gratuito cobre o núcleo inteiro. Se o pagamento da assinatura falha, a conta volta para o básico: o organizador perde os extras, nunca o evento que está vendendo. Uma pergunta como “isso entra agora?” passa a ter um primeiro filtro: é núcleo? Se é, e está quebrado ou faltando, vem antes de qualquer extra.
Três perguntas para cada trabalho manual
Antes de pôr um processo manual na matriz, eu passo por três perguntas. Elas não dão a nota. Dão o que comparar.
| Pergunta | O que ela revela | Exemplo |
|---|---|---|
| Com que frequência acontece? | Quanto tempo a automação devolve | No Glint, qualquer participante pode pedir reembolso; a comissão de afiliado fecha por período e cabia num relatório pago à mão |
| O que custa quando sai errado? | Quanta revisão humana a automação precisa | No sistema de pedidos de uma distribuidora, errar a embalagem de um tambor de 200 litros não é barato. Por isso a IA propõe e o comprador confirma |
| A regra está escrita? | Se dá para automatizar sem alguém decidir caso a caso | Dentro de sete dias o reembolso é direito do participante: regra clara, estorno automático. Fora do prazo, é decisão do organizador |
A terceira pergunta é a que mais separa. Regra clara vira automação. Regra que depende de contexto vira fila para alguém decidir, com a máquina só preparando a decisão.
Matriz de impacto × esforço
A ferramenta mais simples, e muitas vezes suficiente. Os itens abaixo são do Glint; as posições são uma leitura minha em retrospecto, não uma medição.
A matriz rende mais como exercício coletivo. O valor está na discussão quando duas pessoas põem o mesmo item em quadrantes diferentes; quase sempre uma delas sabe algo que a outra não sabe.
RICE, quando a lista é longa
A matriz fica frágil com muitos itens parecidos. O RICE, criado na Intercom, acrescenta quantas pessoas são afetadas e quão confiante o time está:
| Item (exemplo ilustrativo) | Alcance | Impacto | Confiança | Esforço | RICE |
|---|---|---|---|---|---|
| Mensagem de erro mais clara no pagamento | 8.000 | 0,25 | 100% | 0,5 | 4.000 |
| Novo fluxo de cadastro | 2.000 | 1 | 80% | 2 | 800 |
| Módulo de relatórios | 500 | 3 | 50% | 4 | 187,5 |
O melhor do RICE é tornar visível o item sem glamour que alcança muita gente. O pior é a precisão falsa: 187,5 é o produto de quatro estimativas. Pontuações próximas são empate. Use o número para separar grupos, nunca para desempatar por casa decimal, e registre de onde veio cada valor.
Dependência também ordena a fila
Valor diz o que importa. Não diz em que ordem dá para construir. No Glint, isso ficou explícito numa iniciativa de 16 tarefas: catálogo de produtos, CRM, funil, certificados, participantes, a reorganização das abas do evento. Uma descoberta feita antes da execução gerou um brief por tarefa e um mapa de conflitos: quais tarefas mexiam nas mesmas telas e nos mesmos arquivos.
A ordem saiu desse mapa, em seis ondas:
- 01Fundação
Componente de abas criado uma vez e mudanças de banco consolidadas.
- 02Páginas isoladas
Clientes, funil, certificados e painel geral, em paralelo.
- 03Segunda leva paralela
Produtos, visão geral do evento e engajamento.
- 04Editor do evento
Dias, ingressos e participantes, em série: dividem a mesma tela.
- 05Entregáveis
Upload de arquivos, sobre a tela que a onda anterior deixou pronta.
- 06Menu do evento
Um dono só reorganiza as abas no fim, de 14 para 12 itens.
A última onda é a lição. Reorganizar o menu parecia a tarefa mais visível, e por isso a mais tentadora de fazer primeiro. Feita primeiro, teria conflitado com todas as outras. Feita por último, virou uma costura de itens que já existiam.
Um roteiro em ondas é também a forma mais honesta de dizer “não agora”. No Kitnets, a descoberta virou 29 épicos em três ondas. Os épicos que dependiam de conta aprovada em serviço externo, com prazo que eu não controlo, ficaram para depois. Quando um painel precisava de dado de cobrança que ainda não existia, os cartões entraram desabilitados, com o aviso de que chegariam junto com a cobrança, em vez de mostrar número falso.
Sequência: o que abre caminho para o quê
Às vezes a ordem vem do próprio funil. Na Zeztra, o site com simuladores e diagnóstico, cada um devolvendo valor antes de pedir contato, veio primeiro. Com ele no ar, as campanhas da Zeztra passaram a pedir páginas por tema, e só então fez sentido o motor de pesquisas, uma página por tema. Construir o motor antes seria priorizar escala sem ter o que escalar.
No Glint, a trilha de marketing seguiu a mesma lógica, em seis etapas: cupom que vale para um evento ou para todos, afiliado como entidade do organizador, portal do afiliado, vitrine pública de eventos, afiliado da plataforma promovendo qualquer produtor e, por fim, divisão automática da comissão. As cinco primeiras saíram no mesmo dia, cada uma apoiada na anterior. A sexta foi adiada de propósito.
A lista do que fica na mão
O artefato mais útil de uma priorização é o que ficou de fora, com o motivo e a condição para voltar. Nem todo trabalho manual precisa virar automação agora.
| Item | Por que não agora | O que faria mudar |
|---|---|---|
| Split automático da comissão de afiliados (Glint) | Exige verificação de identidade de cada afiliado; a comissão como relatório, paga à mão, resolve o problema do período | Volume de afiliados que torne o pagamento manual inviável |
| Comissão diferente por evento para o mesmo afiliado (Glint) | Um percentual por afiliado cobre o uso atual | Pedido recorrente de organizadores |
| Cobrança e receita no painel da plataforma (Kitnets) | Dependia da assinatura, que ainda não existia | A assinatura entrar no ar |
A primeira linha é um trabalho manual mantido de propósito. Enquanto os afiliados são poucos, pagar a comissão à mão, a partir de um relatório, custa menos do que verificar a identidade de cada um. A automação espera o volume que a justifique.
A terceira coluna transforma um “não” numa decisão revisável. Quem pediu sabe o que precisaria acontecer, e ninguém rediscute a mesma coisa a cada semana.
O que eu faria diferente
- Fechar o mapa de planos antes de construir o gating. Na primeira versão, os planos nasceram com todo mundo no plano completo, para ninguém perder acesso. Quando o cadastro self-service entrou, o mapa foi refeito: produtos, clientes e cupons desceram para o gratuito. Deu certo porque a regra morava num arquivo só, mas foi retrabalho de decisão.
- Fixar os contratos entre tarefas paralelas. No painel da plataforma, duas frentes paralelas combinaram nomes diferentes para os mesmos números, e a tela de métricas abriu preta. Ondas paralelas pedem o contrato escrito antes, não só o mapa de arquivos.
- Fazer o comparativo antes. Ele veio depois de boa parte do produto pronto, e mostrou que a maior lacuna era de pós-venda. Feito no começo, teria pesado na ordem das primeiras levas.
Checklist de priorização
- Existe um resultado escrito para o período, e só um?
- O núcleo está separado dos extras, e o núcleo vem primeiro?
- Cada trabalho manual candidato foi avaliado por frequência, custo do erro e clareza da regra?
- A comparação com o mercado foi lida pelas lacunas, e não só pelas vantagens?
- A matriz foi feita em grupo, e as divergências foram discutidas?
- No RICE, a fonte de cada número está registrada, e pontuações próximas são empate?
- A ordem considera dependências e conflitos, e não só valor?
- Tarefas paralelas têm contrato escrito entre elas?
- Existe uma lista do que fica na mão, com motivo e condição para reabrir?
Se ninguém ficou desconfortável com o que ficou na mão, provavelmente a priorização não escolheu nada.