Pedido de funcionalidade vai para o mesmo lugar que todo o resto: support@rec.review. Não tem formulário separado nem mural de votação — um e-mail simples chega em quem constrói o produto.
O que colocar nele
Os pedidos que viram código são os que a gente entende. Quatro linhas bastam:
- O que você está tentando fazer. A tarefa, não a funcionalidade. “Preciso mandar o mesmo corte para dois clientes sem que um veja o comentário do outro” diz mais do que “coloca compartilhamento multicliente”.
- Como você faz hoje. A gambiarra que você usa. Normalmente é ela que mostra onde está o atrito de verdade.
- Com que frequência isso acontece. Uma vez por trimestre e duas vezes por dia são produtos diferentes.
- Um print, se tem tela envolvida. Marque em cima dele onde a coisa deveria ficar.
Diga se está travando o trabalho. Isso muda a ordem das coisas.
Bug não é pedido de funcionalidade
Se algo está quebrado em vez de faltando, mande como bug — veja Falar com o suporte para saber o que incluir e a gente conseguir reproduzir de primeira.
Acompanhando o que saiu
- No app: abra o menu do avatar e clique em Novidades. Um ponto no menu marca as novidades que você ainda não viu.
- No site: Novidades lista os mesmos lançamentos publicamente, então dá para apontar um colega para a mudança sem mandar print.
Dica: Quando algo que você pediu sai, aparece ali. Dar uma olhada uma vez por mês costuma render mais do que perguntar se o pedido foi para frente.