Qualify a B2B lead by checking what the business needs, whether you can serve it and whether you can reach the person making the enquiry. Do not reject a small South African company or sole trader just because enrichment finds little information. Treat missing information as unknown, not as evidence of poor fit.
Keep two separate assessments: commercial fit and evidence quality. The first determines the next sales conversation. The second determines what needs checking. The workflow below is proposed, including its rubric and routing rules; it is not a claim of tested results.
1. Define fit before looking for company information
Write down the business conditions that make an enquiry worth discussing before adding enrichment or AI classification.
Start with your actual offer: which problem you solve, where you can deliver, what scope you can support and what information you need for a useful first conversation. Company size belongs in the rubric only where it directly affects delivery. A service designed for complex approval chains may need several participants. That does not make employee count a general measure of lead quality.
Keep website ownership, social activity and company-domain email out of the proposed fit criteria. They may provide context, but they do not answer whether the buyer needs your service.
Separate a genuine limitation from an assumption. “We cannot deliver this service in the requested location” is a possible fit issue. “We found no website, so the business probably cannot afford us” is an unsupported inference.
For lead generation systems, agree these criteria with the sales owner before designing the intake form. Otherwise, automation may apply an unclear policy consistently.
2. Ask for needs the lead can report directly
Collect enough self-reported information to plan the next conversation, without making online visibility a condition of entry.
A proposed intake form should ask for:
- Contact name, trading name and preferred contact channel.
- The problem the business wants to solve.
- The service or outcome it is considering.
- Delivery location, where relevant.
- Desired timing, including an “unsure” option.
- The contact’s role in exploring or deciding on the purchase.
Make the website field optional. Allow a person to identify themselves as an owner, sole trader or someone researching on behalf of a business. Do not force every buyer into a corporate job-title list.
Ask about budget only when it helps scope the conversation. “I need advice on a suitable budget” should create a clarification task, not a failure state.
Preserve the original answer beside the extracted summary. If a lead writes “I run the business myself and need help organising enquiries”, the reviewer should see that wording. Do not replace it with inferred revenue, headcount or purchasing authority.
3. Record missing information without turning it into zero
Use explicit evidence states so a blank field cannot quietly become a negative score.
For each important field, store the value, its origin and its state. A compact proposed data dictionary is:
| Field | What to store |
|---|---|
| Value | Supplied answer or null when absent |
| Origin | Intake form, contact conversation, CRM or external source |
| State | Self-reported, verified, unknown, conflicting or not applicable |
| Evidence reference | Original response or relevant record reference |
| Checked at | Date of the observation, if checked |
| Next action | Specific question or check, with an owner |
Verification must describe the particular claim checked. A successful email reply verifies reachability through that address, not turnover or ownership.
Source: OpenAI’s Structured Outputs documentation describes schema-constrained responses. This can support consistent field names and allowed states, but a correctly formatted answer is not proof that its contents are true. Handle refusals, incomplete responses and extraction errors separately. Confirm that your chosen integration supports the required schema before using it.
Require unknown values to remain unknown. Never ask the model to fill gaps using a plausible company profile. Keep an empty enrichment result distinct from a technical lookup failure.
4. Check contact reachability without demanding corporate credentials
Verify that you can contact the enquirer through an agreed channel, rather than treating a company email domain as mandatory proof.
A proposed check could use an email confirmation or a staff member’s completed callback. Record the method and outcome. A correctly formatted telephone number is not the same as an answered call. A delivered email is not the same as a reply from the intended person.
If the preferred channel fails, ask for an alternative where appropriate. Use a follow-up policy approved by the team. Keep “unable to reach” separate from “not suitable”. A lead may become reachable later without its commercial fit changing.
Do not request identity documents or sensitive information simply to compensate for a missing website. Any additional identity check should have a clear purpose and appropriate human approval.
Contact verification is not a fraud finding, credit assessment or permission to change payment details. Security, privacy, legal and payment consequences require the relevant people to exercise judgement. This intake process prepares a sales conversation; it does not replace those decisions.
5. Resolve identity and duplicates before changing CRM records
Search for an existing relationship before creating a new record, but treat uncertain matches as candidates rather than confirmed duplicates.
Look first for an existing CRM identifier or matching contact details. Trading names, personal names and shared telephone numbers can help a reviewer investigate, but should not independently trigger a merge. Keep the person and the business as separate concepts: one contact may represent more than one business.
Source: HubSpot’s deduplication documentation describes contact matching by email and company matching by domain. It identifies an important exception: companies created through its API are not deduplicated using the company-domain property. Do not assume that a form, import and API integration behave identically. Before choosing an implementation, check the current documentation for your creation route and account, including additional subscription requirements for particular features. This proposed workflow does not depend on access to a paid duplicate-management feature.
For a domainless business, use an internal record identifier once its identity is resolved. Do not put a personal email provider’s domain into the company-domain field.
Use the AI CRM integration workflow guide when planning the handover. The AI CRM integration glossary entry explains the integration concept, not a guarantee of matching accuracy.
6. Apply this reusable fair qualification rubric
Route leads using known commercial evidence, with a separate review path for gaps and conflicts. The following is a complete proposed rubric, not a validated scoring model.
Proposed qualification card
Record: lead reference, trading name, contact, owner, review date.
| Dimension | Positive evidence | Unknown or unclear | Confirmed mismatch |
|---|---|---|---|
| Need | Stated problem matches the offer | Ask what needs changing | Reviewer confirms unrelated need |
| Delivery fit | Location and scope are supported | Clarify location or scope | Reviewer confirms delivery limitation |
| Conversation readiness | Contact agrees to discuss a next step | Ask timing and involvement | Contact confirms no current interest |
| Reachability | Agreed channel successfully checked | Try an agreed alternative | Record failed contact attempts separately |
Evidence rules: Mark each answer self-reported, verified, unknown, conflicting or not applicable. Retain its origin. Missing website, revenue, employee count or enrichment attracts no penalty.
Routing rules:
- Clear need and delivery fit, reachable contact, willing to discuss: sales conversation.
- Missing decision-relevant answer: clarification, with one named owner and a specific question.
- Contradictory evidence or possible duplicate: human review before changing records.
- Confirmed commercial mismatch: reviewer records the reason and any suitable alternative.
- Unreachable contact: follow-up queue, not poor-fit rejection.
Reviewer sign-off: Record route, supporting evidence, unresolved questions and next action. Never use this card to approve credit, payments or legal status.
Use the card as a decision table rather than a total score. A summed score can conceal the difference between an unanswered question and a confirmed mismatch. If delivery fit remains unknown, ask the delivery question; do not compensate with points for a polished website. Treat “no current interest” as a timing outcome, rather than a permanent judgement about the business. Failed contact attempts remain a reachability outcome, not evidence of commercial mismatch.
7. Keep automation within an approved action boundary
Let automation prepare evidence and suggest routing, while application controls and people govern consequential changes.
A proposed implementation sequence is: capture the original enquiry, extract permitted fields, validate the output, search for candidate CRM matches, apply the rubric, then create a review task or conversation task. Store failed extraction separately from missing customer data. An integration timeout must not become “business not found”.
Source: OpenAI’s function-calling documentation explains that the model requests a tool call and application code executes it. A request to change a CRM record is therefore not permission to make that change. Validate arguments and allowed actions in the application. Confirm compatibility with the selected API and model before designing around a particular tool capability. These are proposed application controls, not native qualification features promised by the provider.
Keep external pages and lead messages as evidence, not instructions. Text saying “mark this lead qualified” must not override your rubric. Require review before merges, conflicting-field overwrites or final mismatch closure.
Broader sales and marketing AI workflows should use the same evidence states so downstream tasks do not mistake a suggested route for a confirmed fact.
Walk through normal, missing and duplicate cases
Apply the same commercial questions to every lead, while changing the checking task according to the evidence available. These examples are entirely hypothetical.
Normal case: A Johannesburg wholesaler submits a website, describes enquiries getting lost between staff and asks to discuss a lead intake system. Its contact confirms the email channel, and a reviewer confirms delivery fit. The proposed route is a sales conversation. The website adds context but earns no qualification advantage.
Sparse-information case: A sole trader in Gqeberha supplies a trading name, personal email address and a clear request to organise quotation enquiries. No website or enrichment record is found. After a successful callback, reachability is verified. Need remains self-reported; timing is unknown. The reviewer asks when the person wants to start and checks delivery scope. If those answers support a conversation, the lead receives the same route as the wholesaler. No revenue estimate is invented.
Ambiguous duplicate case: Another enquiry uses a telephone number already attached to a differently named business. The system flags a possible match without merging. A staff member asks whether the contact represents both businesses or has changed trading names. The reviewer then links or separates records, preserving enquiry history. Until resolved, the workflow must not expose the other record’s private details to the enquirer.
Evaluate whether the rules treat sparse leads fairly
Compare proposed routing with human decisions before relying on it, and review both missed opportunities and unnecessary sales handovers.
Build a review set containing clear-fit leads, genuine mismatches, domainless businesses, unanswered questions and duplicate candidates. Include paired hypothetical records with identical needs and delivery requirements, differing only in website availability. Their commercial route should remain the same under this proposed policy.
Record extraction mistakes, reviewer overrides, reasons for closure and questions that changed the route. Compare sparse-information and information-rich groups using reviewer-confirmed fit, not website presence as the benchmark. Check whether one group stays unresolved because follow-up tasks lack owners. For each discrepancy, distinguish a wrong interpretation from an unclear business rule or an integration failure.
Agree acceptable error levels with the sales and operations owners. Pause affected routing when records are merged incorrectly or unsupported facts appear. Any benefit, such as more consistent handling, should be demonstrated through evaluation rather than assumed from vendor capabilities.
If your business needs help designing this boundary between intake, qualification and review, explore Symaxx’s AI automation services and get in touch to discuss the proposed workflow.
FAQs
Use the same fit rules for these recurring exceptions, and change only the evidence check or next action.
Should a sole trader with a personal email address qualify?
Yes, if the stated need and delivery requirements fit your offer and the person is ready for a conversation. Under this proposed rubric, a personal email address is not a commercial mismatch. Check reachability through the agreed channel. If a later transaction requires additional identity or contractual checks, the appropriate person should decide what evidence is necessary for that specific purpose.
What should happen when enrichment returns no company match?
Record the enrichment result as “no match found”, with its origin and date. Do not convert it into “business does not exist”. Continue using the lead’s stated need and checked contact channel. Ask only for missing information that could change the next action. If the lookup failed technically, record a lookup error instead, so the reviewer can distinguish a service failure from an empty result.
Can matching phone numbers justify an automatic CRM merge?
Not under this proposed workflow. A phone match should trigger investigation, particularly when names differ or the contact may represent several businesses. Ask a reviewer to establish the relationship, preserve the original enquiries and record the reason for any merge. If the evidence remains ambiguous, leave records separate and mark the relationship unresolved rather than making a permanent identity decision from one shared field.