Skip to content
</>
Back
AI-powered WhatsApp supportProduction

Professional project

Ley REP Assistant (formerly Orbix)

  • Laravel
  • MySQL
  • WhatsApp Cloud API
  • DeepSeek
  • Vercel AI Gateway
  • Odoo

Problem

Questions about Chile's EPR law (Ley REP) arrive over WhatsApp and repeat themselves: which products are priority products, who must report, how to comply. Answering them one by one eats team time, and the cases that do need a person get lost among the rest.

Context

A professional project at GreenSoft, in production at leyrep.cl. It is the Ley REP virtual assistant; Orbix was its former name. It is backend only: there is no UI of its own, everything the user sees happens in WhatsApp. It is independent from Dixta.

Objective

Give guidance on Ley REP with answers grounded in documents, and hand concrete cases to the sales team with the data needed to continue the conversation.

My role

  • Planned the solution, defined the technical design and built the backend.
  • Implemented the WhatsApp Cloud API webhook with Meta signature validation, plus the guided flows with buttons, lists and numbered options.
  • Built the AI answers for open questions: search over the indexed documents and generation with DeepSeek through Vercel AI Gateway.
  • Integrated lead registration in the CRM (Odoo) when a conversation is handed to an agent.

Architecture & decisions

  • Laravel 13 on PHP 8 and MySQL; it is backend only, with no frontend. The suite has close to 1,280 Pest tests and runs against MySQL.
  • The webhook only validates and enqueues: Meta signature, per-phone rate limit and message extraction. The answer is built in a job, because Meta retries when the webhook is slow.
  • Every message goes through a decision cascade: guided flows and an intent tree first; the model only answers open questions.
  • Document search is lexical, with no embeddings or vector database: a local SQLite (FTS5) index over 116 regulatory documents.
  • The model is DeepSeek through Vercel AI Gateway, via an OpenAI-compatible API. It previously ran on a self-hosted llama.cpp server.
  • Leads are sent to Odoo and a job retries failed deliveries. Bitrix24 was retired.

Architecture flow

  1. 01WhatsApp
  2. 02Webhook: validate & enqueue
  3. 03Guided flow or AI + documents
  4. 04Handoff + Odoo

Solution

  • Interactive main menu and a priority-products submenu, with guided answers for frequent questions.
  • AI answers for open questions, grounded in the fragments of regulatory documents that search retrieves.
  • In-chat capture forms and handoff to an agent, with the lead registered in Odoo.
  • Data deletion on request from the chat itself: the conversation is anonymized instead of deleting the rows.
  • Reference case sets and commands to evaluate retrieval, routing and answers before changing a parameter or a model.

Challenges & trade-offs

  • In a regulatory topic the risk is not that the model writes badly but that it answers well to someone who did not ask; that is why answers rely on documents, not on what the model remembers.
  • Avoiding duplicate messages when the model is slow: the webhook enqueues, a per-phone lock orders the turns and an incoming-messages table provides idempotency.
  • Choosing lexical over vector search and tuning its parameters by measuring against reference cases, not by eye.
  • Switching model providers without rewriting the system, by keeping an OpenAI-compatible interface.

Learnings

  • Measure before changing: with a set of reference cases, an improvement stops being an impression.
  • AI helps with interpreting open questions; flows that capture data or hand off to a person need explicit steps.
  • Designing a conversation demands the same care for hierarchy and error recovery as a visual interface.

Result

In production at leyrep.cl: it answers Ley REP questions over WhatsApp and hands commercial cases to the CRM. Internal documents, credentials and operational details are omitted.