Companies’ use of AI voice agent services for the first commercial call is a documented trend across both B2B and B2C sales environments.

A widely shared case report shows an improvement from 12% to 44% in the share of contacts that clear a pre-qualification filter and are transferred to the sales team, alongside a drop in average time-to-first-contact from ten hours to two minutes.

It matters to be precise about what that figure represents: given how the process is described — an initial call, a requirements check, and transfer only of contacts that pass — the reported percentage corresponds to a qualification rate, the proportion of contacts reaching the salesperson, not necessarily a closed-sale conversion rate, which the case does not report.

This article cites the figure in those terms and avoids attributing to it a meaning the source does not support. A later publication by the same author describes a comparable B2C application in the automotive sector; this paper treats both cases as illustrations of a broader architectural question rather than as representative evidence for either B2B or B2C sales generally.

Taken on its own terms, this result improves the speed and consistency of an already-existing process. But the case itself reveals, without framing it as a problem, a structural condition worth examining: the leads entering the system are the same ones that were entering before the AI’s involvement. The innovation sits entirely within the qualification of contacts already inside the CRM — not within the criterion by which those contacts got there.

We argue that the criterion of entry — typology of a potentially attractive prospect versus a need voluntarily declared by the user — is a more consequential analytical axis than the surface-level contrast between “human salesperson” and “AI agent.”

Public discussion around cases like this one tends, tellingly, to decompose the sales funnel into distinct stages: acquisition, response, qualification, follow-up, and close.

AI qualification agents intervene only in two of these — response and telephone pre-qualification — without touching the acquisition stage (how the contact enters the system) or the close stage (how many qualified contacts actually buy).

This lets us state the article’s central question more precisely than a simple efficiency comparison would allow:

What turns a contact into a “lead”, and at what stage of the sales process is that decision made?

At least four distinct levels are routinely collapsed under the single word “lead”:

• A contact (an individual who fits a target profile or segment),

• An interested party (a contact who has shown some degree of interest, active or passive),

• A pre-qualified lead (a contact verified against certain criteria, through human or automated evaluation — criteria that, as discussed in Section 6.1, are not necessarily objective),

• And an Auto-Lead (an individual who has explicitly declared a need and requested to move forward toward a solution).

As detailed in Section 3, the AI Voice Agent model operates across the first three levels: it receives contacts or interested parties from the company using this kind of service and, through the voice agent’s intervention, converts them into pre-qualified leads.

As detailed in Section 4, IC-APP and IC-CHAT operate exclusively on the fourth: nothing enters the CRM that is not already, by definition, an Auto-Lead.

This distinction maps onto an established methodological one in market research: stated data (self-reported by the subject, with conscious awareness that they are declaring it) versus inferred data (attributed to the subject from the outside — typology, behavior, ad interaction — without their active participation in producing it).

Read this way, calling an Auto-Lead’s underlying data “genuine” is defensible in a strict, epistemic sense: not a claim that the person is more likely to buy, or a better prospect, but a claim about the provenance of the signal itself.

A pre-qualified lead’s profile is inferred about the contact; an Auto-Lead declares its need, authored by the contact. The word describes where the data came from, not what it predicts.

This section describes, mechanically rather than by name alone, how each of the two mechanisms compared in this article currently operates — since neither the AI Voice Agent process nor the IC-APP/IC-CHAT platforms are, at the time of writing, widely documented outside the sources that describe them.

Based on the publicly available description this paper draws on, the process follows a fixed sequence:

• A new contact enters the company CRM through a campaign, ad, or purchased/inherited list;

• Shortly afterward, an AI-driven voice system places an outbound call to that contact;

• The system runs a scripted set of pre-qualification questions — seven, according to the example that originates this paper, but the number can vary according to company interest — designed to verify basic fit (ownership of a relevant product, budget range, timeline, decision-making authority, or similar);

• The AI voice system logs the contact’s answers directly into the CRM record, updating fields that previously required manual entry by a salesperson;

• Only contacts whose answers meet a defined threshold are forwarded to the company’s human salespersons for the next stage of the sales process; contacts that do not meet the threshold remain in the CRM but are not actively pursued further.

The entire sequence, from first ring to CRM update, is reported to take roughly two minutes, compared to an average of ten hours for the equivalent first call to be placed by a human salesperson under the prior process.

It is worth stating plainly what this sequence does and does not accomplish: the AI Voice Agent does not create the lead. It evaluates whether an existing contact should be treated as one — a distinction the rest of this paper returns to repeatedly.

Unlike the sequence above, IC-CHAT does not call a contact to determine whether a need exists. It provides a structured path through which the user can voluntarily identify the problem for which a solution is being sought — and IC-APP provides the equivalent path for visitors who arrive through a different channel.

IC-APP and IC-CHAT are two separate entry points into the same underlying registration mechanism, aimed at different visitor contexts: IC-APP is a standalone bilingual (English/Spanish) web application typically reached through a shared referral code or a direct link, while IC-CHAT is a conversational widget embedded directly on the company website, aimed at organic visitors who arrive with no prior relationship or code.

Both converge on the same structured outcome: a CRM record that did not exist until the visitor chose to create it.

The registration sequence on IC-APP proceeds as follows:

• A visitor first selects a language.

• Then indicates whether they hold a referral code (SHAREICAPP), a completed or rejected project code (FEEDBACK), or neither. (Figure 1).

Figure 1. IC-APP Code Selector screen.

• Before registering any need or contact information, and before any commercial interaction, if the visitor has a SHAREICAPP code, the following page appears to collect that code number (Figure 2A).

Figure 2. The IC-APP screen asking the visitor for their SHAREICAPP code

• After receiving it, the IC-APP thanks the visitor for sharing the code and informs them that this code will be used to provide benefits for the next need and data registration that will occur after this step (Figure 3). This sequence, described in Section 4.4 as the SHAREICAPP outcome, can occur before, independent of, and regardless of whether a sale is ever completed.

Figure 3. The IC-APP thank-you screen, inviting the visitor to the next step.

• They then complete a Solutions User Registration form (Figure 4).

  – First, providing contact details.

  – Then self-identifying as one of several roles (end user, installer, project designer, distributor/wholesaler).

  – Then indicating which solution is needed from a list, along with the desired timing.

  – Next, it asks how they found the IC-APP (what type of referral); if the referral came from an individual or a company, the application requests the details to be added to the CRM as a new contact.

Figure 4. IC-APP Solutions User Registration screen.

• After providing it, the visitor is immediately asked to rate their experience with the platform itself on a 0–5 scale (Figure 5) — a first rating related to the digital tool, not to any solution provided or already installed or salesperson performance. The CRM record is created only at this step, from data the visitor supplies directly. This is the precise moment in the process when an *Auto-Lead* is defined: no “lead” record existed in the CRM before this voluntary action, and the record originates from the visitor’s own declaration rather than an externally assigned classification.

Figure 5A. IC-APP User experience rating screen.

• After visitor Registration and survey, the ICAPP shows the following screen (Figure 5B), asking for written comments about the experience.

Figure 5B. The IC-APP screen asking the visitor for written comments

about their experience (fictitious data for explanatory purposes).

• After registration, an IC-Ambassador — the most relevant human figure in this process, discussed further in Section 2.3 — reviews the declared data and need, then contacts the visitor by call or video meeting. During that conversation, the IC-Ambassador discusses the visitor’s need in depth and agrees together on the final solution, which may itself evolve from the original inquiry as a result of that guidance.

• This information is passed to a Leader team, which prepares a customized proposal.

• Then, the proposal is emailed to the registered visitor along with a new SHAREICAPP code to share with others.

• Whether or not that proposal is approved, or once the project concludes, the user later receives a FEEDBACK code by email, which routes them to a screen (Figure 6) asking for open-text comments and a second 0–5 satisfaction rating — this time rating the interaction with the IC-Ambassador and the process as a whole, including the proposal itself. Figure 6 shows an actual instance of this screen in which the recorded comment explains a non-approval (“Budget was delayed around three months”) — an illustration, drawn from the system’s own interface, of the FEEDBACK2 outcome described in Section 4.4: a non-purchase that nonetheless returns structured, attributable information to the system, rather than dropping out of it silently.

Figure 6. IC-APP FEEDBACK screen, shown here with an actual recorded comment explaining a proposal

that was not approved — an instance of the FEEDBACK2 outcome (fictitious data for explanatory purposes).

• After the FEEDBACK rating, the visitor is asked again for contact data to send a copy of this feedback, including a new SHAREICAPP code to invite others to this experience, and then asked whether they want to register again for a new project (Figure 7).

Figure 7. IC-APP FEEDBACK screen requesting visitor details to send a copy and asking

whether a new registration is needed (fictitious data for explanatory purposes).

• If the visitor selects YES, a new thank-you screen appears, asking them to go to a new Registration process (Figure 8). So, these FEEDBACK steps also provide a new way to generate a genuine Lead or Auto-Lead.

Figure 8. IC-APP FEEDBACK thank-you screen, then going to the Registration Screen

• IC-CHAT, by contrast, reproduces the same logic through a different channel. Embedded as a widget on the company website (Figure 9), it opens with a fixed, button-only branching question — “Solutions User” or “Solutions Provider” — rather than an open-ended conversation, through a scripted sequence of further button choices until a comparable CRM record as “Auto-Lead” is created. No free-text chat or open-ended AI-generated dialogue occurs at any point in this flow; every step is a discrete, pre-defined choice made by the visitor.

Figure 9. IC-CHAT widget embedded on the company website, showing the initial Solutions User-Solutions Provider branching question that begins the same registration logic as IC-APP, through a second channel.

• Unlike IC-APP, IC-CHAT does not provide SHARE or FEEDBACK codes; it captures only the need declaration, contact data, and a short survey about the tool’s use (Figure 10).

Figure 10. IC-CHAT User Satisfaction Survey Screen

Both tools (AI VOICE and IC-APP-IC-CHAT) place a human at the end of the pipeline, but the information that human receives — and consequently what they can do with it — differs sharply between them.

Traditional / Model A salesperson:

Receives contact AI Voice’s filtered → Discovers whether a need exists → Proposes → Sells.

Receives an already-declared need (Auto-Lead)→ Verifies and interprets it → Integrates the appropriate solution provider(s) → Facilitates the solution.

In Model A, the salesperson who receives a qualified contact knows only what that contact’s answers to the AI agent’s script revealed — typically the same fixed set of roughly seven questions (example) the company itself designed, unilaterally and in advance, to filter its own list (Section 2.1).

Those questions were not derived from anything the contact volunteered. As argued in Section 6.1, this means the resulting “qualification” is only as objective as the script that produced it: the salesperson’s starting knowledge inherits whatever bias or gap exists in a set of questions nobody outside the company designed or validated.

The IC-Ambassador, by contrast, is not simply “the salesperson of the IC model under a different name.” As Section 2.2 describes, the IC-Ambassador’s starting point is a need the contact already articulated, in their own words, through their choice of registration path — not a script the company wrote to interrogate them.

The IC-Ambassador’s role is accordingly different in kind, not just in outcome: rather than discovering whether a need exists, as a Model A salesperson effectively still does even after AI-assisted filtering, the IC-Ambassador verifies and helps execute a need the contact has already declared.

This is also why the IC-Ambassador is trained specifically in the IC methodology rather than in general sales technique: their function is integration, not discovery or persuasion.

Neither the registration structure described above nor the SHARE/FEEDBACK mechanism in Section 4.4 depends on the specific subject matter of energy-supply-chain integration. The same sequence — a button-driven or form-driven declaration of a specific need, followed by a “pre-transaction” platform rating and a post-outcome feedback capture regardless of whether the outcome was a sale — could, in principle, be reconfigured around a different set of category options (the “which of these best describes you” choices in Section 2.2, for instance) to serve a different product line or a different industry entirely, without altering the underlying architecture this paper compares against Model A.

This article does not test that generalization empirically, but intends to clarify that the mechanism, not the specific energy-sector vocabulary, is the object of the comparison that follows.

The architecture of this model can be represented as:

Campaign → Contact → CRM (existing) → AI Voice Agent → Pre-qualification → CRM (updated) → Salesperson → Sale

Its defining features are:

• Dependence on a pre-existing database. The CRM contains contacts, segments, and campaigns accumulated through conventional means (purchased lists, ad-generated forms, inherited databases).

• Outbound by design. The organization initiates the first contact, not the prospect.

• AI as an accelerant of one stage, not a redesign of the process. The voice agent replaces the salesperson in the repetitive task of pre-qualification, but the pool of contacts to be processed remains unchanged.

• Entry criterion: typology. A contact enters the CRM by belonging to a profile considered commercially attractive (age range, job title, industry, company size, having interacted with an ad) — not by having declared a need. Here, the contact precedes the lead: subsequent qualification, human or automated, is what attempts to determine, once the contact is already inside the CRM, whether a real (maybe not objectively) need exists at all.

This model effectively solves a throughput problem: how many contacts can be qualified per unit of time, and how consistently.

It does not solve — and does not attempt to solve — whether those contacts represent a genuine, voluntarily expressed need.

The Integration Coefficient IC framework proposes a structurally different architecture:

Content/SEO-GEO/social media → User recognizes a problem →
IC-APP/Website-IC-CHAT → Voluntary Registration-Declaration of Need → CRM (Auto-Lead generated) → IC-Ambassador → Integrated solution Proposal → Project → Feedback/SHAREICAPP

Its key structural elements:

Unlike Model A, the CRM here does not precede the demand-generation process — it is its product. A contact is only recorded after the user, on their own initiative, has interacted with IC-CHAT or IC-APP and declared a specific need.

Both tools simultaneously register two categories of participants: Solution Users (those requiring a solution) and Solution Providers (those able to supply one, internationally or locally).

This bilaterality structurally distinguishes the system from a one-directional CRM built solely to convert buyers, and places IC-APP/IC-CHAT within the theoretical tradition of two-sided platforms (Collaborative Economy models), where a business must get both sides of a market on board simultaneously to generate value for either.

That simultaneity is itself a version of the “chicken-and-egg” problem long studied in platform economics — a platform needs supply to attract demand and demand to attract supply — and it is precisely what IC-APP/IC-CHAT are designed to solve by capturing both roles through the same registration mechanism, rather than sequencing one side after the other.

When providers register with IC-APP or IC-CHAT, they are not routed to the IC-Ambassador but to a Project Leader, who evaluates whether the provider can execute the solution independently or should be grouped into a consortium with other providers already approved by the company.

The company retains contractual and financial control, invoicing the client and paying the provider or consortium — mirroring, at the local level, the same quality-control mechanism applied to its manufacturer worldwide network. This design mitigates the classic disintermediation risk in bilateral platforms, where the two connected parties try to bypass the intermediary in future transactions.

A fair objection to this architecture is that voluntarily declaring a need does not, on its own, guarantee a completed purchase.

That’s correct, and should be stated plainly: entering through IC-APP or IC-CHAT is not a guaranteed sale.

However, Model B does not define a “good” Auto-Lead by its probability of purchase, but by whether the interaction produces a structured, usable commercial signal.

Under this definition, every completed cycle produces one of three outcomes, not mutually exclusive over time:

Unlike a conventional CRM, where an unclosed opportunity is typically marked lost and drops out of the active information flow, Model B captures every outcome:

A purchase generates revenue and reputation; a non-purchase generates market intelligence; and both are useful and totally compatible with system expansion via SHARE.

This redefines what a “good lead” is: not one likely to buy, but one whose interaction, whether or not it ends in a sale, returns an identifiable demand signal to the system.

This comparison should not be overstated as a blanket criticism of the AI Voice Agent model. Adding AI to the pre-qualification stage is a legitimate throughput improvement, and it spares salespeople from spending time on low-probability contacts.

The claim here is not that the model is inferior — it’s that it operates at a different layer of the problem.

AI Voice, in Model A, optimizes how existing demand is currently processed. The Integration Coefficient IC business model intervenes in how demand is generated before it ever reaches a CRM. As a research question:

If AI Voice can efficiently automate lead qualification, why continue generating those leads primarily from databases, rather than from the user’s voluntary identification of a need?

We find a logical tension in Model A worth making explicit. The usual justification for adding a qualification step — human or automated — is to determine whether a given contact represents a real opportunity. That poses a dilemma:

• If the sales team already knows, in advance, that the contacts in its database are good, the qualification function loses its rationale: there’s no need to verify what is already known.

• If the sales team doesn’t know — the scenario most consistent with available evidence, given that the case itself describes contacts who don’t recall interacting with the campaign or who lack the basic attribute required (for example, not owning the product the service is built around) — then the records entered into the CRM under the label “lead” did not, strictly speaking, meet that definition. They were unevaluated contacts, awaiting an evaluation the process itself treats as necessary.

Under this interpretation, the “AI voice agent” service does not qualify pre-existing leads. In fact, it attempts to determine during the call itself whether they qualify as leads, drawing from a contact list that, according to the company using the service, had not met that definition up to that point.

This has a direct consequence for interpreting any “conversion” metric reported in this context: if lead status is defined retroactively by the outcome of the qualification step itself, the resulting metric describes the success rate of the measurement instrument — not a pre-existing property of the population being measured.

The argument holds even when applied to Model A’s own existing inventory. If a company already owns a contact database — purchased, inherited, or built by conventional means — this article hypothesizes that the company would obtain better results by running an SEO/GEO campaign directed specifically at that same universe of contacts, inviting them to voluntarily declare any problem related to the company’s line of business, through a structured registration mechanism equivalent to Model A’s own seven (example) pre-qualification questions — but completed by the contact’s own decision, not extracted through an unsolicited call.

This is consistent with a broader body of practitioner-oriented literature contrasting inbound and outbound acquisition costs, though that literature has not, to this article’s knowledge, been extended to the specific case of AI-mediated outbound qualification examined here.

Under this reading, Model B is not a complement to Model A for processing new leads: it is a preferable alternative even for re-converting the inventory Model A already holds, replacing interruption with invitation.

This article presents a conceptual comparative framework, not a controlled empirical study.

Quantitatively evaluating the proposed metrics and, in particular, the conversion rate of SHAREICAPP into new registrations, and the predictive value of FEEDBACK2 data on rejected proposals, requires a longitudinal dataset that, given the system’s recent operational deployment, is not yet available with sufficient volume for publication. Building that dataset, and comparing it against conversion metrics reported by Model A systems (also a recent system), is proposed as future work.

We also need to clarify that a strictly quantitative, head-to-head comparison between the two models may itself be premature: each currently optimizes for a different stage of the same funnel, and a fair comparison would need to isolate that stage-specific performance before aggregating it into a single metric.

The hypothesis in Section 6.2 that an inbound re-conversion of Model A’s own contact inventory would outperform an AI Voice Agent’s outbound calling on that same inventory is, at present, a theoretical proposition derived from the IC architecture, not a measured result.

Validating it would require an experimental A/B design on the same underlying database, comparing both treatments; that design is outside this paper’s scope and is proposed as a follow-up study.

The comparison between the two models shows that the relevant question for designing commercial systems is not “how do we qualify the leads we already have, faster?” but “what makes a contact a lead, and who decides that?”

The Integration Coefficient IC does not propose eliminating automation from the qualification stage; it proposes redesigning the entire architecture of demand generation and transfer, letting CRM stop being the input to the sales process and become its output.

It’s worth closing on a consequence of this reasoning that the analyzed case does not itself address.

If, as argued in Section 6.1, Model A’s entry criterion is typology rather than declared need, then the throughput improvement AI Voice agent provides describes the efficiency of processing an inventory of unevaluated contacts — without offering any mechanism to replenish that inventory once exhausted. In that sense, faster qualification solves a downstream problem (processing faster) without touching the upstream one (what criterion a contact enters the system in the first place).

Model B (IC) does not compete with Model A (AI Voice agent) on processing speed; it is not an IC-APP and IC-CHAT vs AI Voice agent competition. IC model tries to answer a fundamental question: whether a system needs to be replenished from the outside through new lists, or generates and evaluates its own demand as part of the very process by which that demand comes to exist.