O problema

Fazer compras online é, em muitos aspectos, melhor do que ir presencialmente ao mercado. Você pode olhar corredores sem fazer qualquer esforço para andar ou empurrar um carrinho; pode encontrar instantaneamente o produto que deseja; não precisa enfrentar trânsito e pode fazer tudo isso no conforto da sua casa ou onde estiver. Apesar dessas facilidades, o varejo alimentar digital ainda encontra muitos desafios.

Muitos players de delivery dependem de um profissional que vá ao mercado por você — os chamados shoppers. O problema é quando as mercadorias que você comprou são armazenadas no mesmo espaço onde outros clientes fazem compra presencialmente. Um produto que você comprou online, pode ser disputado por uma pessoa presencialmente se a quantidade em estoque for insuficiente. Um spoiler: geralmente a pessoa no mercado físico é quem levará.

Uma série de problemas resultam em números que não são fieis à real quantidade de um produto em estoque. Infelizmente, resolver os problemas que originam essa dor não estava ao nosso alcance. Precisávamos seguir por outro caminho.

A grandiosidade do projeto necessitava do envolvimento de duas squads (Customer e Shopper) de tribos diferentes. Ou seja, precisávamos atuar em dois produtos diferentes. O ponto alto do projeto foi realizar o discovery de forma ampla e ao mesmo tempo focando em aspectos específicos de cada produto para servir a ambos e suas particularidades.

O processo

Já sabíamos que a falta de produtos era uma das principais queixas dos clientes. Queríamos entender mais a fundo essas reclamações. Analisamos dados quanti e qualitativos — incluindo ligações ao time de suporte e trocas de mensagens com shoppers.

Com esses dados, pudemos ter uma base do que estava acontecendo de fato com a nossa operação e como isso refletia na experiência do cliente. Esse seria um projeto gigante em importância para o negócio e tecnicamente desafiador. Ao final de toda escuta e leitura de reclamações dos agentes envolvidos nos processos, montar uma jornada do usuário parecia uma boa forma de representar todos os dados e listar algumas possíveis oportunidades.

Decidimos buscar como outros players nacionais e internacionais resolveram o problema em seus contextos. Fizemos um benchmarking. Seria importante para captar referências e imaginar quais problemas em comum esses players enfrentaram.

Era a hora de reunir stakeholders para compartilhar o que foi descoberto e trazer novas certezas, hipóteses e dúvidas para o projeto. Durante algumas meets, business owners, product owners e eu colocávamos nossas considerações em uma matriz CSD. O fato de ter lido e ouvido o contato do cliente com coletores e time de atendimento previamente nos deu a vantagem de responder algumas dúvidas sem precisar levá-las a uma pesquisa mais ampla, assim conseguimos economizar bom tempo de debates improdutivos e nos esforçar apenas naqueles que não tínhamos evidências.

Ao final, tínhamos 3 possíveis caminhos e seus pontos positivos e negativos:

1. O cliente poderia escolher um produto alternativo enquanto realiza a compra; isso economizaria tempo e traria agilidade operacional mas poderia ocasionar em uma dupla frustração caso o cliente selecionasse um produto que poderia estar com a quantidade em estoque errada
2. O cliente seria avisado pelo coletor uma única vez quando todos os itens estivessem coletados e poderia escolher entre uma gama de possíveis substituições escolhidas pelo coletor; pensamos que uma ocasional demora do cliente poderia trazer ao coletor uma sensação de aflição
3. A terceira alternativa seria juntar as duas ideias e obter o melhor dos dois caminhos; seria a saída mais complicada tecnicamente e com muitas pontas a serem controladas nesse primeiro momento

Apesar de chegarmos a esses caminhos, ainda havia muita dúvida sobre o que exatamente cada um deles contemplaria e como o cliente e coletor atuariam em cada ideia. Decidi então tornar os caminhos menos abstratos criando fluxos da jornada do cliente e do nosso coletor. Dessa forma, pudemos perceber impasses e oportunidades que antes não tínhamos visto.

Nos questionamos então qual proposta resolveria o problema e entregaria valor mais rapidamente. Assim, conseguiríamos mensurar a entrega de forma rápida e ir incrementando aquilo que não seria priorizado. Decidimos seguir pelo caminho 2, onde o coletor é avisado que um produto pode estar em falta e da prioridade a ele. Caso um item falte, o Shopper consegue sugerir opções de forma menos dolorosa e mais automatizada. No final da coleta, o cliente receberia todos os itens em falta de uma só vez e poderia escolher entre as opções enviadas pelo coletor ou remover o produto da compra.

Desenhando a solução

Validação das soluções

Após escolher uma alternativa, planejamos o roteiro para validar com clientes reais do James e fizemos um protótipo de alta fidelidade.

Com os clientes finais, durante os testes, percebemos que:

1. Não estava claro a alguns participantes como ficaria o preço do pedido após as alterações na compra
2. Haviam dúvidas sobre quem enviou aquelas sugestões de substituição: um sistema ou a pessoa que está realizando a coleta
3. Algumas pessoas gostariam de realizar ações que não eram possíveis na primeira versão do MVP e não estava clara a forma como elas poderiam contornar esse problema

Já nos testes com shoppers, foi possível perceber:

1. Dificuldade em saber por onde iniciar o novo fluxo, uma vez que estavam habituados a realizar isso de forma manual via chat
2. Não estava claro que o cliente enviou uma observação a respeito das substituições que autorizou. Isso poderia acarretar em erros operacionais e mais frustração
3. Alguns participantes ficaram em dúvidas sobre o que fazer enquanto aguarda a resposta do cliente

Após as considerações dos participantes, realizamos os ajustes necessários e avançamos para a validação final com o time de tecnologia. O projeto estava pronto para iniciar o desenvolvimento.

Para isso fazemos o hand-off, o entregável do time de design para desenvolvedores. Contendo fluxos, componentes, orientações e outras informações úteis durante o desenvolvimento. O hand-off assegura mais qualidade às entregas. Recentemente, reformulamos e padronizamos a forma como realizamos os hand-offs em conjunto com os desenvolvedores, buscando entender o que ajuda ou não seus trabalhos.

No hand-off, gosto de propor eventos que auxiliarão ao time de negócios, dados e a mim sobre como a funcionalidade está performando e garantir que tenhamos insumo para métricas e melhorias futuras.