AI prospect research: build a brief you can actually check

Start with a decision, not a long company profile

The useful question is usually small: what does the account owner need to know before a discovery call? A ten-page profile is a poor output if the reader needs three reliable facts and two questions. I would define the brief before choosing the model: what the company does, why the person contacted us, relevant evidence, unanswered questions and the next action.

This article uses Aster Analytics, a fictional software business. Its contact asks for faster call preparation. That request supports a research task. It does not establish budget, buying intent or authority.

Keep source text beside each claim

For the example, the company page says Aster makes reporting software for operations teams. A team page lists 18 people. The first source supports a product-and-audience statement. The second supports only the observation that 18 people are listed; it cannot establish total headcount.

A useful record has four fields: claim, source excerpt, source reference and review status. In a real implementation I would also store the retrieval date. If the source is inaccessible or contradictory, the field stays unknown. Repeating a plausible statement across model responses does not turn it into evidence.

Make an error visible before automating the handoff

Our deliberately flawed draft says: “Aster has 18 employees and is ready to invest in AI.” Both conclusions go beyond the evidence. The reviewer replaces them with: “Aster builds reporting software for operations teams. The contact wants faster call preparation. Team size and budget are unconfirmed.”

The corrected brief creates two useful questions: how many discovery calls happen each week, and what research does each call need? This is a better handoff than a confident but unsupported qualification score. The interactive example shows the original draft and correction together.

Evaluate the workflow before connecting it to the CRM

Use a small, representative set of enquiries with reviewed reference briefs. Include incomplete websites, similarly named companies, inaccessible pages and conflicting source text. Count unsupported claims, missing required facts and reviewer corrections. Record the time spent checking the output as well as the time spent generating it.

Decide the acceptance threshold with the account owner. A draft that saves generation time but doubles checking time has not solved the problem. Keep the first release limited to draft notes, with a named reviewer and a way to return to the manual process.

What this example does not prove

The demonstration uses pre-authored fixtures. It makes no live model calls and cannot establish accuracy, speed or commercial benefit in your business. Real deployment depends on source access, model behaviour, privacy requirements and the CRM permissions available. The next step is a scoped evaluation using data you are authorised to process, followed by a measured pilot.