Actionable lists for sales

Split into three steps: (1) selection of eligible customers for the current action, the only part that changes per action; (2) exclusion of those already sent; (3) formatting in the exact layout of the destination. The eligibility table carries the action name, so the history and the feedback know where each contact came from.

Eligible: checkout with no completion date (completedAt null), with an identified customer, value above the action's minimum, each customer's latest abandonment in the window. Customers who placed an order after the abandonment are removed. To prioritize, join with ERP or hub history: customers who bought at least twice, with an average ticket above the minimum, in the order statuses that count as a sale.

In the ERP, the sales pipeline mixes quotes and orders in the same stages. Treat it as an order only when the payment method has been entered on the installment; before that, it is an open quote. For the list of most-quoted, unclosed items, count quotes per item over the last few months and the conversion (quotes that became an invoice / quotes), linking cart to invoice by the full key (store and invoice number).

The last purchase comes from ERP invoicing, not from the latest CRM activity. Lapsed means the customer went past their own purchase cycle without coming back, prioritized by customer classification (A, B, C). Not every customer who buys has a CRM record: the list comes from the ERP and creates or updates the record. A dedicated win-back pipeline in the CRM separates reactivation contact from regular sales contact.

Join the online store and the ERP by CPF (individual tax ID) or CNPJ (company tax ID) as digits only, or by lowercase email. When the destination does not store the ID, embed the key in an extractable format: an "Email: <e-mail>" line in the task description, or the ERP ID in parentheses in the card title ("NAME (123)"). With no name, use "Unnamed customer (<id>)" instead of leaving it blank.

Every round writes to an insert-only table: customer, reference (the cart, the quote), action and send date. Before sending, exclude anyone already in the history for the same action. The history is never overwritten by the next round; it is what guarantees idempotency when the send runs again.

Sends fail halfway. Before resending, read the tasks that already exist in the destination list, extract the key (the email in the description) and send only the missing ones. Run in test mode first, without writing, and make a send failure break the run so it shows up.

Read back the open tasks in the list (customers to handle, negotiating, no reply, follow-up, did not buy). When the customer placed an order after the task was created, mark the task as "bought" and store the number and value of the first order. That way each action has conversion and revenue measured by the order, not by the manual status.

Besides the per-customer lists, send yesterday's summary by store every day in the CRM chat (sales and quotes, count and value) and the cards in qualification or negotiation by salesperson, with value. Exclude system and integration users from the ranking. The text sent is the same one that gets stored, for checking.

List tables store flags (has phone, has document) and, when needed, a hash of the contact with the secret kept in the vault, not the data in clear text. Shared views show a masked CPF. Phone and email only appear in the final step, which writes to the destination.