Um restaurante presente em três plataformas de entrega acaba normalmente com três tablets numa prateleira, cada um com o seu som, cada um a exigir que alguém aceite a encomenda e a leia num ecrã. Funciona até duas delas tocarem ao mesmo tempo em pleno serviço.
Resposta curta: ponha um agregador entre as plataformas e a cozinha, e depois envie uma chamada de impressão por encomenda. As plataformas mantêm as suas apps para estados e apoio, mas o talão que chega à cozinha tem um único formato, um único som e nenhum ecrã para vigiar.
Onde os tablets doem mesmo
| Problema | Porque acontece | O que muda |
|---|---|---|
| Três formatos de talão diferentes | Cada app compõe o seu | Um modelo único que você controla |
| Encomendas falhadas na hora de ponta | Dois tablets tocam ao mesmo tempo, um é ignorado | O talão é físico e não precisa de confirmação |
| Voltar a escrever no POS | O tablet é uma ilha à parte | O agregador encaminha a encomenda adiante |
| Nenhum rasto do que chegou | O histórico vive em três apps | Um histórico de impressão, uma referência de encomenda |
O padrão por trás dos quatro é o mesmo: um tablet é um ecrã para uma pessoa, e uma cozinha na hora de ponta não tem pessoas a mais.
A arquitetura
Três peças, e só a do meio é uma decisão:
- As plataformas. Uber Eats, Glovo, Bolt Food e as restantes expõem as encomendas através da respetiva integração de parceiro.
- Um agregador. O HubRise e equivalentes normalizam esses fluxos num único formato de encomenda, que é o que torna possível um modelo de talão único. É esta a peça que poupa o trabalho.
- Uma chamada de impressão. Um POST por encomenda para uma impressora acessível pela internet. Sem software local, sem tablets.
Se as suas plataformas já estão unificadas num POS, o passo do agregador pode ser dispensável e a chamada de impressão pode ficar pendurada no POS. A pergunta é simplesmente onde as encomendas já se encontram, e ligar aí a impressão em vez de construir uma quarta ilha.
Para plataformas que só expõem um webhook, uma ferramenta de automação como o Zapier faz a ponte sem código, ao preço de alguns segundos de latência.
O que o talão precisa e uma encomenda web não
Os talões de entrega trazem informação que uma encomenda de loja nunca tem, e deixá-la de fora é o que provoca os telefonemas:
- O nome da plataforma e a referência de encomenda da própria plataforma, impressos em grande. Quando um estafeta chega a pedir a encomenda 4471, ninguém quer procurar em três apps.
- Entrega ou recolha, no topo. Muda a embalagem.
- A hora pedida, não apenas a hora da encomenda. Uma pré-encomenda para as 20:30 que entra às 19:00 não deve ser preparada de imediato, e este é o erro mais comum ao abandonar os tablets.
- As variantes numa linha indentada própria, porque quem lê à pressa toma uma variante colada por mais um artigo.
- A nota do cliente, por inteiro, em baixo.
O resto da paginação segue as mesmas regras de qualquer talão de cozinha, e a marcação está na referência de paginação.
Tratar as falhas próprias da entrega
Cancelamentos depois de imprimir. Uma plataforma pode cancelar uma encomenda que já está no passe. Imprimir um talão de cancelamento na mesma impressora vale a pena: é mais barulhento do que uma notificação que ninguém vê.
Alterações. Algumas plataformas deixam o cliente mudar a encomenda antes da preparação. Imprima a alteração como um talão novo que referencia o original, em vez de reimprimir a encomenda inteira, para que a cozinha não a prepare duas vezes.
Duplicados por repetições. Os webhooks de agregador repetem. Ponha a referência de encomenda da plataforma em origin para que uma repetição seja detetável no histórico em vez de reimpressa. O guia de fiabilidade descreve o padrão.
As pré-encomendas. Decida se o talão sai na receção ou à hora de preparação. Sair na receção é mais simples e serve para volumes pequenos; agendar a impressão com uma antecedência sobre a janela pedida é melhor assim que as pré-encomendas se tornam frequentes, e nos dois casos a hora pedida tem de constar do talão.
O que continua a precisar de ecrã
Imprimir não substitui por completo as apps das plataformas. Marcar uma encomenda como pronta, falar com um estafeta e tratar reembolsos ficam na app, e o tablet pode sair do passe para o escritório. O objetivo não é zero ecrãs; é que nenhum ecrã fique entre uma encomenda que chega e a cozinha.
Imprima um talão de entrega de teste no plano gratuito com um payload realista, incluindo hora de pré-encomenda e uma nota de cliente de duas linhas, antes de ligar o agregador. Os defeitos de paginação custam muito menos se forem encontrados numa terça à tarde.
FAQ
Posso imprimir as encomendas das plataformas sem um tablet por app?
Sim. Um agregador normaliza as plataformas num único fluxo de encomendas, e uma só chamada de impressão envia o talão para a cozinha. As apps ficam para estados e apoio, mas já nada tem de ser lido num ecrã para que a encomenda seja feita.
O que deve um talão de entrega mostrar que uma encomenda de loja não mostra?
O nome da plataforma e a sua própria referência de encomenda em grande, entrega ou recolha no topo, a hora pedida e não apenas a da encomenda, as variantes numa linha indentada própria, e a nota do cliente por inteiro.
O que acontece se uma plataforma cancelar depois de o talão ser impresso?
Imprima um talão de cancelamento na mesma impressora. É mais barulhento do que uma notificação que ninguém vê, e aparece onde apareceu o talão original, que é o único sítio para onde a cozinha olha mesmo.
Como evito que as pré-encomendas sejam preparadas de imediato?
Ponha a hora pedida no talão, não apenas a hora da encomenda, e decida se imprime na receção ou se agenda a impressão com antecedência sobre a janela. Imprimir na receção sem a hora pedida é o erro mais comum.
Porque é que a mesma encomenda de entrega às vezes imprime duas vezes?
Os webhooks de agregador repetem quando o seu endpoint responde devagar. Ponha a referência de encomenda da plataforma no campo origin para que uma repetição seja detetável no histórico em vez de reimpressa em silêncio.