The local ledger never catches up with the platform
People changed, sheets changed, someone sent invites by hand in the back office. The local record only covers part of the history, so deduping against it alone guarantees repeats.
Creator outreach: turning 'scroll the back office, hope it is not a repeat, check before sending' into a traceable line
The expensive part of outreach is not sending. It is **the cost of sending wrong**: a repeat invite damages the account and the relationship, and your local record of who has already been invited is almost always shorter than the platform's.
01
Where it used to get stuck
Filters live in two places and disagree
Category, follower count and average order value are partly platform filters and partly human judgement. When the two disagree, the shortlist contains people who do not actually qualify.
The approval step is where the process breaks
An operator wants to see the list before it goes out, but by the time they come back the run has drifted — the list has been recomputed, or people were topped up to fill the quota.
02
How it runs once handed over
Filter on your criteria, written down rather than remembered
Category, creator tier and metric thresholds are fixed as parameters, so every round runs the same way and nothing deforms when someone else takes over.
Three dedupe passes: local ledger, platform-side, within this round
The second one is the one that matters — **confirming 'not yet invited' inside the platform's own filter**. Only what is still findable there counts as genuinely un-invited; a local ledger cannot cover it.
A preview list that waits for your approval
The preview carries the criteria each creator matched and the dedupe evidence, so you can see why these people and not others.
Send exactly the list you approved — no topping up
Once approved, the list is pinned. If someone becomes unavailable the round simply sends one fewer. It will **never quietly add the next candidate**, because that means sending to someone you never reviewed.
Reconcile against the platform afterwards
Actual results are written back to the ledger, which is what makes the first dedupe pass accurate next round.
03
Where it stops for a person
- Sending always waits for a person to approve. A preview is not a send
- An approved list is pinned: never recomputed, never topped up
- Qualification thresholds are yours; it does not relax them on its own
How it is accepted
- Spot-check people from the preview against the platform's own not-yet-invited filter
- Reconcile the number actually sent against the approved list — exactly, not roughly
- On the second round, nobody from the first round should reappear
04
Where the definitions come from
06
Questions
How does it operate the back office? Is there an API?
Where an open API exists it is used. Where it does not, a real browser carries your existing signed-in session and takes the same path a person would. Both routes pass through the same approval gate.
Could it send to creators who do not qualify?
Qualification is a parameter and filtering is finished before the preview, so the list you see is the list that goes out. Combined with never topping up after approval, the list cannot be silently swapped.
How many can one round send?
A cap you set. It will not relax criteria to fill that cap — it would rather send fewer this round than send to someone who does not qualify.