Short answer: trace each claimed result from the missed call to the completed job, then use a separate randomized holdout to test whether the recovery workflow created lift. If a vendor cannot show both using your records, it has not proved incremental revenue.
Calls answered, conversations connected, and appointments booked are useful operating signals. They are not revenue proof. The buyer's question is simpler: what completed work happened because this system intervened, and can I audit every claimed job?
This guide gives residential HVAC contractors a practical audit for weak attribution, vague measurement, and invoices that cannot be reconciled.
The evaluation standard
>
- Attribution establishes which completed jobs can be claimed.
- A holdout tests whether the workflow caused incremental lift.
- The event log shows what the system actually did.
- Every claimed outcome must survive a record-level audit.
Why “appointments booked” is not proof
Imagine a system recovers a missed call and schedules a visit. That is progress, but several things can still happen:
- the homeowner cancels;
- the booking duplicates work already in the schedule;
- the caller would have returned without intervention;
- the job never reaches completion; or
- the completed job cannot be linked reliably to the original missed call.
The honest unit is therefore not an answer, a conversation, or a booking. It is an
attributed recovered completed job.
Keep the states separate in your ledger:
Eligible missed call → recovery attempt → connected conversation → approved booking → completed job → recorded job value
If a link is missing, label the outcome unresolved. Do not turn a gap into revenue by assumption. The homepage's proof section shows the difference between the machine-event receipt and the completed-job ledger.
Attribution comes before measurement
Attribution answers a record-level question: which completed job came from which eligible missed call?
For every claimed job, ask to see:
- the source call identifier and timestamp;
- the recovery attempt and connection outcome;
- the approved booking;
- the completed-job record in your operating system;
- the value and gross profit recorded for that completed job; and
- the rule used to resolve repeat callers, duplicates, cancellations, and disputes.
That chain should be inspectable without trusting a summary dashboard. A vendor should not invoice from a booking count while waiting for completed-job truth to catch up.
A holdout answers a different question
A holdout tests causality. Start with eligible missed calls, exclude emergency and safety-sensitive calls, then randomly assign a small control before the recovery workflow begins. Work the recovery arm and leave the control arm to the contractor's normal missed-call path. After outcomes mature, compare completed jobs under a prespecified method.
The difference estimates incremental lift. It does not decide which individual job belongs on an invoice.
That separation matters:
- Attribution connects a recovered job to its source.
- The holdout tests whether the workflow caused lift.
- The event receipt proves what the system did.
- The completed-job record supplies the business outcome.
Emergency and safety-sensitive calls must be excluded before randomization and worked immediately under the contractor's approved routing rules. A vendor that cannot show where that exclusion occurs has not shown an acceptable holdout design.
Read how Vectrion measures caused lift and the measurement policy before comparing designs.
Pricing should follow the evidence
“Performance based” should describe inspectable economics, not marketing posture.
Vectrion has two contract tracks:
- Founding Cohort is a flat arrangement and never includes a performance share.
- Standard uses a base plus a share of the gross profit Vectrion proves it recovered, never a share of revenue.
The contractor keeps every dollar above what it pays Vectrion. Exact figures are reviewed privately because service, replacement, and install mix change gross profit.
The useful buyer question is not whether a public price looks cheap. It is whether the agreement makes the calculation reproducible from completed-job records. Read the number-free pricing model and the Founding Cohort path before the call.
Questions to ask any AI phone vendor
“Can you trace one claimed completed job back to the exact missed call?”
Ask for the call record, recovery event, approved booking, completed-job record, and recorded value. If the chain breaks, attribution is not proven.
“What proves caused lift?”
The answer should explain the holdout, eligible population, exclusions, outcome source, and analysis plan. A dashboard total is not a causal design.
“How are emergencies excluded before holdout assignment?”
The exclusion should happen before randomization, not after a report is generated. Ask for the decision rule and the audit record.
“What does your event log show?”
Ask which machine events exist, what timestamps they carry, and how the vendor distinguishes its own test traffic from real customer traffic. A promise is not a log file.
“How do I dispute a job?”
The process should cover duplicates, existing opportunities, cancellations, incomplete work, refunds, source ambiguity, and corrections. Evidence—not vendor discretion—should decide the outcome.
“Which capabilities are live today?”
Ask the vendor to separate production behavior from roadmap language. Integrations, routing, memory, and safety claims should each have a current runtime proof.
Audit your own recoverable ceiling
Use your records, not a borrowed industry average. Pull:
- inbound call logs;
- eligible missed calls by daypart;
- connected recovery outcomes;
- approved bookings;
- completed jobs;
- recorded job value and gross profit; and
- refunds, cancellations, duplicates, and unresolved records.
Build a conservative range rather than one precise promise. Keep missed-call recovery separate from later expansion pools such as after-hours overflow, unsold estimates, and lapsed-customer reactivation. Those pools need their own eligibility, attribution, and consent rules.
Start with the Vectrion application, then use the homepage FAQ to pressure-test the vendor's answers.
Frequently asked questions
What proves an AI answering service made money?
A traceable chain from an eligible missed call to a recovery event, an approved booking, a completed job, and the value recorded in the contractor's system. A separate randomized holdout then tests whether the recovery workflow caused incremental lift.
Is an appointment booked the same as recovered revenue?
No. A booking can cancel, fail to complete, duplicate an existing opportunity, or lack a reliable source link. Revenue proof waits for the completed job and an attribution chain that survives review.
What is a measurement holdout?
A holdout is a small randomized control drawn from the same eligible missed-call stream. Comparing completed-job outcomes for worked and held calls helps distinguish caused lift from jobs that likely would have happened anyway.
Does a measurement holdout include emergency calls?
No. Emergency and safety-sensitive calls are excluded before assignment and follow the contractor's approved routing rules immediately.
How does Vectrion pricing work?
Founding Cohort is a flat arrangement with no performance share. Standard uses a base plus a share of the gross profit Vectrion proves it recovered, never a share of revenue. Exact figures are reviewed privately because job mix changes the economics.
What should I ask an AI phone vendor before signing?
Ask for the event chain, completed-job source, holdout design, emergency exclusions, dispute rules, and own-test disclosure. Then ask which integrations and routing behaviors are live today rather than planned.
The buyer's rule
Do not ask an AI answering service to show you how busy it was. Ask it to show you which completed jobs it can prove, whether the recovery workflow created lift, and whether each claim can be rebuilt from your records.
Use these questions on Vectrion AI too. Proof should survive the same audit no matter whose logo is on the report.
Related reading: