Backend Developer , Bot Developer

1. Business context Abraham is a kosher sushi and food business in Buenos Aires, Argentina. Most customer orders arrive through WhatsApp. Today, employees manually answer repetitive questions, send the menu, recommend products, calculate quantities, take delivery details, confirm payment and manually enter orders into the restaurant system. The goal is to build an AI-powered WhatsApp sales assistant that can handle most customer conversations automatically, while allowing a human employee to take over at any moment. This is not a generic customer support chatbot. It must behave like a trained sales employee from Abraham. 2. Main objective The bot must: Answer WhatsApp messages automatically. Understand informal Spanish from Argentina. Show the menu and current prices. Recommend products and combos. Take complete orders. Ask for missing information. Confirm the final order with the customer. Send the order to the restaurant system or human operator. Know when it must stop and transfer the conversation to a human. 3. Main communication channel The first version must work through: WhatsApp Business Platform / WhatsApp Cloud API. Do not build the system using unofficial WhatsApp automation, browser automation or WhatsApp Web scraping. The architecture must be compatible with an official Meta WhatsApp Business account. 4. Language and tone The bot must speak in natural Argentine Spanish. Tone: friendly; informal; commercial; fast; clear; not robotic; not excessively formal. Example: Bad: Estimado cliente, por favor indique el producto que desea adquirir. Good: Dale, ¿qué tenías ganas de pedir? ¿Sushi, ensalada o wok? The bot should understand spelling mistakes and informal expressions. Examples: “quiero 30 piezas” “mandame lo de siempre” “tenes salmon?” “quiero algo para 4” “cuanto sale el combo?” “sin palta” “agregame 3 teri” “para las 20:30” “retiro yo” “mandalo a belgrano” 5. Customer memory The bot should recognize returning customers when possible. It should remember: customer name; phone number; usual delivery address; previous orders; favorite products; allergies or restrictions; usual sauces; whether the customer normally requests delivery or pickup. Examples: If the customer says: Mandame lo de siempre. The bot should check the last confirmed order and reply: La última vez pediste 30 piezas, 2 teriyaki y 2 soja. ¿Repetimos eso? The bot must not invent previous orders when there is no reliable history. 6. Menu management The bot must read menu data from a database or API. Do not hardcode the complete menu inside the AI prompt. Each product must include: product name; category; description; price; quantity or number of pieces; ingredients; availability; optional extras; restrictions; image; active or inactive status. The restaurant administrator must be able to update prices and availability without editing code. 7. Product categories The bot must support at least: sushi combos; individual rolls; salads; woks; appetizers; sauces; drinks; desserts; catering; Shabbat orders; special promotions. 8. Sales recommendations The bot must recommend products based on: number of people; budget; preferences; allergies; previous purchases; raw or cooked salmon preference; vegetarian preference; delivery time. Examples: Customer: Somos 4 y quiero gastar alrededor de 60 mil. Bot: Para 4 te recomiendo el combo de 50 piezas. También puedo agregarte 4 salsas y palitos. ¿Prefieren más salmón o más piezas cocidas? Customer: Quiero algo sin pescado crudo. Bot: Perfecto. Te puedo armar una opción con piezas cocidas, hot rolls y wok. ¿Para cuántas personas sería? The bot must not recommend unavailable products. 9. Order creation flow The bot must collect: customer name; customer phone; products; quantities; modifications; sauces; utensils; delivery or pickup; address; apartment or floor; neighborhood; delivery time; payment method; observations. The bot must confirm the order before submitting it. Example final confirmation: Te confirmo: 1 combo de 30 piezas — $35.000 3 teriyaki 2 soja 4 palitos Envío a Av. Cabildo 2100, piso 4 Entrega: 20:30 Pago: transferencia Total: $35.000 + envío. ¿Confirmás el pedido? The order must only be submitted after the customer clearly confirms. 10. Scheduling orders The bot must support scheduled orders. It must understand: today; tomorrow; Friday; Saturday night; exact dates; exact times. Examples: “para mañana a las 20” “para el viernes antes de shabat” “quiero retirar 12:30” “mandalo el domingo a las 21” It must validate that the requested time is inside business hours and that enough preparation time exists. 11. Shabbat functionality Because Abraham is a kosher business, the bot must support Shabbat-specific orders. It should: allow customers to pre-order; show order deadlines; identify Friday delivery or pickup; prevent scheduling during unavailable hours; offer Shabbat packs when configured. All opening hours and deadlines must be editable by the administrator. 12. Delivery and pickup The bot must ask: ¿Es envío o retiro? For delivery it must collect: complete address; neighborhood; apartment, floor or unit; delivery instructions. The first version may use delivery zones and fixed delivery prices. Future versions may integrate with logistics providers. If an address is outside the delivery area, the bot must transfer the case to a human or explain that delivery requires manual confirmation. 13. Payment The bot must support configurable payment methods: cash; bank transfer; Mercado Pago; payment link; other configured methods. It must not mark an order as paid only because the customer says “I paid”. Payment status should be confirmed through: payment provider webhook; manual employee confirmation; verified transfer receipt in a later phase. 14. Fudo integration The desired integration is with Fudo. The developer must first verify what official APIs or integration options are available. Ideal flow: Customer confirms order. Bot creates or identifies customer. Bot creates the order in Fudo. Bot stores the Fudo order ID. Bot sends confirmation to customer. Human staff can review the order. If direct Fudo integration is not technically available, implement an intermediate order dashboard where employees can approve and manually send the order. Do not fake an integration that does not exist. 15. Human handoff The bot must transfer the chat to a person when: customer explicitly requests a human; complaint or refund; food safety or allergy uncertainty; payment problem; unusual delivery; custom catering; very large order; bot confidence is low; product or price information is missing; abusive or confusing conversation. Example: Te paso con una persona del equipo para resolverlo bien. Ya le dejo el contexto de tu pedido. The human operator must see: conversation summary; customer details; detected order; missing information; reason for transfer. 16. Admin dashboard The system needs a basic admin panel where Abraham staff can: see all chats; take over conversations; pause or activate the bot; update menu; update prices; update availability; edit business hours; review pending orders; approve or reject orders; view customer history; see failed conversations; see analytics. Minimum analytics: conversations received; automated conversations; human handoffs; orders created; conversion rate; average response time; most requested products; abandoned orders. 17. AI architecture Recommended architecture: WhatsApp Cloud API; backend in Node.js or Python; database such as PostgreSQL; OpenAI, Claude or Gemini API; deterministic order state machine; retrieval from menu and business rules; admin dashboard in React or Next.js. Important: The AI must not control the complete order process alone. Use a structured state machine for: customer identification; product selection; delivery details; payment; confirmation; order submission. The language model should interpret messages and generate natural answers, but prices, availability, calculations and final order data must come from structured systems. 18. Data security Requirements: API keys only in backend; secure webhooks; authentication for admin dashboard; audit logs; role-based permissions; encrypted connections; no public exposure of customer conversations; database backups; privacy policy support; deletion or anonymization of customer data when required. 19. MVP scope The first production-ready MVP must include: Official WhatsApp integration. Automatic Spanish responses. Menu and prices from database. Product recommendations. Complete order flow. Delivery or pickup. Scheduled orders. Customer confirmation. Human handoff. Admin conversation dashboard. Customer and order history. Basic analytics. Fudo integration if officially possible. Alternative approval dashboard if Fudo integration is unavailable. Do not include in MVP: voice calls; advanced voice bot; automatic financial refunds; autonomous supplier ordering; complex delivery optimization; multi-restaurant support; custom AI model training. 20. Required deliverables The developer must deliver: complete source code; GitHub repository; installation instructions; environment variables example; database migrations; API documentation; deployment documentation; test WhatsApp number; admin credentials; test cases; error logging; backup instructions; 30 days of bug fixing after delivery. The code and all accounts must belong to Abraham. The developer must not keep exclusive access to hosting, Meta, database or API accounts. 21. Milestones Milestone 1 — Architecture and prototype WhatsApp webhook working; incoming and outgoing test messages; database schema; basic admin login. Milestone 2 — Menu and order flow product database; menu responses; cart; delivery or pickup; final confirmation. Milestone 3 — AI understanding Argentine Spanish; spelling mistakes; recommendations; returning customer context; safe fallback. Milestone 4 — Dashboard and handoff conversations; human takeover; pending orders; customer history. Milestone 5 — Integration and launch Fudo or approval dashboard; deployment; testing; documentation; production launch. Payment must be released by milestone only after testing. 22. Acceptance tests The project is not complete unless it can successfully handle these conversations: Test 1 Customer: Hola quiero 30 piezas para hoy 20:30. The bot must ask for missing information and create a complete order. Test 2 Customer: Somos cinco, qué me recomendás? The bot must recommend a suitable quantity and ask preferences. Test 3 Customer: Mandame lo de siempre. The bot must check actual history and ask for confirmation. Test 4 Customer: Sin palta y agregame cuatro teri. The modifications must appear correctly in the final order. Test 5 Customer: Quiero hablar con alguien. The conversation must immediately transfer to a human. Test 6 Customer requests an unavailable product. The bot must not sell it. Test 7 Customer changes address or time after the order summary. The bot must update the order and reconfirm. Test 8 The AI service fails. The system must show a controlled fallback and alert an employee. 23. Questions the developer must answer before hiring Please answer: Have you built an official WhatsApp Cloud API bot? Can you show a working example? How will you prevent the AI from inventing prices? How will human takeover work? How will you manage conversation state? Have you integrated restaurant or POS systems? How will the system behave if Fudo has no usable API? What hosting architecture do you recommend? What are the expected monthly costs? How many weeks do you need for the MVP? What parts will not be included in the proposed price? Will the full source code and accounts belong to me?