Está a passar o terminal numa mesa e, do outro lado da sala, outra já pediu a conta. A ideia de o cliente ler um código e pagar sozinho costuma aparecer neste ponto do serviço.
Vale a pena começar pelo que o código tem lá dentro. Um código impresso na mesa não guarda dinheiro. Não guarda dados de cartão nem o total da conta. Guarda um endereço. Tudo o que transforma uma leitura em pagamento acontece depois de o telemóvel chegar a esse endereço.
Daí saem quase todas as respostas práticas: se é preciso reimprimir autocolantes quando os preços mudam, o que o cliente vê quando falta configurar um passo, como é que um autocolante pode ser trocado. Percorremos o nosso próprio lado do cliente de ponta a ponta. Em quatro dos estados em que aterrámos, o endereço abriu bem e não deu pagamento nenhum.
O Que o Código da Mesa Guarda Mesmo
Um código QR é texto impresso que uma câmara consegue ler. Numa mesa de restaurante esse texto é quase sempre um endereço web. O endereço identifica o espaço e a mesa.
Os nossos resolvem-se numa cadeia que qualquer pessoa pode seguir, lendo um código seu. Um link curto fndn.mn com o id do espaço reencaminha para o endereço do menu. Esse endereço traz o nome curto do espaço e abre um ecrã de boas-vindas. Depois vem um id de menu. Quando o cliente toca num prato, entra um id de artigo. É o endereço da aplicação de menu, que corre à parte e não é uma página do nosso site. Preço não aparece em parte nenhuma dessa cadeia. O valor nasce do pedido que o cliente monta depois de chegar. Fica registado do lado do restaurante.
Há dois tipos de código e a restauração usa os dois. O estático imprime-se uma vez e nunca muda. É sempre o mesmo endereço, com conteúdo diferente por trás. O dinâmico é gerado para uma única transação e mostrado num ecrã. Esse pode levar um valor, precisamente porque só existe para aquela conta.
O autocolante da mesa é estático. Pode alterar todos os preços do menu sem tocar no impresso, porque o impresso nunca guardou preços. Em troca, não lhe consegue pôr prazo de validade.
Três Fluxos, e Qual Deles Serve uma Sala
Três montagens diferentes recebem o nome de pagamento por QR. Cada uma põe o trabalho em mãos diferentes.
Na primeira, o estabelecimento mostra o código e o cliente lê-o. É o caso da sala. Um autocolante ou um cartão impresso em cima da mesa, e o pagamento a fazer-se no telemóvel do próprio cliente.
Na segunda, é o cliente que mostra o código. A aplicação do banco ou da carteira digital apresenta-o. Aqui o código leva credenciais de cartão em vez de um endereço. A equipa lê-o na caixa, depois de introduzir o valor. Poder aceitá-lo ou não depende das carteiras que o fornecedor de pagamento suporta.
A terceira é de aplicação para aplicação. Os dois lados abrem as respetivas aplicações e uma lê a outra. Quem paga confirma o valor no ecrã. É o mesmo formato da segunda, com um telemóvel a ler em vez de uma caixa.
Só a primeira poupa uma travessia da sala. Costuma ser essa a razão pela qual um operador faz esta pergunta. Nas outras duas, continua a ser preciso alguém de pé junto à mesa com um aparelho na mão.
O Que Acontece Entre a Leitura e o Dinheiro
O telemóvel abre o endereço no navegador. A partir daí o cliente chega ao menu, monta um pedido ou abre o que já está a correr na mesa, e acaba num ecrã de pagamento. É nesse ecrã que o pagamento se faz, com os dados do cartão introduzidos à mão ou com uma carteira já configurada no telemóvel.
O dinheiro não passa pelo menu. Corre pela conta que o restaurante tem junto de um fornecedor de pagamento. É o fornecedor que fixa a comissão por transação, o dia em que o dinheiro entra no banco e a forma como se trata uma devolução ou uma contestação. Se está a comparar o pagamento por QR com o terminal de cartão que usa hoje, a comparação joga-se aí. A leitura do código é igual nos dois casos. Se o mesmo pedido e pagamento também serve para levar ou entregar, há sete factos-chave sobre takeaway e entrega que ajudam a responder às novas exigências dos clientes. Para situar esta escolha entre outras apostas tecnológicas da sala, há cinco tendências que podem trazer mais lucro aos restaurantes em 2021. Se o restaurante também faz entregas, os 5 benefícios da entrega interna mostram como ganhar controlo sobre encomendas, clientes e custos sem depender de plataformas de terceiros.
Há uma consequência que convém decidir antes de imprimir seja o que for. O pedido e o pagamento são dois registos. Só ficam ligados a uma mesa porque o código disse qual era a mesa. Isso decide-se no momento em que os códigos são gerados, e não se corrige depois.
Quatro Maneiras de a Leitura Não Dar Nada
Todas as falhas que apanhámos no nosso próprio lado do cliente eram estados de configuração, não falhas de pagamento. As quatro veem-se antes do serviço, se ler os seus próprios códigos.
O menu ainda está em rascunho. O endereço abre, o ecrã de boas-vindas carrega e o cliente lê uma linha a dizer que o menu está a ser preparado. Não há nada partido nem nada para pedir.
O código está em modo de exibição. Um código FineDine pode ser configurado para mostrar o menu e mais nada. Com os pedidos desligados, o lado do cliente apresenta secções, detalhe de artigo, ícones de alergénios e avaliações. Carrinho não aparece em parte nenhuma da página. Quem leu o código para pagar fica sem nada com que pagar.
Um só código para a sala inteira. O código de sala pode ser único por mesa ou partilhado por todas. Com um código partilhado, o pedido chega sem mesa associada. Alguém continua a ter de ir perguntar quem pediu o robalo.
O telemóvel não aguenta a ligação. O menu do lado do cliente é montado no navegador depois de a página carregar. Uma mesa numa zona sem rede fica à frente de um ecrã em branco enquanto o sinal não chega. Esta é a única que não se resolve no painel.
As Duas Desvantagens Que Vale a Pena Planear
A primeira é física e os guias costumam saltá-la. Um autocolante numa mesa pode receber outro autocolante por cima. A olho, o cliente não distingue um do outro, porque ambos são quadrados pretos sobre branco. O substituto manda a leitura para outro sítio. O primeiro a descobrir é um cliente que já introduziu os dados do cartão numa página que julgava ser sua.
Nada dentro do código impede isto. Um código estático não tem validade nem assinatura que uma câmara possa verificar. O que funciona é saber para onde é que os seus códigos devem abrir e confirmá-lo. Leia um código descarregado do painel, guarde o endereço que aparece na barra do navegador e compare-o com o que abre a partir da mesa. Um código na mesa que abra outra coisa não é o seu código. Faça essa passagem à abertura, quando prepara as mesas. Um código mostrado no ecrã de um terminal não corre este risco, porque não fica nada na mesa entre serviços.
A segunda desvantagem não envolve nenhum atacante. Há clientes que não leem o código. Há quem não traga um telemóvel com que possa pagar. Não medimos quantos são, e um número tirado de outra sala não diz nada sobre a sua. O que daí resulta é que o código na mesa é um caminho a mais e não um substituto. A caixa continua a receber cartão e dinheiro para o resto da sala, e o padrão de serviço tem de cobrir as duas metades.
Que Fornecedor Ligar, e Quem Fica com o Dinheiro
Um pagamento por QR chega ao banco através de um fornecedor com quem o restaurante tem conta. Os fornecedores disponíveis dependem do país onde trabalha. O Marketplace da FineDine lista dez para ligar: Stripe, Iyzipay, Square, SumUp, STC Pay, Pay2M, Myfatoorah, PayZee, MOKA e NoonPayments. A mistura é regional, por isso vários deles não serão opção na sua morada.
Do lado do cliente, o Fast Checkout corre sobre Stripe e Myfatoorah. O ecrã de pagamento aceita cartão, Apple Pay e Google Pay. As gorjetas e a divisão da conta ficam nesse mesmo ecrã. O cliente tem à frente uma página web e não uma aplicação nossa. É por isso que não há nada para instalar no telemóvel dele.
Os custos ficam em dois sítios e nenhum deles é o código. Há a parte do fornecedor por transação, fixada pelo fornecedor. Há a subscrição do menu e dos pedidos que vivem por trás do código. O que cada plano inclui vai mudando ao longo do tempo, por isso confirme na página de preços do site em vez de num valor escrito num artigo. Se também trabalha com entregas e recolha, isso corre como canal de pedidos próprio, com links e definições próprias: taxa de entrega, valor mínimo, tempo de preparação. O nosso guia de encomendas online trata dessas decisões.
O Que Muda num Serviço, e o Que Não Muda
Depois de estar a funcionar, isto é o que muda. As mesas que optam por ler o código fecham-se sozinhas enquanto está do outro lado da sala. A caminhada com o terminal passa a acontecer para menos mesas. Os códigos geram-se em Settings > QR Codes, onde escolhe entre display, ordering e tablet. Os códigos por mesa descarregam-se em Settings > Operations, no separador Tables. Se serve álcool, a verificação de idade é uma definição dos pedidos e não do código, e não substitui a verificação que a equipa é obrigada a fazer à mesa.
Do outro lado, alguém continua a acompanhar os pedidos à medida que entram. A escolha entre código partilhado e código por mesa continua a fazer-se antes de se imprimir seja o que for. E há sempre clientes que querem entregar um cartão em mão. Não medimos que percentagem de uma sala escolhe o código em vez do terminal, por isso conte o número da sua sala ao longo de dois ou três serviços.
Se ainda está antes disto e a decidir se o canal sequer faz sentido no seu serviço, o nosso guia sobre o que é o pagamento por QR e onde encaixa trata dessa parte. O que muda para o cliente depois da leitura cobre o outro lado da mesa.
| Fluxo | Quem mostra o código | O que o código leva | De onde vem o valor |
|---|---|---|---|
| Código estático de mesa | O restaurante, impresso na mesa | Um endereço web que identifica o espaço e a mesa | Do pedido que o cliente monta no telemóvel |
| Código dinâmico de pagamento | O restaurante, num terminal ou ecrã de POS | Uma transação específica | Da conta para a qual o código foi gerado |
| Código da carteira do cliente | O cliente, na aplicação do banco ou da carteira | Credenciais de cartão emitidas pelo banco ou pela carteira | Introduzido na caixa pela equipa antes da leitura |
Perguntas frequentes
- Os clientes precisam de instalar uma aplicação para pagar por código QR?
- Neste fluxo, não. As câmaras dos iPhone e Android recentes leem códigos sem software adicional. O código abre uma página web, e o pagamento faz-se nessa página com cartão ou com uma carteira já configurada no telemóvel. As montagens que exigem aplicação são as outras, aquelas em que é o cliente a mostrar o código. Aí a aplicação é a do banco dele, não algo que o restaurante distribua.
- É preciso reimprimir os códigos quando os preços mudam?
- Não. O impresso guarda um endereço e os preços vivem atrás desse endereço. Uma alteração de preço já está ativa na leitura seguinte, sem nada para reimprimir. Reimprime-se quando muda o próprio código: ao passar de um código partilhado para um código único por mesa, ou ao acrescentar mesas.
- A câmara de um cliente não lê o código. E agora?
- O link curto também pode ser escrito à mão, por isso o cliente chega ao menu sem ler nada. Se falha um telemóvel, o problema é daquele telemóvel. Se falha um lote inteiro de mesas, desconfie da impressão e volte a descarregar os códigos no painel.
- Um cliente pode pagar só uma parte da conta?
- O Fast Checkout suporta pagamento dividido, sobre Stripe ou Myfatoorah, e as gorjetas ficam no mesmo ecrã. O que não resolve é quem paga o quê. Isso continua a acordar-se à mesa, e um grupo de oito a dividir por oito demora mais do que uma pessoa a pagar tudo.
- O mesmo código serve para um menu em tablet?
- O tablet é um modo próprio, não o mesmo código noutro aparelho. Escolhe-se ao lado de display e ordering, quando configura os códigos. Traz também os seus próprios modos de pedido: tablet na mão do empregado, tablet fixo à mesa, quiosque de autosserviço. Decida qual deles vai usar antes de configurar.
