The lead profile the salesperson sees before closing: already bought, owes money, where they came from
The salesperson closes the deal. Then finance discovers the person was already a student, was delinquent and came back with another e-mail. Renegotiation, cancellation, refund. All of it was in the base — in three different systems. The lead profile is where it would sit together, before the call.
The case is real and it repeats: a former mentorship student, with overdue installments, comes back through an ad, talks to a new salesperson, and buys again — sometimes with another e-mail. The salesperson celebrates. Days later finance crosses the data and the problem appears: the person was delinquent, and now has two enrollments and a debt. The sale becomes a renegotiation, or a cancellation, or a refund.
Nobody made a mistake. The salesperson had no way of knowing: delinquency lives in the finance system, the previous purchase on the payment platform, and the conversation in the CRM. The lead profile is the answer to “what did I need to know before calling” — and it only exists when leads are centralized.
What the profile needs to show
- Who they are: name, e-mail, phone — every one the person has used, with the primary marked.
- Where they came from: the first ad, the first page, the campaign. Not only the last click.
- What they already bought: product, date, amount, status. Renewals separate from new purchases.
- How they stand: overdue installment, cancelled subscription, refund requested — the finance system’s state, with a date.
- Which audiences they are in: “delinquent”, “student of product X”, “abandoned checkout” — the sets the product maintains.
- The whole timeline, for whoever wants the story.
The state that comes from outside: the database source
Delinquency is rarely an event on the payment platform — Hotmart marks the installment as late and never changes the status again, even when the person settles it outside. Who knows the truth is the customer’s finance system, which records renegotiation and manual payment. For the profile to show the right state, that system needs to enter as a source: a SQL query on the customer’s database, read periodically, which becomes a lead attribute (payment status) and a timeline event when it changes.
The truth about the debt lives where the debt is handled — not where the charge was generated. The profile has to read from there.
The other e-mail
The former student who comes back often uses another e-mail — on purpose or not. If the profile only matches by e-mail, they show up as a new, clean lead. What solves it is identity by phone and by document, with the merge rule that joins strong identifiers: the phone on the new form is the same as on the old purchase, and the two profiles become one. That is why capturing the phone on the form is not a detail.
Where the salesperson sees it
Three paths, from simplest to most integrated: (1) the profile in the product itself, which the salesperson opens by e-mail or phone; (2) the “delinquent” audience wired by webhook to the CRM, which tags the contact before the first conversation; (3) a query from the CRM or the WhatsApp automation to the base, the moment the lead enters, returning “alert: former student, installment overdue since March”. The third is what prevents the wrong sale; the first is what makes the salesperson trust the data.
A number to size it: in a mentorship with about 2,900 students, 686 were delinquent according to finance — almost one in four. Each of them is a sale the sales team can close by mistake.
In CrazyLeads the lead profile brings together identity, origin, purchases, audiences and the timeline of every source; the database source reads the customer’s finance system and stores payment status as an attribute; and the “delinquent” audience can notify the CRM by webhook the moment the person enters it.