From a WhatsApp chat to a tracked operation

One idea: the operation lives in a database, not in a chat

Today the website is a calculator that ends in WhatsApp. Everything after that (data, proof of payment, verification, bookkeeping) happens in chat and by hand. The whiteboard moves that work into a structured flow; Kambista shows how a client-facing version of it can feel.

How a client is attended now

brasper.com/es promises “Envía dinero a Perú y Brasil por WhatsApp, seguro y en minutos”. The flow below is what the site and its code do. The back office behind it (sales and billing teams, KeyFácil and Omni) comes from the team’s diagnosis notes, because the whiteboard photo I have is cropped at the top.

What gets in the way

What Kambista’s flow gives us to reuse

Walked end to end on a real device (Samsung, app v2.0.218). Kambista does everything in-app: calculate, fill data, transfer, report proof, track, get receipts. Each pattern below maps to a piece of the whiteboard.

The whiteboard flow, redrawn

Everything below the red line on the board, drawn with its actors: who does each step and in which system. Three rules shape it. Payment validation stays with a person who works in the VIEW. The Dashboard is the existing system and is not modified: it only imports and exports orders. And AI appears only where similar remittance and exchange businesses already use it, as optional pieces.

The original

What the board says

• Web App reads the exchange rate (“tipo cambio”) and collects Origen de fondo ✓, C. Origen, N° Trans, C. Destino.
• Fotos go from the Web App into the BD, labelled IV (read by the team as Intención de Venta).
• Bank with a person and 15 min: a person checks the bank and “ok? Aprob” goes back to the BD, through the VIEW where they change the order status (confirmed by you).
• The VIEW over the BD; a person marks to export.
• Export → the Dashboard, which already exists, is not modified and only imports and exports orders (confirmed by you).
• I/EXP → SCRIPT “Fact”: a person exports the orders from the Dashboard and imports them into Fact (confirmed by you). Fact has its own database and an API key (underlined and flagged with “!!”); it runs the set of orders, registers the sales through KeyFácil / Omni, and the flow ends with the receipt.
• Bottom left: WSP, Telegram, Discord o IA. In my drawing this is the optional chat agent A1 (Discord is not drawn: I found no use of it by similar businesses).

What the client would see

Five screens modelled on Kambista’s wizard, using the board’s fields and BRASPER’s own rules (three currencies, commission shown up front, WhatsApp always one tap away). Illustrative wireframes with sample values, not final design.

What the validator and the operator would see

The VIEW is the one screen we build for the team. The person validating payments changes order statuses here and marks which orders to export. The Dashboard is not touched: the exported file is imported into it as today. Wireframe with made-up rows.

What changes, element by element

Each row is one improvement from the board, with what it replaces today and the Kambista behaviour it can borrow.

Where AI helps, and what it should be worth

From the IATHON diagnosis (challenge 5.5, sales and billing at Brasper). Payment validation stays with a person, so AI is limited to three optional pieces with a track record in remittance and exchange businesses (the evidence is in A1 to A3 of the To-be section). The numbers below are the team’s baseline and hypotheses, not measurements I made.

Baseline, hypotheses and what they imply

The schema the board asks for, and a 4-day cut

The board flags “dB Schema!!!” in red and the notes list “define the BD schema” as pending. Below is a draft built only from the fields named on the board and in the notes, plus the MVP limits the team gave: four days, happy path only.

Draft schema suggested, to validate

MVP cut for four days suggested

Dependencies and risks

The flow behind “Script Fact”

Fact takes a set of orders that a person exports from the Dashboard and imports into Fact, which then runs the whole set. It registers each sale through the provider’s API with the tax authority (SUNAT in Peru through KeyFácil, the Brazilian equivalent through Omni), builds the PDF itself from the XML it gets back, and emails that PDF. It replaces today’s billing steps 6 to 9: pre-validate, register in KeyFácil / Omni, consolidate, email.

When something goes wrong (per record)

Pseudocode of the job

# input: the set of orders a person exported from the Dashboard and imported into Fact
batch = ingest(file)                                   # 1 schema + checksum, skip already-invoiced ids
for rec in batch.records:                              #   bounded concurrency
    try:
        check(rec)                                     # 1 country rules; DataError → rechazado_validacion
        svc = service_for(rec.direction)               # 2 PE→BR: keyfacil → SUNAT · BR→PE: omni → BR authority
        res = svc.register_sale(rec, key=rec.operation_id)   # idempotent; returns xml (+ cdr / protocol)
        if res.rejected:  mark(rec, "error_fiscal", res.code); continue
        if res.pending:   mark(rec, "pendiente_autoridad");   continue   # polled later
        store_xml(rec, res.xml, res.cdr)               # 3 untouched, hashed
        pdf = render_pdf(res.xml)                      # 4 from the XML, never from the DB
        assert totals(pdf) == totals(res.xml)          #   PDF ≠ XML → error_pdf, no email
        send_mail(rec.customer.email, pdf)             # 5 log message id
        mark(rec, "facturada")
    except DataError  as e: mark(rec, "rechazado_validacion", e)
    except Transient  as e: retry_later(rec, status_check=True)  # ask the service before resending
report(batch)                                          # 6 per-row result to the BD / VIEW + daily consolidated

What billing would see (in the VIEW, not in the Dashboard)

A phased path (my proposal)

The board does not set an order, so this is one that delivers value early: first stop the leaks on the live site, then capture data, then verify, then export and invoice, then widen the channels.

What I read from the board, and how sure I am

Handwriting leaves room. These are the readings I used; correct any that are wrong and the diagram above will change with them.