O CMO diz-lhe, convicto: temos um programa de fidelização e funciona. Pontos, um cartão, descontos por níveis, o habitual. Aparentemente, está tudo em ordem. Depois faz-lhe uma pergunta muito simples: esse cliente que acumula pontos na loja consegue ver o seu saldo na app? Normalmente, não há resposta. Não é que o programa esteja avariado, propriamente. É que só funciona num dos sítios onde o cliente compra, e hoje quase ninguém se limita a um único canal de venda. Um cartão que vive na loja mas não existe no site, ou o contrário, o que também acontece, é provavelmente o erro mais comum no retalho de média dimensão. E o mais difícil de detetar a tempo, porque não aparece em nenhum relatório até alguém decidir olhar, com calma, para o que realmente se passa. Este é o primeiro caso da série Autópsia da Fidelização: o diagnóstico, a causa real e a prescrição para perceber porque é que o seu programa vive dividido em dois sem que ninguém o tenha decidido de propósito. Porque, no fim de contas, ninguém desenha um programa para funcionar só metade do tempo.
O diagnóstico: um programa que o cliente não consegue tocar
Imagine um cliente habitual de uma cadeia de moda. Dois anos a acumular pontos na loja. Cartão físico, número de sócio, a sensação vaga mas real de que tem algo guardado ali. Um domingo qualquer compra no site, chega ao checkout e não há rasto do saldo. Abre a app e também não há nada. Liga para o apoio ao cliente e o agente não consegue realmente ajudar, porque esses dados vivem apenas na caixa registadora da loja física. Na prática, esse cliente tem dois programas de fidelização do mesmo retalhista que não comunicam entre si. Um para a loja e outro, bastante mais pobre, para tudo o resto. E esse "tudo o resto" é, ano após ano, onde mais gasta.
Isto não é propriamente novo. Tem um precedente bem conhecido: o clássico cartão de fidelização, daqueles de carimbos e desconto na caixa, nunca captou toda a atividade de um cliente.
30-40%
das transações foi o máximo que um cartão de fidelização clássico alguma vez conseguiu captar; o resto ficava sem registo, sem nome e sem forma de acompanhamento.
O programa de pontos de hoje herda esse mesmo limite, com uma diferença: agora o canal invisível já não é "o que nunca foi registado", mas "o que foi registado no sítio errado". O cliente acumula pontos, só que não onde mais tarde os quer usar. E aqui está o curioso: o sintoma não aparece em nenhum painel de vendas. A faturação continua a entrar, o programa parece vivo, nenhum alarme dispara. O problema só se torna visível quando alguém se senta a medir a participação real: quantos clientes inscritos resgataram alguma coisa nos últimos doze meses, quantos compraram em mais de um canal. É então que os números deixam de bater certo. E o mais estranho, e isto é realmente surpreendente quando se pára para pensar, é que ninguém está a mentir. A loja vê o programa a funcionar porque, nesse canal, funciona. O e-commerce nem sequer o conta nas suas métricas porque, do seu ponto de vista, esse programa simplesmente não existe: não aparece no seu checkout, não entra nos seus números de conversão. Cada equipa tem razão quanto aos dados que gere, e é essa a armadilha. O problema não vive em nenhum relatório em particular; vive no intervalo entre relatórios.
Porque acontece: a fidelização como sistema acoplado ao checkout
A causa raramente é negligência; é arquitetura, e antiga. O programa de fidelização nasceu, na maioria dos retalhistas, como um módulo do sistema de caixa: um complemento do terminal POS para somar pontos quando alguém pagava na loja. Na altura fazia todo o sentido, porque quase todo o negócio passava por ali. O problema é que o negócio mudou e o programa ficou parado. Chegou o e-commerce, depois a app, depois o WhatsApp como canal de compra e de apoio, e o módulo de fidelização continuou a viver exatamente onde nasceu: no POS. É uma falha de conceção, não falta de intenção, e vale a pena dizê-lo com clareza, porque costuma ser lido ao contrário. Ninguém acordou um dia e decidiu "vamos recompensar só os clientes da loja". Simplesmente, o sistema que gere o benefício nunca foi construído para comunicar com o checkout online, e ligá-lo depois, sobre um sistema que não foi pensado para isso, revela-se caro, lento e, muitas vezes, nunca chega a ficar bem feito. E é aqui que muitos retalhistas ficam presos durante anos: a solução "óbvia", integrar manualmente o sistema de pontos atual com o e-commerce, costuma implicar mexer no POS, no ERP e no motor de preços da loja online. Não é que ninguém queira resolver. É que fazê-lo assim se transforma num projeto que compete por orçamento e tempo de IT com outras prioridades mais urgentes. E entretanto o remendo nunca chega. A verdadeira mudança de paradigma é outra: o benefício não é calculado nem aplicado num módulo isolado, mas consultando os dados do cliente em tempo real, no próprio momento do pagamento, seja qual for o canal em que esse pagamento ocorre. Quando a fidelização vive na gateway transacional do checkout, e não num canto do sistema de caixa, deixa de importar se o cliente paga na loja, na web ou no telemóvel: o motor consulta os mesmos dados. Aplica o mesmo benefício em qualquer um dos três sítios.
O custo silencioso de um programa fragmentado
A parte mais cara deste erro não é técnica, é de confiança, e isto é mais grave do que parece. Um cliente que não consegue consultar o seu saldo, ou que descobre que o que ganhou na loja não vale nada online, aprende depressa uma lição incómoda: neste programa não se pode confiar, por isso é melhor não contar com ele. Deixa de consultar o saldo, deixa de esperar o benefício, e o negócio perde exatamente aquilo que um programa de fidelização deve gerar: uma razão para voltar. Além disso, esse cliente acaba por ligar ao apoio ao cliente para perguntar algo que devia poder resolver sozinho. "Quantos pontos tenho?" não deveria exigir um agente do outro lado do telefone. E de cada vez que exige, há um custo operacional que ninguém orçamentou para o programa de fidelização. E depois há os dados, que são, talvez, o dano menos visível de todos. Se o sistema de pontos vive separado do resto da operação, o comportamento do cliente também fica dividido por dois registos que não comunicam entre si. A equipa de marketing não consegue saber se o mesmo cliente que compra na loja também compra online, porque o sistema, literalmente, não o sabe. E isto atinge exatamente onde mais custa ao CMO: o CLTV e a margem. Se não se vê o cliente inteiro, não se sabe quanto ele realmente vale, nem que esforço de retenção merece. Um cliente que compra pelos dois canais pode parecer, em relatórios separados, dois clientes medianos em vez de um cliente muito bom, e as decisões de investimento em fidelização tomadas com essa meia imagem tendem a correr mal quase por definição, por muito bem pensada que a estratégia pareça no papel.
A prescrição: fidelização omnicanal real
A solução não é "esforçar-se mais" com o programa atual. É mudar o sítio onde vivem os dados do cliente. Uma Carteira de cliente unificada resolve o problema pela raiz: um único espaço digital que reúne o saldo, o histórico e os benefícios do cliente, acessível a partir de diferentes ambientes, integrado na app do próprio retalhista, numa app em marca branca, através da Apple Wallet ou da Google Wallet com Mobile Pass, ou diretamente a partir do navegador, mas mostrando sempre o mesmo conteúdo, a mesma experiência, atualizada em tempo real. Na prática, isto significa que os pontos ganhos na loja podem ser resgatados no site de e-commerce e vice-versa, sem atrasos nem sincronizações manuais, com o mesmo saldo visível em qualquer ponto de contacto que o cliente queira consultar. Quem costumava ligar para perguntar o saldo deixa de ter esse problema: pode consultá-lo sozinho, de imediato, a partir do sítio que lhe for mais conveniente. Veja-se um caso concreto: um cliente compra na loja num sábado e ganha pontos. No domingo, do sofá, entra no site do mesmo retalhista e vê esse saldo atualizado na sua conta, não uma versão de há uns dias, o real. Resgata alguns desses pontos numa compra online. O sistema deduz-os desse mesmo saldo único, não de uma cópia separada. Se essa pessoa voltar à loja física na semana seguinte, o saldo que o funcionário vê na caixa é, mais uma vez, o mesmo. Não há uma "versão loja" e uma "versão web" do cliente. Há um cliente, com um saldo, visível a partir de qualquer lado. E essa continuidade é exatamente o que o cliente entende por "estar inscrito num programa de fidelização". Não é pedir muito. É simplesmente o mínimo que se espera de algo que tem esse nome. Nem sequer é preciso mexer no ERP nem no motor de preços do e-commerce para que isto aconteça: o benefício é calculado e aplicado no checkout, através de uma gateway, consultando os dados existentes no momento do pagamento. O marketing ganha autonomia sobre o programa sem depender de um longo projeto de integração, e a equipa de IT não tem de abrir um novo pedido de desenvolvimento sempre que muda uma regra do programa. E isto não exige o projeto de um ano que tantas equipas temem. Os projetos empresariais de CDP mais fidelização costumam seguir ciclos de 8 a 18 meses. Uma integração construída sobre uma única API de checkout, pelo contrário, avança em semanas: a maioria dos casos entra em produção entre 4 e 12 semanas, consoante o integrador do ponto de venda do retalhista. Não é mais uma promessa de marketing. É a diferença entre reescrever de raiz o sistema de caixa e ligar uma gateway por cima dele.
Como saber se o seu programa sobreviveria a esta autópsia
Antes de assumir que isto não se aplica a si, vale a pena colocar cinco perguntas concretas. Nenhuma exige uma análise técnica profunda; respondem-se olhando para a experiência real do cliente, não para a ficha de produto do fornecedor atual.
- O cliente vê o mesmo saldo de pontos na loja, na app e no site, sem diferenças?
- O que se ganha na caixa pode ser resgatado online, e o que se ganha online pode ser resgatado na caixa?
- O apoio ao cliente consegue consultar o saldo de qualquer cliente, independentemente do canal em que comprou?
- O marketing consegue lançar um novo benefício sem abrir um pedido de IT para mexer no sistema de caixa?
- Sabe, com dados reais, que percentagem dos seus clientes inscritos resgatou alguma coisa nos últimos doze meses?
Se alguma destas perguntas o deixa a pensar em vez de responder logo que sim, o seu programa tem, no mínimo, uma versão deste mesmo problema. E não há mal nenhum em admiti-lo: é, de longe, o mais comum dos quatro erros que vamos abordar nesta série, o que, visto de outro ângulo, é na verdade uma boa notícia. Significa que a solução já está provada. Não há nada a inventar de raiz.
Uma fidelização que o cliente não consegue tocar não constrói fidelidade. Este é o primeiro caso da Autópsia da Fidelização, a série em que a Wapping analisa, caso a caso e sem citar marcas, os erros mais comuns e mais silenciosos dos programas de fidelização no retalho. A seguir: o que acontece quando um desconto é enviado a toda a base de clientes por igual, sem distinguir quem realmente precisava dele de quem não.