
A maioria dos roteiros de carteiras assenta num pressuposto silencioso: que "móvel" significa "aplicação para smartphone". Nos mercados onde o dinheiro móvel mais importa, esse pressuposto deixa de fora, logo no primeiro dia, a maioria da população alcançável. Uma grande parte dos clientes ainda usa um telemóvel básico. Muitos dos que têm smartphone racionam os dados com tanto cuidado que uma aplicação que não podem pagar para atualizar é uma aplicação que não usam. Se a sua carteira existe apenas como aplicação, não construiu para o seu mercado: construiu para a fatia dele que já se parece consigo.
O USSD é a forma de chegar aos restantes. É pouco glamoroso, limitado e tem décadas, e é a decisão de canal mais importante que um operador focado na inclusão toma. Eis o que é, porque funciona e o que é preciso para o fazer bem.
O que é realmente o USSD
O USSD (Unstructured Supplementary Service Data) é a tecnologia por trás dos códigos *123# que se marcam para consultar o saldo de chamadas. Ao contrário do SMS, funciona por sessão e em tempo real: quando um cliente marca um código, a rede abre uma sessão ao vivo entre o telemóvel e um serviço de backend, e acontece uma curta conversa (menu, escolha, menu, escolha) até a tarefa estar concluída. Corre no canal de sinalização que todos os telemóveis GSM têm desde os anos 90, e é exatamente por isso que funciona num aparelho de vinte dólares, sem internet e sem aplicação.
A experiência do cliente é uma sequência de menus numerados. Marque o código. 1 para Enviar dinheiro. Introduza o número. Introduza o valor. Confirme com o seu PIN. Sem descarga, sem pacote de dados, sem configuração além da própria carteira. Para uma população enorme, isto não é um recurso de reserva: é a forma principal, e muitas vezes a única, de alguma vez tocarem num serviço financeiro digital.
A carteira inteira, num código de marcação
O erro dos operadores é tratar o USSD como um menu reduzido (consulta de saldo e talvez um envio), reservando "o produto verdadeiro" para a aplicação. Bem feito, o USSD gere a carteira do dia a dia: enviar dinheiro, levantar num agente, pagar contas, pagar a comerciantes, comprar saldo, consultar o saldo e obter um mini-extrato. São as transações que as pessoas fazem todas as semanas, e cada uma é protegida por PIN e confirmada antes de ser lançada. Percursos mais ricos, como pedir um empréstimo ou gerir um objetivo de poupança, podem seguir o mesmo padrão à medida que o menu cresce.
O pormenor mais importante é invisível para o cliente: um envio por USSD e um envio pela aplicação são a mesma transação, no mesmo razão, com os mesmos limites, o mesmo nível de KYC e a mesma pista de auditoria. O canal é uma porta diferente para a mesma casa. Isto não é uma conveniência de implementação: é uma garantia de correção. Se o USSD e a aplicação fossem caminhos de código separados com regras separadas, iriam divergir, e o limite de um cliente num canal seria diferente do outro, exatamente o tipo de lacuna que se torna um vetor de fraude e uma não conformidade.
As restrições que moldam um bom design USSD
O USSD é um meio de design hostil, e respeitar as suas restrições é o que separa um canal que as pessoas usam de um que abandonam a meio da sessão.
- Ecrãs minúsculos, textos curtos. Uma página USSD é um punhado de linhas de texto simples. Em muitos aparelhos não há deslocamento, imagens nem formatação. Cada menu tem de merecer cada carácter. Listas longas de opções devem ser paginadas com uma convenção "0. Seguinte" que pareça natural a utilizadores que o fazem há anos.
- As sessões expiram. As redes fecham sessões inativas após uma janela curta definida pelo operador, muitas vezes bem abaixo de dois minutos. Um fluxo que faz demasiadas perguntas expira antes de o cliente terminar, deixando-o sem resposta. Um bom design USSD reduz implacavelmente os passos e nunca obriga o cliente a ir buscar a meio do fluxo informação que o sistema já conhece.
- A latência sente-se. Entre cada menu, o cliente olha para um estado de "a carregar" num canal de sinalização lento. Cada ida e volta ao backend do motor de menus é tempo em que o cliente se pergunta se algo avariou. O motor tem de ser rápido e de falhar de forma clara.
- O estado vive no servidor. O aparelho não se lembra de nada entre páginas. O motor de menus tem de guardar o estado da conversa (onde está o cliente, o que introduziu), associado à sessão, e reconstruí-lo a cada passo. Se a máquina de estados estiver errada, os clientes reintroduzem dados ou vão parar ao ecrã errado.
Como se encaixa na rede mais ampla
O USSD não existe sozinho; é um canto de um sistema que tem de funcionar em conjunto.
- O gateway. Uma operadora ou um agregador USSD encaminha cada passo da sessão para um único endpoint de backend. O motor de menus interpreta a entrada, avança a máquina de estados e devolve o ecrã seguinte, ou uma confirmação final. Suportar vários agregadores por trás de um só motor é o que permite à mesma carteira funcionar em vários países e redes.
- A rede de agentes. Um saldo digital só é útil se puder transformar-se em numerário e vice-versa. Os agentes completam o USSD: o cliente deposita num agente, faz transações por USSD e levanta noutro agente. Sem rede de float, os utilizadores de USSD ficam com um valor que não podem gastar na economia física onde a maioria ainda vive.
- A língua. Os menus devem falar com os clientes na língua em que pensam. Num mercado com várias línguas principais, árvores de menus traduzidas são a diferença entre um canal que inclui e um que exclui discretamente; planeie-as desde o primeiro menu que escrever.
Anatomia de uma sessão USSD
Por trás dos menus, uma sessão USSD é uma curta troca de texto entre o gateway e o seu motor de menus. Sempre que o cliente responde, o gateway envia todo o percurso de respostas até então, separadas por asteriscos, e o seu motor responde com o ecrã seguinte. Uma resposta que começa por CON mantém a sessão aberta; uma que começa por END fecha-a. Um envio pode ser assim:
| Passo | O cliente vê | O cliente introduz | Percurso enviado ao motor |
|---|---|---|---|
| 1 | Menu principal: 1. Enviar dinheiro, 2. Levantar … | 1 | 1 |
| 2 | Introduza o número do destinatário | 254712000002 | 1*254712000002 |
| 3 | Introduza o valor | 500 | 1*254712000002*500 |
| 4 | Enviar 500 para 254712000002. Introduza o PIN para confirmar | PIN | 1*254712000002*500*PIN |
| 5 | Enviado. Taxa, novo saldo, referência | — | Sessão termina |
Daqui decorrem dois princípios de design. O motor não guarda estado entre passos, porque o percurso transporta toda a conversa, o que o torna simples de escalar. E o percurso contém o PIN no passo de confirmação, o que é importante para a segurança.
Segurança num canal que não controla totalmente
O tráfego USSD passa pela rede móvel e pelo agregador antes de chegar até si, e o aparelho não oferece cifra ao nível da aplicação. Boas práticas mantêm o risco baixo:
- Nunca guarde o PIN. Os registos de sessão são valiosos para resolver litígios, mas a posição do PIN no percurso tem de ser mascarada antes de qualquer coisa ser escrita em disco ou mostrada à equipa.
- Verifique o PIN no núcleo, contra um valor com hash, e bloqueie a carteira após falhas repetidas.
- Mantenha limites idênticos aos da aplicação. Um canal com limites mais folgados torna-se o canal preferido dos burlões.
- Vigie as trocas de SIM. Onde a rede móvel disponibiliza dados de troca de SIM, uma troca recente seguida de uma transferência grande merece retenção ou verificação.
- Aceite tráfego apenas do seu gateway, por regras de rede ou segredos partilhados, para que ninguém possa enviar sessões falsas diretamente ao seu motor.
- Confirme por SMS. Um recibo após cada transação dá aos clientes um registo e um incentivo para comunicar algo que não fizeram.
Desenhar menus para todos
Muitos utilizadores de USSD leem devagar ou numa segunda língua, e alguns dependem de familiares para ajudar. Os menus que funcionam para eles partilham alguns hábitos:
- Use a mesma ordem e numeração em todo o lado, para criar memória muscular. Se Enviar dinheiro é o 1 hoje, tem de ser o 1 no próximo ano.
- Use verbos simples: Enviar, Pagar, Levantar, Comprar. Evite nomes de produtos internos no menu principal.
- Repita os factos essenciais no passo de confirmação: para quem, quanto e a taxa, antes de pedir o PIN.
- Escreva mensagens de erro que digam ao cliente o que fazer a seguir, não apenas o que correu mal.
- Teste com utilizadores reais em telemóveis básicos reais, no terreno, antes do lançamento e após cada alteração de menu.
Medir o canal USSD
O desempenho do USSD é fácil de ignorar porque é invisível nas análises das aplicações. Acompanhe-o deliberadamente:
| Métrica | O que lhe diz |
|---|---|
| Taxa de conclusão de sessões | Quantas sessões terminam numa transação concluída em vez de expiração ou abandono |
| Abandono por passo | Que ecrã perde clientes, normalmente o que pede informação que não têm à mão |
| Tempo de resposta por passo | Se o seu motor ou um parceiro está a fazer os clientes esperar |
| Taxa de PIN incorreto | Problemas de usabilidade, ou alguém a tentar adivinhar |
| Quota de transações por canal | Quantos clientes dependem do USSD, e se isso está a mudar |
USSD versus aplicação: não uma hierarquia, mas um portefólio
É tentador ordenar os canais: aplicação primeiro, web depois, USSD em último. Essa ordem codifica o enviesamento que causou o problema. O enquadramento certo é um portefólio em que cada canal serve uma população e um momento. A aplicação é mais rica para quem tem o aparelho e os dados. A web serve utilizadores de computador e empresas. O USSD serve o telemóvel básico, o plano de dados racionado, o momento de cobertura fraca em que uma aplicação não carrega mas uma sessão de sinalização passa. Um operador sério corre todos sobre um único núcleo e deixa os clientes escolher. A função da plataforma é garantir que, por baixo, é a mesma carteira.
A inclusão é uma decisão de arquitetura
A "inclusão financeira" aparece em todas as apresentações de dinheiro móvel, normalmente como valor, raramente como uma restrição que molda a construção. Mas a inclusão não é um slogan que se acrescenta no fim: é uma decisão tomada no início, quando escolhe se o USSD é um canal de primeira linha com o produto completo por trás, ou um pormenor secundário com uma consulta de saldo. Os mercados que saltaram para o dinheiro móvel fizeram-no com USSD, porque era o que as pessoas tinham nas mãos. Construir para elas significa construir o canal que realmente têm.
Trabalhar com redes e agregadores
A maioria dos operadores chega ao USSD através de um agregador ligado a várias redes móveis, que encaminha as sessões para um único endpoint. Escolha agregadores pela fiabilidade e pelo alcance, não só pelo preço: peça as suas taxas de sucesso de sessão, o tempo de resposta até ao seu motor, como lidam com falhas de rede e se conseguem fornecer códigos em todas as redes que os seus clientes usam. Acorde níveis de serviço por escrito, monitorize-os do seu lado e tenha um segundo agregador em mente para mercados críticos. Quando uma rede muda o tempo de expiração das sessões ou o encaminhamento, quer sabê-lo antes dos seus clientes.
Um plano piloto para um novo canal USSD
- Semanas 1–2: ligue o gateway em teste, percorra todos os caminhos de menu em telemóveis básicos reais em cada rede e meça os tempos de resposta.
- Semanas 3–4: convide a equipa e agentes de confiança a usar o canal com valores reais pequenos; recolha todas as mensagens de erro que virem.
- Semanas 5–8: abra aos clientes de uma zona com agentes ativos, acompanhe a conclusão e o abandono por passo, e corrija o pior ecrã todas as semanas.
- A partir da semana 9: expanda zona a zona, acrescentando agentes antes da procura, para que cada novo cliente USSD tenha onde depositar e levantar.
O piloto é também o momento de escrever os guiões de apoio. Os clientes de telemóveis básicos não conseguem enviar uma captura de ecrã, por isso a equipa de apoio precisa de ver o percurso da sessão, com o PIN mascarado, para perceber o que aconteceu.
Porque o USSD importa para o modelo de negócio
O USSD é por vezes visto como um centro de custos para a inclusão. Na prática, carrega muitas vezes uma grande parte das transações em mercados com muitos telemóveis básicos, e esses clientes podem estar entre os mais fiéis, porque mudar é mais difícil para eles. Cada cliente que só o consegue alcançar por USSD é também um cliente que os seus concorrentes limitados a aplicações não conseguem servir de todo. Vista assim, o USSD é menos caridade e mais uma vantagem defensiva.
Quando algo corre mal a meio da sessão
As sessões falham: a rede corta a sessão, o saldo do cliente muda entre ecrãs, ou um parceiro não responde a tempo. O cliente de telemóvel básico não tem aplicação para verificar depois, por isso o canal tem de fechar todos os ciclos. Se uma transação foi concluída, um recibo por SMS confirma-a mesmo que o ecrã final nunca tenha chegado. Se não foi concluída, o cliente deve ser informado com clareza e nada deve ser debitado. Se o resultado for incerto, por exemplo um pagamento a um parceiro que ainda não confirmou, o cliente deve receber uma mensagem a dizer que o pagamento está a ser confirmado, seguida do resultado final. Os clientes perdoam uma falha explicada; não perdoam dinheiro que desaparece em silêncio.
Perguntas frequentes
O USSD custa alguma coisa ao cliente?
Depende do mercado e do acordo com a rede móvel. Muitos operadores absorvem ou isentam os custos de sessão USSD, porque um canal gratuito impulsiona a adoção entre os clientes que mais precisam dele.
O USSD pode funcionar sem acordo com a rede móvel?
Não. Um código curto USSD é atribuído e encaminhado pela rede móvel, normalmente através de um agregador. Garantir códigos em todas as redes que os seus clientes usam faz parte do plano de lançamento.
O USSD vai desaparecer com a expansão dos smartphones?
A adoção de smartphones está a crescer, mas os telemóveis básicos continuam comuns, e muitos utilizadores de smartphone ainda racionam dados. O uso de USSD em mercados de dinheiro móvel maduros continua significativo, e é muitas vezes a alternativa quando a cobertura de dados falha.
Os agentes também podem usar USSD?
Sim. Os agentes em zonas com fraca cobertura de dados beneficiam do mesmo canal para servir clientes, desde que os seus menus, limites e comissões venham do mesmo núcleo que a aplicação de agente.
A PesaBridge trata o USSD como um canal de primeira linha: um motor de menus por trás de uma interface de gateway USSD padrão, apoiado pela rede de agentes e a correr exatamente o mesmo razão equilibrado, os mesmos limites e as mesmas taxas que as aplicações. Assim, o cliente de telemóvel básico tem a carteira do dia a dia, e não um subconjunto simpático dela.