Automação pós-compra para Shopify: fluxo de trabalho para configurar com o Shopify Flow e sua central de atendimento
O Shopify Flow pode automatizar as etapas do suporte pós-compra no Shopify, enquanto sua central de atendimento continua sendo o sistema para conversas com clientes, atribuição de tickets e acompanhamento pelos agentes. A configuração mais confiável é usar o Flow para detectar um evento de pedido, verificar um pequeno número de condições e, em seguida, atualizar o pedido ou enviar informações estruturadas para uma integração com a central de atendimento. Não trate o Flow sozinho como um sistema completo de monitoramento de remessas: atrasos da transportadora, exceções de entrega e eventos de devolução podem exigir uma plataforma de rastreamento ou devoluções capaz de fornecer esses sinais.
Este guia mostra como criar o fluxo de trabalho, escolher o acionador correto, conectar o resultado à sua central de atendimento e testar a automação sem criar tickets duplicados ou mensagens enganosas para os clientes.
O que o fluxo de trabalho deve fazer
Um fluxo de trabalho pós-compra útil tem quatro partes:
- Evento: Algo acontece com um pedido, como pagamento, processamento, cancelamento ou reembolso.
- Decisão: O Flow verifica se o evento requer uma ação. As condições podem incluir o valor do pedido, o país de envio, o status do processamento, tags ou se um cliente já entrou em contato com o suporte.
- Ação: O Flow adiciona uma tag, atualiza um pedido, envia um e-mail ou notificação, ou envia dados para um endpoint externo.
- Responsável: Uma pessoa ou fila da central de atendimento recebe o caso quando é necessário julgamento ou comunicação com o cliente.
O objetivo não é automatizar toda interação com o cliente. É eliminar o trabalho repetitivo de triagem, preservando uma transferência clara para as exceções.
Antes de criar: defina a fonte de verdade
Comece decidindo qual sistema conhece cada informação. O Shopify geralmente é a fonte de informações sobre pedidos, pagamentos, processamento, reembolsos e clientes. Uma transportadora ou plataforma de rastreamento pode ser a fonte de informações sobre leituras durante o transporte, exceções de entrega e confirmação de entrega. A central de atendimento deve ser a fonte do histórico de conversas, status dos tickets, atribuições e notas dos agentes.
Essa distinção evita um erro comum de design: criar um fluxo de trabalho que pressupõe que o Shopify Flow pode identificar todos os problemas de entrega. O Flow pode reagir a eventos do Shopify e a informações disponibilizadas por aplicativos conectados ou serviços externos, mas não pode inferir um atraso da transportadora apenas porque um pedido foi processado. Um evento de processamento confirma que um registro ou status de processamento foi alterado; por si só, não comprova que o pacote está se movimentando normalmente.
Anote o evento de que você realmente precisa antes de selecionar um acionador. Por exemplo:
- “O pedido foi processado e o cliente deve receber a mensagem pós-compra padrão.”
- “Uma remessa tem uma exceção da transportadora e o suporte deve receber um caso prioritário.”
- “Um reembolso foi criado e o cliente deve ser encaminhado para a fila de reembolsos se já existir uma conversa.”
Arquitetura recomendada com Shopify Flow e uma central de atendimento
Há dois padrões práticos de conexão.
Padrão 1: usar uma integração nativa com a central de atendimento
Se sua central de atendimento tiver uma integração com o Shopify, instale-a e configure-a primeiro. As integrações nativas geralmente disponibilizam os detalhes do pedido dentro de um ticket ou permitem que os agentes abram o pedido relevante sem copiar dados manualmente. Os eventos e as ações exatos dependem da central de atendimento; portanto, confirme-os na documentação atual em vez de presumir que todos os eventos do Shopify são compatíveis.
Nesse padrão, o Flow pode cuidar da classificação no Shopify. Por exemplo, ele pode adicionar uma tag como post_purchase_priority quando um pedido atender aos seus critérios de suporte. A central de atendimento pode então usar essa tag, os dados do pedido ou um evento fornecido por um aplicativo para encaminhar a conversa.
Padrão 2: enviar uma solicitação HTTP pelo Flow
Quando nenhuma ação nativa cobre a transferência, o Shopify Flow pode enviar uma solicitação HTTP para um serviço de middleware, uma plataforma de automação ou um endpoint da central de atendimento onde essa opção seja compatível. O sistema receptor deve validar a solicitação, transformar o payload se necessário e criar ou atualizar um ticket.
Use esse padrão somente quando puder controlar a autenticação, a detecção de duplicidades, o tratamento de erros e os dados enviados ao serviço externo. Uma solicitação que simplesmente cria um novo ticket toda vez que o Flow é executado pode produzir rapidamente casos duplicados.
Fluxo de trabalho 1: transferência do processamento para o suporte ao cliente
Este é um bom fluxo inicial porque o processamento é um evento claro do Shopify e o resultado operacional é fácil de medir.
Etapa 1: escolher o acionador
No Shopify Flow, crie um fluxo de trabalho usando o acionador relacionado ao processamento que corresponda ao seu processo. O nome exato do acionador e as variáveis disponíveis podem mudar conforme o Shopify atualiza o Flow; portanto, selecione a opção atual exibida no seu admin e examine as variáveis disponíveis no editor do fluxo de trabalho.
Etapa 2: adicionar condições comerciais
Não envie todos os pedidos processados para um agente. Adicione condições que identifiquem uma exceção ou um segmento operacional útil. Os exemplos incluem:
- O pedido tem alta prioridade interna de suporte.
- O destino de envio pertence a um mercado com uma fila de atendimento separada.
- O pedido contém um produto que exige instruções pós-compra especiais.
- O pedido tem uma tag indicando uma reclamação anterior do cliente ou uma análise manual.
- O processamento é parcial e o cliente pode precisar de uma explicação.
Mantenha a primeira versão restrita. Uma regra como “todos os pedidos internacionais vão para o suporte” pode criar mais trabalho do que eliminar, a menos que exista um motivo operacional específico.
Etapa 3: escolher a ação
Para uma classificação de baixo risco, adicione uma tag ao pedido ou uma nota interna. Para um caso que precise de um responsável, envie uma notificação à central de atendimento ou crie um ticket por meio da integração. Inclua somente as informações de que a equipe receptora precisa:
- ID e número do pedido no Shopify
- Nome do cliente e identificador de contato
- País ou região de envio
- Status do processamento e referência de rastreamento, quando disponíveis
- Motivo do encaminhamento
- Fila e prioridade sugeridas
Se a API da central de atendimento exigir um formato JSON específico, use a documentação como contrato. Não tente adivinhar os nomes dos campos. No Flow, insira as variáveis pelo seletor de variáveis sempre que possível e compare o payload de teste com os campos exigidos pelo sistema receptor.
Etapa 4: evitar tickets duplicados
Use uma estratégia de idempotência. Antes de criar um novo caso, verifique se o pedido já tem uma tag de suporte, uma referência de ticket aberto ou um campo personalizado que indique que a transferência foi concluída. Se sua central de atendimento oferecer suporte a uma chave de idempotência, use um valor estável baseado no pedido e no evento, e não em um carimbo de data e hora. Se não oferecer, faça com que o middleware procure um caso aberto existente antes de criar outro.
Fluxo de trabalho 2: escalonamento de exceções de entrega
As exceções de entrega exigem mais cuidado porque o evento pode ter origem fora do Shopify. O Shopify Flow deve ser apenas a camada de ação se o aplicativo ou a integração de rastreamento passar um evento confiável para o Shopify ou para o endpoint usado pelo Flow.
Um design sólido funciona assim:
- Uma transportadora ou serviço de rastreamento informa uma exceção.
- O serviço de rastreamento ou middleware verifica se a remessa ainda está aberta e se uma exceção semelhante já foi processada.
- O sistema envia um evento estruturado para a central de atendimento ou para um endpoint compatível com o Flow.
- A central de atendimento cria ou atualiza um ticket, atribui a fila apropriada e exibe o contexto do rastreamento ao agente.
- Um agente decide se deve entrar em contato com o cliente, aguardar outra leitura, solicitar a confirmação do endereço ou oferecer uma solução aprovada.
Use uma lista controlada de categorias de exceção, como problema de endereço, atraso alfandegário, tentativa de entrega malsucedida, remessa danificada ou ausência de leitura recente. Evite prometer automaticamente uma data de entrega, a menos que o serviço subjacente forneça uma estimativa atual e sua política de atendimento ao cliente permita essa mensagem.
Se você usar o Flow para marcar o pedido relacionado, escolha tags que descrevam o estado, e não o resultado. carrier_exception_open é mais seguro do que delivery_failed quando a transportadora não confirmou uma falha definitiva.
Fluxo de trabalho 3: devoluções, reembolsos e perguntas pós-compra
Devoluções e reembolsos geralmente geram perguntas repetitivas, mas não devem ser combinados em uma única automação. Um reembolso pode estar concluído enquanto o cliente ainda aguarda o provedor de pagamento lançar os fundos. Uma devolução pode ter sido solicitada, mas ainda não recebida. Cada estado deve ter uma resposta diferente da central de atendimento ou uma instrução interna diferente.
Use o Shopify Flow para classificar eventos como uma solicitação de devolução, criação de reembolso, cancelamento ou atualização de pedido quando esses eventos estiverem disponíveis na configuração do Flow da sua loja. Encaminhe o resultado de acordo com sua política:
- Informativo: Adicione um rótulo interno e deixe a macro existente da central de atendimento responder às perguntas comuns.
- Sensível ao tempo: Crie ou priorize um ticket quando uma janela de serviço prometida estiver em risco.
- Análise manual: Encaminhe produtos danificados, reembolsos contestados ou históricos de pedidos incomuns a um especialista.
- Ação do cliente necessária: Solicite apenas as informações ausentes, como fotografias ou um endereço corrigido.
Se as devoluções forem gerenciadas por um aplicativo dedicado de devoluções, mantenha o status da devolução nesse sistema e transmita o status necessário ao Shopify ou à central de atendimento. Não mantenha status manuais concorrentes em três sistemas, a menos que exista um processo claro de reconciliação.
Como configurar a transferência para a central de atendimento
Antes de ativar uma ação externa, prepare o lado da central de atendimento.
Defina filas e responsabilidades
Crie filas que correspondam a decisões reais, e não apenas a rótulos amplos. “Exceção de entrega”, “correção de endereço” e “análise de reembolso” geralmente levam a procedimentos diferentes. Atribua uma fila alternativa para eventos incompletos ou não reconhecidos, para que as falhas de automação não desapareçam.
Crie um esquema compacto de eventos
Use nomes e valores de campos consistentes. Um evento prático pode incluir event_type, event_id, shopify_order_id, order_number, customer_reference, tracking_number, reason_code, priority e occurred_at. Envie um ID de evento estável e registre-o no lado receptor.
Minimize os dados pessoais. A central de atendimento talvez já consiga recuperar o perfil do cliente pelo número do pedido; portanto, não envie mais informações do cliente do que a integração exige.
Defina a regra de contato com o cliente
Decida quais eventos criam um ticket interno, quais enviam uma mensagem ao cliente e quais fazem as duas coisas. Uma exceção da transportadora geralmente justifica uma análise interna antes de um e-mail automático. Uma confirmação padrão de processamento pode ser adequada para um modelo aprovado. A regra deve ser registrada na documentação do fluxo de trabalho para que os agentes saibam por que uma mensagem foi enviada.
Lista de verificação de testes e monitoramento
Teste em etapas, em vez de ativar todas as ações de uma só vez.
- Teste o acionador: Confirme que o evento selecionado é executado para os tipos de pedido esperados e não para alterações não relacionadas.
- Teste as condições: Use exemplos positivos e negativos, incluindo processamento parcial, destinos internacionais, reembolsos e pedidos com tags existentes.
- Inspecione o payload: Verifique identificadores do pedido, dados de rastreamento, datas, prioridade e código do motivo. Confirme que campos vazios não interrompem a API receptora.
- Teste o comportamento de duplicidade: Execute o mesmo evento mais de uma vez e confirme que ele não cria vários tickets ativos.
- Teste o tratamento de falhas: Use temporariamente um endpoint inválido ou um campo obrigatório em um ambiente controlado. Confirme que a falha fica visível para um responsável.
- Faça um lançamento limitado: Comece com uma fila, um mercado ou um tipo de evento. Analise os tickets e o feedback dos agentes antes de expandir.
Monitore tanto os resultados operacionais quanto os resultados para os clientes. As métricas úteis incluem o número de transferências automatizadas, tickets duplicados, tickets sem atribuição, solicitações com falha, tempo até a primeira análise humana e a porcentagem de casos encaminhados que os agentes reclassificam. Uma automação que cria mais tickets, mas não melhora a atribuição ou a resolução, não está funcionando bem, mesmo que o histórico de execuções do Flow mostre sucesso.
Erros comuns a evitar
- Usar o processamento como prova de entrega: Processamento e entrega são estados diferentes.
- Criar um ticket para cada pedido: Use condições e limites de encaminhamento para reservar os agentes para as exceções.
- Enviar identificadores instáveis: Números de pedido, IDs de evento e referências de rastreamento devem ser mapeados de forma consistente.
- Ignorar a autenticação: Trate um endpoint HTTP que recebe dados de clientes ou pedidos como um serviço protegido.
- Ignorar limites do aplicativo e do plano: Confirme quais ações do Flow, acionadores, chamadas de API e recursos da central de atendimento estão disponíveis na sua configuração atual.
- Automatizar decisões de política: Deixe o Flow classificar casos rotineiros, mas mantenha reembolsos, compensações, alterações de endereço e suspeitas de fraude dentro das regras aprovadas e da análise humana.
Uma sequência prática de implementação
Para a maioria das lojas Shopify, a sequência mais segura é começar com uma tag ou notificação interna, depois adicionar o encaminhamento para a central de atendimento e somente mais tarde introduzir a automação voltada ao cliente. Comece com um evento fácil de verificar, como uma exceção de processamento ou um estado de reembolso conhecido. Documente o acionador, as condições, a ação, o responsável, a regra de duplicidade e o caminho de falha. Depois que o fluxo de trabalho produzir resultados estáveis, adicione mais tipos de evento, um de cada vez.
O melhor design não é aquele com mais ações do Flow. É aquele que fornece aos agentes de suporte o contexto certo no momento certo, deixa um registro auditável e evita fazer o cliente repetir informações já disponíveis no Shopify ou no sistema de rastreamento relevante.
FAQ
O Shopify Flow pode criar diretamente um ticket na central de atendimento?
Isso depende da central de atendimento e da integração disponível na sua loja. Se uma ação nativa do Flow não estiver disponível, uma solicitação HTTP pode transmitir dados do evento para um serviço de middleware ou para um endpoint da central de atendimento, quando compatível. Confirme os requisitos de autenticação, payload e criação de tickets do sistema receptor antes de ativar o fluxo de trabalho.
O Flow pode detectar que um pacote está atrasado?
Não apenas pelo status de processamento. Uma remessa atrasada exige uma regra de tempo de entrega e uma fonte confiável de eventos da transportadora ou de rastreamento. Use uma integração ou serviço de rastreamento que forneça esses sinais e, em seguida, encaminhe o evento para a central de atendimento ou para o fluxo de trabalho apropriado do Shopify.
Todo evento pós-compra deve criar um ticket?
Não. Use tags, notificações internas ou automações existentes da central de atendimento para eventos de baixo risco. Crie um ticket quando uma pessoa precisar investigar, entrar em contato com o cliente, aprovar uma solução ou monitorar uma exceção.
Como interromper tickets duplicados?
Use um ID de evento estável ou uma chave baseada no pedido e no evento, verifique se já existe um ticket aberto e registre o resultado da transferência. Uma tag como support_handoff_complete pode ajudar em fluxos simples, mas uma consulta à central de atendimento ou ao middleware é mais segura quando os eventos podem ser repetidos.
O que deve ser testado antes do lançamento?
Teste o acionador, as condições, o mapeamento de dados, as permissões, o comportamento de duplicidade, os alertas de falha e o texto voltado ao cliente. Inclua processamento parcial, dados de rastreamento ausentes, eventos repetidos, reembolsos e pedidos que já tenham um caso de suporte.
