O que um painel admin precisa para o seu produto não precisar de você

Um bom painel administrativo se mede pelos chamados de suporte que ele evita. Não pela quantidade de telas, não pela beleza do dashboard, mas pela raridade com que a pessoa que opera o produto precisa pedir ajuda a um desenvolvedor. Se publicar conteúdo, reembolsar um cliente ou mudar uma regra de negócio exige abrir um chamado, o painel falhou, por mais polido que o resto do produto seja.

O painel é o produto para quem opera

Quando alguém compra ou encomenda um software, a obsessão vai toda para o app do usuário final: o onboarding, as animações, os estados vazios. O painel administrativo fica com o orçamento e a atenção que sobram, o que costuma ser quase nada. Essa prioridade está invertida por um motivo simples: o usuário final abre o app por alguns minutos de cada vez, mas o operador vive dentro do painel todos os dias.

O operador é quem aprova cadastros, responde reclamações, corrige um erro de digitação numa descrição e puxa os números do relatório mensal. Para essa pessoa, o painel não é um detalhe de bastidor. Ele é o produto. Se for lento, confuso ou incompleto, a operação inteira desacelera junto, e as lacunas passam a ser preenchidas pelo recurso mais caro disponível: o tempo de um desenvolvedor.

Quais operações de rotina precisam ser self-service

Rotina é tudo o que acontece semanalmente ou mais. Tudo desta lista deveria ser executável por um operador não técnico, sozinho, sem tocar em código nem pedir a ninguém:

• Publicar e despublicar conteúdo: cadastros, eventos, ofertas, páginas, avisos
• Gerenciar usuários e permissões: convidar alguém do time, mudar um papel, desativar uma conta
• Fazer reembolsos ou corrigir pedidos quando algo dá errado com um cliente
• Configurar políticas: taxas, limites, horários, janelas de cancelamento, regras de notificação
• Exportar dados e puxar relatórios sem pedir para ninguém consultar o banco
• Ver exatamente o que o usuário final vê, para que o suporte comece da mesma tela

O último item é o mais negligenciado. Quando um cliente diz que algo parece errado, o operador deveria conseguir ver a visão daquele cliente em segundos. Sem isso, toda conversa de suporte vira uma corrida de revezamento entre o operador, o cliente e, no fim, um desenvolvedor com acesso ao banco.

Regra de negócio como configuração, não como código

As regras de um negócio mudam com mais frequência do que o software deveria mudar. Preços se movem, políticas apertam ou afrouxam, temporadas vêm e vão. Se toda mudança de regra é uma mudança de código, o operador acaba negociando com o backlog de um desenvolvedor só para tocar o próprio negócio.

Um dos sistemas que a Cazullo constrói e opera é um sistema de gestão de estúdios chamado Mahna, usado por estúdios de yoga e bem-estar. Cada estúdio tem as próprias regras de faltas e reposições: quantas faltas um aluno pode repor, dentro de qual janela e em quais condições dependendo do plano do aluno. Essas regras vivem na configuração do estúdio, não no código. Quando um aluno falta, o sistema aplica a política daquele estúdio automaticamente: concede ou nega o crédito de reposição, controla a janela e mostra a mesma resposta para todos.

O efeito aparece na recepção. Antes, cada caso limítrofe virava uma discussão entre a recepcionista e o aluno, e cada ajuste de política virava um pedido de mudança para um desenvolvedor. Com regra como configuração, a discussão acaba porque o sistema é o juiz, e o ajuste leva um minuto no painel em vez de uma semana num backlog.

Fluxos de moderação e curadoria

Qualquer produto com conteúdo gerado por usuários ou pela comunidade precisa de moderação, e qualquer produto que queira parecer vivo precisa de curadoria: escolher o que ganha destaque, ordem e vitrine. As duas coisas são trabalho diário, e as duas precisam pertencer ao operador.

A plataforma white-label de comércio local da Cazullo gera um app, um site e um painel administrativo com a marca de cada cliente. Cada marca é tocada por um time pequeno, muitas vezes duas ou três pessoas sem nenhum engenheiro entre elas. O painel permite aprovar ou rejeitar novos cadastros de negócios, ocultar conteúdo que quebra as regras, destacar os negócios e eventos que quiserem no topo e publicar avisos. Nada disso toca código, e essa é a única forma de várias marcas operarem numa mesma plataforma sem uma fila de pedidos de engenharia atrás de cada uma.

Sinais de que o seu painel está falhando

A falha raramente se anuncia. Ela aparece como um atrito que todo mundo aos poucos aceita como normal. Fique de olho nestes sinais:

• Chamados recorrentes para desenvolvedores por mudanças de rotina: atualizar um preço, corrigir um texto, desbloquear um usuário na mão
• Operadores mantendo planilhas paralelas porque o painel não responde às perguntas que eles realmente têm
• Um fluxo constante de mensagens do tipo 'você consegue mudar rapidinho o X' caindo no chat de um desenvolvedor

Cada um desses itens é uma tarefa que o painel deveria cobrir e não cobre. Isoladamente parecem pequenos. Somados, significam que o produto não roda sem quem o construiu, que é exatamente a dependência que um painel administrativo existe para eliminar.

Checklist para escopar um painel

Se você vai encomendar ou construir um produto, coloque o painel na primeira conversa, não na última. Estas perguntas revelam a maior parte do escopo:

• Liste toda ação que o operador fará semanalmente. Cada uma precisa de uma tela ou um botão, não de um chamado
• Decida quais regras de negócio vão mudar com o tempo e transforme cada uma em configuração, não em código
• Defina papéis e permissões desde o primeiro dia: quem publica, quem reembolsa, quem configura
• Inclua moderação: todo conteúdo criado por terceiros precisa de um caminho de aprovar, ocultar ou remover
• Planeje exportações e relatórios para as perguntas mensais do operador, não só um dashboard
• Dê ao operador um jeito de ver o que qualquer usuário final vê, para suporte e para confiança
• Registre quem fez o quê e quando, para que erros possam ser rastreados e revertidos sem perícia
• Reserve tempo real de design e testes para o painel, igual ao do app do usuário final

A recomendação é simples: escope o painel administrativo como metade do produto, porque para quem opera, é isso que ele é. Um produto cujas operações de rotina são self-service cresce sem precisar dos criadores na sala. Um produto que precisa de um desenvolvedor para cada pequena mudança tem um problema de folha de pagamento disfarçado de software.