Guia rápido: especifique o fluxo completo de pedidos
A compra de um terminal para restaurantes exige uma configuração de hardware acordada e uma conexão testada com o fluxo de pedidos. A tela sensível ao toque, sozinha, não é o sistema completo.
- Identifique o aplicativo: Confirme o sistema operacional, a versão e o hardware compatível.
- Confirme o pagamento no mercado local: Verifique se o terminal, o provedor e o aplicativo atendem ao país de instalação.
- Confira o recibo: Teste o manuseio do papel, os números dos pedidos e a retomada após o fim da bobina.
- Aprove uma amostra funcional: Teste a jornada do cliente e os procedimentos de recuperação da equipe antes de uma compra maior.
Um terminal de autoatendimento para pedidos deve ser especificado a partir do processo real do restaurante. O cliente precisa escolher um item, revisar as opções, concluir o pagamento exigido e entender o próximo passo. Por trás dessa jornada simples, há decisões separadas sobre hardware, software, serviços de pagamento e envio do pedido à cozinha.
Este artigo trata da preparação dessas decisões antes da compra do terminal. Não estima um preço universal nem presume compatibilidade com um sistema de ponto de venda (PDV) específico. O objetivo é ajudar o comprador a transformar uma consulta genérica em uma configuração que o fornecedor de hardware e os provedores de software possam verificar juntos.
Comece pelo software já usado no restaurante
Registre o aplicativo de pedidos, a plataforma de PDV e o sistema da cozinha em uso, incluindo suas versões. Identifique o fornecedor responsável por cada conexão. Se o software ainda não foi escolhido, registre essa decisão em aberto, em vez de pedir que uma proposta de hardware inclua um serviço completo de pedidos sem definição.
Solicite ao fornecedor do aplicativo os sistemas operacionais aceitos e os requisitos dos dispositivos. Inclua a forma de conexão com a entrada por toque, as impressoras e o hardware de pagamento. Saber que um aplicativo roda em Android ou Windows é útil, mas isso não confirma todas as versões, drivers, periféricos ou formas de instalação.
Diferencie uma integração já suportada de um projeto de desenvolvimento proposto. Uma conexão suportada deve ter instruções de configuração definidas e uma equipe responsável pelo suporte. Uma nova integração precisa de escopo, testes e plano de entrega. Nenhuma das duas pode ser presumida apenas porque dois sistemas têm conexão de rede ou aparecem na mesma lista de equipamentos.
Registre o que acontece depois do envio de um pedido. Ele chega ao PDV, a uma tela da cozinha, a uma impressora ou a uma fila separada? Quem mantém as alterações do cardápio e a disponibilidade? Essas respostas influenciam o teste da amostra e evitam atribuir ao fornecedor de hardware a responsabilidade por um processo controlado por outro aplicativo.
Adapte a configuração YJCEN ao projeto
O terminal de autoatendimento para pedidos YJCEN oferece telas de toque capacitivo de 21,5, 27 e 32 polegadas, instalação na parede ou no piso e uma impressora térmica de recibos de 80 mm integrada. Há configurações de pagamento por QR code e NFC, além de câmera HD opcional quando exigida pelo projeto.
Esses pontos descrevem configurações de hardware. O aplicativo de pedidos, o processamento de pagamentos, as licenças de software e os serviços de integração são definidos separadamente. Escolher uma configuração de pagamento listada não torna um serviço de pagamento automaticamente disponível em todos os países. O provedor e o aplicativo precisam atender ao terminal e ao mercado escolhidos.
Ao comparar propostas, use o desenho atual do produto e a lista de componentes acordada. Identifique o tamanho da tela, a montagem e os periféricos incluídos em cada orçamento. Peça que os itens opcionais sejam indicados separadamente, para não confundir um total menor com a mesma configuração quando faltam componentes essenciais.
Se o projeto exigir componentes removíveis ou outra disposição, compare o terminal de autoatendimento modular. A diferença relevante é a organização dos componentes. Não presuma que módulos de um projeto possam ser usados em outro sem verificar encaixe físico, interfaces e suporte de software.
Escolha a tela com o cardápio real
Uma tela maior não torna automaticamente a interface de pedidos melhor. Teste um cardápio representativo no tamanho de tela pretendido. Inclua um item simples, uma refeição com opções, um item indisponível e o carrinho final. Avalie os controles que o cliente mais usará, não apenas a tela de boas-vindas.
Verifique se nomes, preços e estados de seleção continuam legíveis. Confirme se nomes longos e cardápios traduzidos não deslocam botões importantes para fora da área visível. A tela pode exibir escolhas detalhadas, mas o aplicativo precisa organizá-las com clareza. Uma área maior não compensa uma sequência de perguntas confusa.
Peça a alguém que não conheça o cardápio para fazer um pedido de teste sem orientação. Observe onde a pessoa hesita, repete um toque ou perde a referência do carrinho. Essas observações ajudam a equipe de software a melhorar a interface. Elas não comprovam um aumento garantido no valor do pedido, nem uma redução garantida na espera ou um crescimento das vendas.
Teste também o acesso da equipe ao aplicativo. A tela pública de pedidos e o menu administrativo têm funções diferentes. O fornecedor do software deve definir como os funcionários atualizam a disponibilidade ou recolocam o terminal em operação. Evite depender de uma sequência não documentada que só o instalador conhece.
Confirme o hardware de pagamento junto com o provedor
Liste as formas de pagamento exigidas e o país de instalação. Peça ao provedor de pagamento que confirme o modelo exato do terminal, a integração suportada e as condições de contratação e ativação. Um símbolo de aproximação ou um leitor de QR code no hardware não comprova que o serviço desejado esteja ativado ou seja compatível.
Esclareça qual dispositivo coleta as credenciais de pagamento e qual aplicativo recebe o resultado. O terminal de pedidos precisa de uma indicação confiável de que a transação foi concluída, falhou ou permanece sem confirmação. O fechamento da janela de pagamento não comprova que o restaurante recebeu um pagamento confirmado.
A documentação dos provedores mostra por que essa integração precisa ser tratada separadamente. Por exemplo, a Terminal API da Square descreve uma conexão específica desse provedor entre um aplicativo e um terminal de pagamento. É um exemplo de interface de pagamento definida, não uma afirmação de que a Square esteja incluída no terminal YJCEN ou certificada para ele.
Use o procedimento de teste aprovado pelo provedor para cancelamentos, expiração do tempo de resposta e transações interrompidas. Defina quem verifica um resultado incerto antes de o cliente repetir o pagamento. O comportamento de recuperação depende da configuração de pagamento e pedidos acordada e deve ser documentado com a equipe de software.
Especifique o conteúdo do recibo
A impressora térmica imprime o conteúdo enviado pelo aplicativo. Prepare um recibo de exemplo com a referência do pedido, os itens comprados e as instruções de retirada. Confirme exigências comerciais ou fiscais locais com o profissional competente e o fornecedor de software; a presença de uma impressora, por si só, não comprova conformidade.
A especificação de uma impressora de 80 mm descreve uma classe de largura de papel, não todo o layout impresso. Confirme com o fornecedor as dimensões da bobina, a forma de colocação e a área imprimível. Teste nomes longos e um pedido representativo de maior tamanho. Um layout adequado a um pedido curto pode ter quebras de linha diferentes no uso normal.
Posicione o terminal de modo que a equipe consiga trocar o papel e resolver um atolamento permitido pelas instruções sem mover toda a estação para a passagem dos clientes. Confirme quais tampas de acesso ou chaves são necessárias. Mantenha as bobinas e as instruções de manutenção de rotina acessíveis à equipe, restringindo o acesso técnico conforme as exigências da instalação.
Inclua um teste de falta de papel na aprovação da amostra. Verifique o que aparece para o cliente e como a equipe identifica o status do pedido. A ausência de recibo não deve deixar todos sem saber se o pedido chegou à cozinha. O aplicativo precisa definir uma resposta adequada, sem depender apenas da saída física do papel.
Compare a instalação na parede com a instalação no piso
Uma unidade de parede pode economizar espaço no piso quando há uma parede adequada e acesso para manutenção. Uma unidade de piso cria uma estação de pedidos própria. Compare toda a área ocupada, incluindo quem usa o terminal, os clientes na fila e os funcionários que abrem o compartimento de manutenção.
Use o desenho do modelo escolhido para conferir dimensões e requisitos de fixação. Não escolha o suporte apenas pelo tamanho da tela. Peça à equipe do local que confirme a estrutura de apoio, a alimentação elétrica e o caminho dos cabos. O método final de instalação deve ser adequado ao equipamento real e às condições do restaurante.
Avalie o alcance da tela de toque, do dispositivo de pagamento e da saída de recibos como uma única interação. O cliente não deve precisar mudar de posição de forma inesperada entre etapas. As exigências de acessibilidade aplicáveis precisam de análise específica do projeto; uma tela grande ou uma montagem baixa, isoladamente, não comprova a acessibilidade da estação completa.
Percorra o trajeto da entrada até o pedido, a espera e a retirada. Mantenha filas afastadas das saídas e dos acessos de manutenção. Marque temporariamente a posição proposta antes da instalação definitiva para que a equipe identifique conflitos durante um período realista de atendimento. Essa verificação de layout não substitui as aprovações profissionais exigidas para o local.
Defina a sequência de aceitação da amostra
Comece com um pedido normal: selecione itens, altere uma opção, revise o carrinho, faça o teste de pagamento acordado e confirme o pedido no destino. Compare o recibo com o registro da cozinha ou do PDV. Registre as versões reais de software e hardware utilizadas, para que a combinação aprovada possa ser reproduzida.
Depois, teste correções antes do pagamento. Remova um item, volte de uma página de seleção e cancele um carrinho incompleto. Confirme se o próximo cliente inicia uma sessão limpa. Esses comportamentos pertencem ao aplicativo, mas a amostra física permite verificá-los com a tela e os periféricos previstos.
Acrescente os testes de recuperação acordados com os fornecedores: perda temporária da rede, bobina vazia, pagamento cancelado e reinicialização normal. Defina o resultado esperado antes de cada teste. Caso contrário, um resultado pode ser chamado de sucesso apenas porque a tela voltou a funcionar, embora o status do pedido continue incerto.
Mantenha uma lista de testes curta o suficiente para ser repetida após uma atualização de software, mas específica o suficiente para revelar uma conexão com falha. Salve o resultado, o nome de quem verificou e as pendências. Uma amostra com falhas de pagamento ou de envio do pedido não deve ser registrada como totalmente aceita apenas porque a tela responde ao toque.
Deixe as responsabilidades claras no orçamento
Separe terminal físico, montagem, impressora, hardware de pagamento, sistema operacional e acessórios acordados. Depois, liste licenças de software, serviços de pagamento, integração, instalação e suporte contínuo como itens de escopo próprios. Isso torna as omissões visíveis sem apresentar custos de software como parte de um preço exclusivo de hardware.
Pergunte quem atende cada tipo de problema. Um gabinete danificado, um aplicativo que trava, um pagamento recusado e um preço incorreto podem exigir equipes diferentes. Dê ao restaurante um contato inicial claro e um caminho de encaminhamento. O resultado útil é um processo de suporte funcional, não uma promessa sem fundamento de que um fornecedor controla todas as partes.
Combine como as alterações serão aprovadas após a aceitação da amostra. Trocar a impressora, a versão do sistema operacional ou o terminal de pagamento pode exigir outro teste direcionado. Um componente aparentemente equivalente no orçamento ainda pode usar drivers ou interfaces diferentes. Registre a lista de materiais aprovada e as versões de software nos documentos de compra.
Em um pedido para vários locais, diferencie a configuração comum dos itens específicos de cada unidade. País, alimentação elétrica, conectividade e pagamento podem variar. Use uma especificação principal com exceções claramente identificadas, em vez de descobrir diferenças locais somente após a entrega. Confirme quais exceções exigem uma amostra ou verificação de instalação separada.
Envie uma especificação que possa ser avaliada
Uma consulta útil inclui tamanho de tela, formato de instalação, quantidade, país e fotos ou desenhos do local. Acrescente nomes e versões dos aplicativos de pedidos e PDV, requisitos do sistema operacional, provedor de pagamento escolhido e recibo de exemplo. Identifique as decisões pendentes para que o hardware proposto seja avaliado com base nas informações disponíveis.
Inclua a rotina diária prevista: abertura, atualização do cardápio, troca de papel, assistência ao cliente e fechamento. Isso ajuda a equipe a discutir acesso e operação, não apenas a aparência frontal. Mantenha projeções e metas comerciais separadas dos requisitos de hardware verificados; são premissas do negócio, não especificações do produto.
Quando essas informações estiverem prontas, envie a especificação da configuração à YJCEN para uma avaliação de hardware. O passo seguinte é combinar uma amostra e o procedimento de aceitação com os fornecedores de software e pagamento envolvidos. Isso permite uma decisão de compra mais clara do que escolher um terminal apenas pelo tamanho da tela ou por um preço anunciado incompleto.
