Buying-committee enrichment

Role

With engineering support, we designed the workflows, wrote the agent instructions and the scoring rules, and built the tools underneath them.

Surface

A single Slack channel. No application, no login, no training.

Users

The US and UK sales teams. Account executives, account managers, and business development across Texas, Illinois, Georgia and the wider US.

Built on

A Relevance AI agent with 17 tools and four workflows, running on a ChatGPT 5.6 Luna.

Sources

Apollo and Apify for discovery, web search to fill gaps, Salesforce for account context.

Writes to

A shared Google Sheet on every run, and Salesforce on an explicit reply.

Prospecting research is expensive, repetitive, and the output evaporates.

1. Hours for research

   To open a conversation with a warehouse or a retail chain, a seller needs the operations lead, the HR lead, and whoever controls the contingent labor budget. Finding those three people means cross referencing LinkedIn, a data provider, and the company site, then guessing at an email format.

2. Names are not the same as a buying committee

   A list of titles does not tell a seller who to call first. Twelve contacts with no ranking is a worse starting point than three with a reason attached, because the seller still has to do the thinking.

3. The output never reached the CRM

   Research landed in a personal spreadsheet, or a notebook, or nowhere. The next person to work the account started again, and the company never accumulated anything from the effort.

Two requests, typed in plain language, in a channel the team already had open.

Find the buying committee. “Find the decision makers at Acme” returns contacts grouped by Operations, HR, and Procurement, each with a title, location, email, phone, LinkedIn, a persona, and a score with a written reason.

Enrich one person. “Enrich Jane Doe at Acme” or a bare LinkedIn URL returns the missing email and direct phone for a contact the seller already has.

Both write to the same shared sheet. Replying in the thread pushes the contacts into Salesforce under the requester’s ownership.

Scroll to see the full interface

Channels

Decision Makers Researcher

Decision Makers Researcher

AH

Anthony H.9:14 AM

Find the decision makers at Acme Logistics in Fort Worth, TX

AI

Decision Makers ResearcherApp9:16 AM

Acme Logistics

Enterprise  |  12,000 employees  |  $4.1B revenue  |  4 contacts found

Operations

B. Okafor SVP, Store Experience and Business Operations Decision makerScore 4Apollo Houston, TX  |  b.okafor@acmelogistics.com  |  +1 415 555 0186

Human resources

A. Rivera VP, Human Resources and Talent Acquisition Decision makerScore 5Apollo Austin, TX  |  a.rivera@acmelogistics.com  |  +1 615 555 0142

C. Lindqvist Regional Human Resources Manager InfluencerScore 4Apify Fort Worth, TX  |  no email returned  |  no phone returned

Procurement

D. Mensah Director, Strategic Sourcing Budget holderScore 4Apollo Dallas, TX  |  d.mensah@acmelogistics.com  |  +1 469 555 0113

AH

Anthony H.9:18 AM

push the ops and procurement contacts to salesforce

AI

Decision Makers ResearcherApp9:18 AM

Created 2 net-new contacts on the Acme Logistics account, owner Anthony H.

Skipped 1: C. Lindqvist has no email.

Message #decision-makers-researcher

The interesting work is not the model. It is the constraints written around it.

The agent runs on ChatGPT 5.6 Luna, a cheap model, with memory off and extended thinking off. That is a deliberate choice rather than a budget one: almost none of the difficulty in this problem is reasoning difficulty. It is knowing which of four procedures to run, which sources to try in what order, and when to throw a result away. All of that is better expressed as an explicit rule than left to a model’s discretion, and once it is explicit, a cheap model executes it as well as an expensive one and does it the same way twice.

Scroll to see the full interface

Decision Makers Researcher

Build

Instructions

Tools

Knowledge

Triggers

Quality

Evals

Run history

Instructions

1. Set internal flags. Do not reason or select a workflow until the result is received. 2. Route on the flags: IF REQUEST_TYPE = named_person to Person Workflow ELSE IF REQUEST_TYPE = company AND CONTAINS_LOCATION = true to Location Company Workflow ELSE IF REQUEST_TYPE = company AND CONTAINS_LOCATION = false to General Company Workflow ELSE IF REQUEST_TYPE = industry_location to Location and Industry Workflow ## Company identity guard Verify every candidate’s current employer against the canonical domain before enrichment, and again before output. A similar company name is not sufficient. Never enrich, rank, or output a candidate who fails.

Tools

Set internal flags Find decision makers, Apollo Find decision makers, Apify Find by industry and location Enrich known person Enrich in bulk Google search Salesforce company search Create and populate Google Sheet Create or update Salesforce contact Create or update Salesforce lead + 6 more

Temperature 0 Memory off Extended thinking off 17 tools 4 workflows 20 eval cases

1. Classify with a tool, not with judgment

   The first thing the agent does on every request is call a tool that sets four flags: what kind of request this is, whether it names a location, whether it came from Slack, and whether the seller wants everything or only the strong matches. It is explicitly forbidden from reasoning or choosing a path until those flags come back. Routing is the decision that determines everything downstream, so it is the one decision that is not left to the model.

2. Four procedures, not one prompt

   A named person, a company, a company at a specific site, and an industry across a region are four different research problems. They get four separate workflows with their own ordered steps. A named person is enriched directly from strong identifiers and never through a broad search. A company with a location starts with the source that handles geography well; a company without one starts somewhere else. The agent is also told not to ask clarifying questions on a standard request, because a question in a Slack thread costs more than a slightly imperfect first answer.

3. Escalate only when the quota is short

   Each workflow is a ladder. Run the primary source, deduplicate, count what is missing against the quota, and only then reach for the next source. Every rung is capped: one call to each of the two contact databases, no more than three targeted web searches to fill a specific gap, five across the whole run. Most requests never reach the top of the ladder. The cap is what keeps a request that is going badly from quietly becoming an expensive one.

4. The identity guard

   The most damaging failure in contact data is not a missing person, it is a real person at the wrong company. A similar name is treated as no evidence at all. The agent has to confirm each candidate’s current employer against the target domain before enrichment and again before output, and if there is no domain evidence it needs two independent sources tying that person to that exact company. Anyone who fails is dropped before their details are ever looked up, so a bad match costs nothing and never reaches the seller.

5. Quotas, and a blacklist

   The target is a small, balanced committee rather than the longest list available: a handful of Operations, a handful of HR, and up to two in Procurement. The quota governs when to stop searching, who gets enriched, and what appears in the answer. A short blacklist strips out the titles that keyword matching reliably gets wrong.

6. Segment decides how much structure is worth it

   The agent sizes each company from headcount and revenue and then treats the two segments differently. A mid market company gets a simple departmental ordering, because a 400 person business does not have a buying committee worth mapping. An enterprise gets a persona assigned to each contact and the contacts split between global and site level, because that is the distinction that decides whether a seller is pitching one warehouse or a national agreement.

7. The same agent behaves differently by surface

   One of the flags records whether the request came from Slack, and it changes both the filtering and the formatting. From Slack the geographic filter is loosened, because a seller in a thread would rather see a good contact one state over than nothing, and the answer is written in Slack’s own markup rather than Markdown. Outside Slack the location filter is strict and the output is a table. Same agent, same rules, two surfaces.

8. Grounded in what actually closed

   The agent carries reference material, including closed-won revenue and deal counts by industry from the company’s own pipeline. Scoring leans on evidence about which industries have historically bought, rather than on a generic idea of a good prospect.

9. Say what you did not find

   Several rules exist only to stop the agent hedging. It may not tease data it is holding back or offer to share more later. If it found nothing beyond what the seller already supplied, it has to say so plainly and ask for a stronger identifier. When it pushes to the CRM, it has to report which contacts were skipped and why. An answer a seller can trust has to include the parts that did not work.

The format is the product. A list of contacts is data. A list of contacts that says who to call first, and why, is a decision a seller can act on or argue with.

Most of these are about restraint rather than capability.

1. The interface is a channel, not a product

   No login, no dashboard, no onboarding flow, no adoption curve. A seller types the sentence they would have sent a colleague, in a tool that is already open on their second monitor.

   The side effect matters more than the convenience. Every request and every answer is public in the channel, so the team learned to prompt it by reading each other’s messages. Nobody ran a training session.

2. Rank the committee, do not just list it

   Each contact gets a department, a buying-committee persona, and a score with a sentence explaining the score. That sentence is the point. It gives the seller something to disagree with, which is what turns a data dump into a call list.

3. One sheet, forever

   Every run appends to the same shared sheet rather than generating a new file. It sounds trivial. It was the difference between research that accumulated into an asset and research that scattered into a hundred abandoned spreadsheets.

4. Writing to the CRM is a separate, human step

   The agent never writes to Salesforce on its own. The seller has to reply in the thread and ask. Only net-new records are created, ownership is assigned to the requester, and the agent reports back exactly which contacts it created and which it skipped, naming the reason for each skip.

   Automatic CRM writes would have been one less click and a permanent data quality problem.

5. Say when the answer is weak

   Missing fields stay visibly blank instead of being filled with a plausible guess. A contact who does not fit the buying profile comes back with a low score and a blunt reason, even when the seller clearly hoped for a better answer.

   Contact data is the one place where a confident wrong answer is worse than no answer, because it goes straight into an email to a stranger.

I created this end to end, with engineering support.

I owned the product: the workflows, the agent instructions, the scoring and persona rules, the quotas and the blacklist, the identity guard, the output format, and the decision about where a human has to intervene. An engineer built the tools those instructions call and wired up the connections to Slack, Salesforce, and the data providers.

1. Turned a vague ask into four procedures

   “Find me decision makers” is not one job. Separating it into a named person, a company, a company at a site, and an industry across a region, then writing the ordered steps for each, is what took the agent from unpredictable to reliable. The same split is why routing could be pushed into a deterministic tool instead of left to the model.

2. Wrote the rules that decide what counts as a good contact

   The departmental quotas, the title blacklist, the mid market and enterprise thresholds, the persona set, and the score with a written reason. These encode how the company actually sells into warehousing and retail, which is the part no general-purpose prospecting tool knows.

3. Specified the failure modes before the features

   The identity guard, the per-source call caps, the blank-not-guessed rule, and the ban on hedging all came from watching the thing fail in ways that would have cost a seller credibility with a prospect. Most of the instruction set is there to prevent a specific bad answer I had already seen.

4. Made it self-serve

   Wrote the operating guide for the channel and set the channel purpose so a new seller can work out what to type without asking anyone. It covers the two request modes, worked examples, and the reply-to-push CRM step, which was the part people kept missing.

5. Closed the loop into the CRM

   Pushed for contacts to land in Salesforce directly rather than through manual upload, so the research became company property instead of a personal sheet.

6. Added the human verification layer

   Agent output is a starting point, not a finished list. On a large retail target I turned a raw run into a prioritized import: contacts ranked by relevance to the actual play, grouped into field, procurement, and HR, each with a note on why they matter, and every unverified email explicitly flagged as unverified before any bulk send.

1. Measure what converts

   The agent scores every contact from one to five, but nothing yet compares those scores against which contacts actually replied or booked. That feedback loop is the difference between a scoring model and a guess with a number on it.

2. Let the research file itself away

   This agent is now one of the allowlisted behind the governed enrichment connector in the sales knowledge system, so the same research the Slack channel produces can be reached from inside the assistant rather than only from a spreadsheet. The remaining gap is durability: a run should leave a cited account page behind it, so the second person to ask about a company reads the answer instead of paying to generate it again.