🧠 O usuário sempre tem razão... será?

te entendo bem, geralmente aparecem alguns clientes recorrentes que ficam fazendo esses pedidos sem sentido. no meu trabalho, a gente definiu que só vai atender solicitação dos clientes quando várioes clientes fizerem o mesmo pedido/reclamação (ou parecido). quando um sistema é feito pra vários clientes, não dá pra atender todo mundo.

e pra piorar, geralmente esse tipo de pedido até pode melhorar o sistema pra esse cliente em específico, mas atrapalha todos os outros.

tenta passar essa ideia pro pessoal, principalmente pros seus superiores.

Um amigo meu trabalha de suporte, e ele fala que muitas coisas ele também acha desnecessário, parte ele corta na hora, mas as vezes a decisão de acatar acaba vindo de cima, a maioria das vezes quando isso ocorre é para agradar um cliente que está aguardando um feature demorada.

Ou ás vezes o cliente mente falando que é uma correção quando é mudança de acordo com a preferência dele, quando não tem como comprarar, acaba passando as vezes.

O que funciona muito bem na empresa em que atuo é o time de produto, eles além das tarefas deles, recebem esse tipo de sugestão que chamamos de 'melhoria', eles avaliam o custo, o tempo, energia etc. Se fizer sentido, entra no backlog com refinamentos que façam sentido pro produto.

Nem sempre a empresa terá o tamanho e a necessidade de um time inteiro para isto, então, no seu caso, talvez eleger alguém do próprio suporte para tomar esse cuidado.

Isso é um fato interessante, pois muitas vezes eu faço uma modificação no site só pq uma pessoa reclamou. Vou me policiar mais com isso. Obrigado ppr coloborar.

Tenho uma opinião impopular quanto a isso, mas vem funcionando bem pra mim rsrs...

Trabalhei em um lugar há uns anos (3+-) que era ótimo, tínhamos um produto que quase não dava problema (quase ainda é muito, o produto era e ainda é muito estável... da para contar nos dedos de uma mão quantos incidentes tive na época). O time tinha só um pequeno problema, que era quanto a validação de ideias propostas. Lembro que certa vez estávamos refinando uma história onde só íamos precisar gerar metadados para o time que cuidava da parte de dados, para validação de ingestão. Um dev propôs com todo entusiasmo do mundo, usando embasamento, estudos, que devíamos criar um serviço todo para gerar esses metadados. O problema não era a ideia, e sim a implementação. O dev se deu o trabalho de procurar os tais estudos, buscar opiniões externas, mas não pensou no principal que é a entrega de valor para uma atividade simples. CAPEX/OPEX não batem nesse tipo de proposta.

Como TL na época, não queria dizer "não vamos fazer isso" sem ter uma base tão boa quanto a dele, mas não tinha tempo para isso. O que sugeri foi que o mesmo fizesse uma POC fora do horário do trabalho, documentasse gastos, despesas, necessidades e problemas resolvidos, montasse uma apresentação e mostrasse ao time. Não preciso dizer que a ideia não andou.

Sei que pareço ser um otário falando isso, pode até ser que eu seja. Eu poderia dar uma de Akita e ser direto sem rodeios, dizer que não, mas não fiz. Chamei essa estratégia de "jogar na burocracia".

Li sobre isso em um livro chamado "As armas da persuasão" do Cialdini. Não tem muito a ver com tech, mas tem essas pequenas abordagens que precisamos usar no dia a dia. Link no precinho para quem quiser comprar: https://amzn.to/4eyVuDE

No seu caso, pensando aqui como aplicar essa "estratégia", seria direcionar a pessoa para um formulário, onde o caso dela ia ser analisado, e se tivessem muitas ocorrências sobre o mesmo pedido, seria feito algo...

Lembrando que isso é uma abordagem minha. Não sou bom com confrontos diretos, nem mesmo em ser direto.