O formulário de morada é o mais longo do processo de compra e o que produz mais abandonos depois da escolha do modo de entrega. Numa loja portuguesa a vender a clientes portugueses, metade dos campos apresentados por omissão não serve para nada.
A análise geral do checkout no telemóvel foi tratada à parte. Este artigo trata do formulário de morada em si.
O que é realmente necessário
Para entregar em Portugal, sete informações chegam.
Nome próprio, apelido, rua e número de porta, código postal, localidade, país, telemóvel.
Tudo o resto é facultativo ou depende da sua atividade. Vejamos os campos habitualmente apresentados e o que valem.
A empresa só serve em B2B. Numa loja de grande público, ocupa uma linha para nada. Numa loja mista, revela-se conforme o tipo de conta.
O NIF merece um tratamento próprio em Portugal, e é a diferença principal face a outros mercados. Muitos clientes particulares querem a fatura com o número de contribuinte, para despesas de saúde, educação ou dedução. O PrestaShop não tem campo NIF próprio: usa-se o campo de número de identificação fiscal previsto para o IVA. Mantenha-o visível e facultativo também em B2C, com a menção de que serve para a fatura.
O complemento de morada é útil, deve ficar facultativo e discreto. Muitas configurações apresentam dois campos de complemento, o que é excessivo. Em Portugal serve sobretudo para andar, fração e lote.
O telefone fixo e o telemóvel em dois campos distintos já não fazem sentido. Um campo chega, e o telemóvel é o que serve à transportadora.
A etiqueta da morada, «Casa» ou «Escritório», só interessa a um cliente que guarda várias moradas. Gere-a automaticamente e não a peça na primeira encomenda.
O código postal e a localidade
É o ganho mais rápido do formulário.
Em Portugal, o código postal de sete dígitos identifica a localidade e, na maioria dos casos urbanos, a própria artéria. Um código introduzido pode portanto preencher a localidade e propor a rua, a partir da base de códigos postais dos CTT.
Três benefícios: um campo a menos para escrever, menos erros de digitação e um controlo de coerência gratuito entre os valores.
Quatro precauções técnicas.
O campo tem de aceitar o formato 0000-000, com e sem hífen, e chamar um teclado numérico no telemóvel.
A localidade tem de continuar editável. Há freguesias e lugares que o cliente prefere usar em vez do nome oficial da localidade postal.
Os códigos de quatro dígitos antigos, ainda escritos por alguns clientes, devem ser aceites e completados em vez de rejeitados.
Os códigos das regiões autónomas, que começam por 9, têm de ser reconhecidos, o que nem sempre acontece em bases de correspondência incompletas.
Checkout Simples e Elegante para PrestaShopUm checkout de página única elegante que converte99,00€
O caso dos Açores e da Madeira
Assunto mal tratado por muitas lojas, e que produz encomendas impossíveis de honrar.
Três pontos a decidir explicitamente.
Entrega? Se não, a zona tem de ser excluída das opções, não deixada selecionável para dar erro no momento do pagamento.
Os portes e os prazos são diferentes. Um tarifário de continente aplicado a uma entrega insular faz-lhe perder dinheiro em cada encomenda. Uma dificuldade adicional: o PrestaShop não fornece estados ou regiões para Portugal, pelo que a separação se faz por prefixo de código postal ou por transportadoras distintas.
A fiscalidade é diferente. As regiões autónomas têm taxas de IVA próprias, mais baixas do que as do continente, o que tem consequências nos preços apresentados e nos seus documentos. É um ponto a validar com o contabilista em vez de improvisar.
A configuração mínima consiste em distinguir estes destinos nas suas zonas de entrega, com as suas próprias transportadoras e as suas próprias regras.
O preenchimento automático
É a medida mais rentável do formulário, e só exige acrescentar atributos.
Os navegadores e os gestores de palavras-passe sabem preencher um formulário de morada completo num gesto, desde que cada campo declare o que espera: nome próprio, apelido, linha de morada 1, código postal, localidade, país, telefone.
Sem essas declarações, o navegador não reconhece nada e o cliente escreve tudo.
Dois pontos complementares. O nome dos campos também conta: nomes técnicos como «field_3» impedem qualquer reconhecimento heurístico. E a estrutura tem de se manter clássica: um formulário reconstruído dinamicamente com componentes exóticos perde essa compatibilidade.
Um teste simples: abra o seu checkout num navegador onde já exista uma morada guardada e clique no campo do nome. Se não for proposto nada, faltam-lhe os atributos.
A autocompletar da morada
Nível seguinte, a implementar depois dos pontos anteriores.
O princípio: o cliente escreve os primeiros carateres da morada, aparece uma lista de propostas, ele seleciona e todos os campos se preenchem.
Três benefícios mensuráveis: tempo de escrita dividido, erros de digitação eliminados e moradas normalizadas, o que reduz as falhas de entrega.
Duas precauções. O campo manual tem de continuar acessível, para as moradas recentes ou atípicas que a base não conhece. E o uso de um serviço externo obriga a verificar o que é transmitido e a mencioná-lo na sua política de privacidade.
Ponto prático: não existe em Portugal uma base pública gratuita de moradas equivalente à que a França disponibiliza. As duas vias realistas são a base de códigos postais dos CTT, sob licença, e um serviço comercial como o Google Places.
A validação
Quatro regras que reduzem os erros sem irritar.
Valide ao longo da escrita, campo a campo, em vez de mostrar cinco erros depois de submeter.
Valide à saída do campo, não a cada carater. Uma mensagem de erro que aparece logo na primeira letra é irritante.
Seja tolerante no formato. Um número de telefone escrito com espaços, pontos ou o indicativo +351 tem de ser aceite e normalizado, não rejeitado. Em Portugal, o telemóvel começa por 9 e o fixo por 2, e não existe prefixo interurbano a retirar.
Formule o erro em ação. «O código postal tem sete dígitos, no formato 1000-001» vale mais do que «Campo inválido».
A morada de faturação
Questão a decidir, porque duplica o formulário.
Numa loja de grande público, a morada de faturação é igual à de entrega na grande maioria dos casos. O comportamento esperado é portanto uma caixa assinalada por omissão, com o segundo formulário recolhido.
Duas exceções. Em B2B, a dissociação é frequente e tem de continuar fácil de aceder. Nas prendas, também, em que quem paga e quem recebe são pessoas diferentes.
Ponto de conformidade: a fatura tem de levar a morada de faturação e o NIF indicado, e a guia de entrega a morada de entrega. Um único campo para as duas produz documentos incorretos assim que diferem, e a fatura sai do programa certificado com dados errados.
O que não deve fazer
Impor um formato de escrita. Um cliente que escreve a morada em maiúsculas ou em minúsculas tem de ser aceite. A normalização faz-se do lado do servidor.
Proibir carateres acentuados. Os nomes de ruas e de localidades têm-nos, e rejeitá-los é um erro de conceção.
Limitar demasiado o comprimento. Há moradas longas, com nome de urbanização, lote, andar e fração.
Pedir o e-mail duas vezes. Esta prática duplica a escrita sem reduzir significativamente os erros, e impede o preenchimento automático.
Medir
Três indicadores.
A taxa de abandono na etapa da morada, separadamente no telemóvel e no computador.
O tempo médio de preenchimento, que desce bastante com o preenchimento automático e a autocompletar.
A taxa de falha de entrega por morada incorreta, que mede a qualidade dos dados recolhidos e tem um custo direto.
O módulo Checkout Simples e Elegante para PrestaShop retoma este formulário no PrestaShop 8 e 9: campos reduzidos ao necessário com revelação condicional dos campos profissionais, preenchimento da localidade pelo código postal, atributos de preenchimento automático corretamente colocados, validação ao longo da escrita e morada de faturação recolhida por omissão.
