- Plan blockAudience, offer, area, period, chosen by the salesperson.
- UniverseInstitutions in the area and their decision-makers.
- SortingA classification model keeps what fits the block.
- ERP checkAlready a customer, known contact, or handled by a colleague.
- List to callEnriched, deduplicated institutions and contacts.
The context
Once the season plan was in place, the salespeople made their next request: the plan says where to go, it does not say whom to call. Building a list of institutions and finding the right contacts took most of their time, with several spreadsheets open. Their requirements: one central, deduplicated list, showing when an institution is already handled by a colleague.
What was built
- The starting point: a real block from a salesperson's plan (two countries, a media offer).
- Building the universe of institutions and their decision-makers, through data services connected to an AI model.
- Sorting by a fast classification model: 2,337 organisations sorted in under two minutes, 1,200 people in under one minute.
- Cross-checking with the ERP: institution already a customer or not, contact already known or not.
| Institution | City | Decision-maker | In the ERP |
|---|---|---|---|
| School A | City 1 | Head of admissions | New |
| University B | City 1 | Corporate relations manager | Customer |
| School C | City 2 | Head of marketing | New |
| Institute D | City 3 | Head of programmes | Handled by a colleague |
| School E | City 3 | Head of admissions | New |
The result on a real block
On this block, the list holds 72 institutions and 351 contacts; 292 of those contacts and 33 institutions were not in the ERP. 23 of the 28 customers already known in the area were found. The cost in data credits: a few dollars for the whole list.
The module rests on three elements kept up to date over time: a reference list of institutions built once and maintained, targeting rules per brand set by management, and a clear answer on the right to store this data.