In this article
Use a sample contractor lead to inspect the product before money changes hands, not to predict every future record. A polished example can encourage you to assume that every homeowner will be reachable, suitable, ready to hire, or unique to one source. Those conclusions do not live inside a row of data.
The practical buying rule is to inspect four connected artifacts: a blank schema, a field dictionary, a redacted sample, and the written product definition. Together they can show what arrives, what each value means, and which rules apply. They still cannot predict what a delivered cohort will produce.
Disclosure: theBuildd publishes this guide and sells residential home-improvement leads. The blank schema below is a neutral evaluation tool. It is not a representation of theBuildd’s payload or any other provider’s fields, and this article does not contain customer data.
A sample contractor lead should show structure, not impersonate a customer
You do not need a believable homeowner story to evaluate a data handoff. You need a visible structure and precise definitions. A made-up name, phone number, street address, and project narrative add realism but no purchasing evidence. Worse, they can blur the line between an illustration and an actual inquiry.
A safe sample answers structural questions:
- Which event creates the record?
- Which timestamp marks the original inquiry, and which marks delivery?
- How are trade, project type, and service area represented?
- Which contact channels can be present or absent?
- What identifies the source and the permission event?
- How is distribution described?
- What makes the record billable, reviewable, replaceable, or ineligible for a remedy?
- Can the record enter your CRM without manual interpretation?
It does not answer whether a person will respond, accept an estimate, buy a project, or generate positive economics. Those questions require actual cohorts, a consistent intake process, and a denominator that does not change halfway through the test.
Ask for four artifacts before reviewing one record
One screenshot cannot carry the whole product definition. Ask the seller to provide these four items and reconcile any conflict among them.
| Artifact | What it should show | What it cannot establish by itself |
|---|---|---|
| Blank schema | Field names, hierarchy, required and optional positions | Meanings, allowed values, or delivery performance |
| Field dictionary | Definition, format, valid values, null behavior, and owner for each field | That a future record will be complete or accurate |
| Redacted sample | How a record looks after generation and delivery | Reachability, permission scope, distribution, qualification, or outcomes |
| Written product definition | Billable event, service and territory scope, recipient rule, checks, remedies, and change control | How your team will work the lead or what results it will produce |
The distinction matters because providers sell different products. Networx’s current Pay Per Lead help page says its record can go to as many as four contractors and arrives by text and email. Service Direct’s current Call Lead Manager documentation describes phone-lead fields and controls such as generated time, campaign, caller details, duration, cost, billable status, recordings when enabled, review status, and CSV export. Neither page defines every provider’s handoff.
The sample must be read against the seller’s own written product, not against a generic idea of a “lead.”
Use this illustrative blank sample contractor lead schema
Illustrative blank schema only. It is not customer data, not a fictional lead, and not a statement or promise of the fields delivered by theBuildd or any other provider. Each row is a question to resolve, not a claim that the field will be available.
| Field to ask about | Blank value | Why it matters |
|---|---|---|
| Product or billable event | [provider must define] |
Identifies what the charge purchases |
| Provider record ID | [redacted] |
Supports matching, review, and duplicate checks |
| Source brand or channel | [provider must define] |
Locates the origin at a useful level |
| Original inquiry time | [redacted] |
Starts the age and response timeline |
| Delivery time | [redacted] |
Separates generation from receipt |
| Record age at delivery | [provider must define] |
Shows whether age is supplied or must be derived |
| Trade or service category | [redacted] |
Tests category mapping against accepted work |
| Homeowner-reported request | [redacted] |
Shows whether free text or structured answers arrive |
| Service-location granularity | [redacted] |
Tests territory fit without demanding an unnecessary address in a preview |
| Contact channels available | [provider must define] |
Shows whether phone, email, or another channel can be present |
| Preferred contact method | [not included] |
Makes absence explicit instead of ambiguous |
| Permission or source evidence | [provider must define] |
Identifies what evidence the buyer may retain |
| Provider recipient rule | [provider must define] |
States distribution outside the record itself |
| Provider checks performed | [provider must define] |
Prevents “verified” from remaining an undefined label |
| Contractor qualification status | [not included] |
Keeps provider checks separate from the buyer’s qualifying call |
| Duplicate or remedy evidence | [provider must define] |
Shows what must be retained for review |
| Charge tied to this record | [provider must define] |
Connects the payload to the billing event |
| Export format and schema version | [provider must define] |
Supports CRM mapping and change detection |
Do not score a provider by how many rows it fills. Some information may be irrelevant to the product, unavailable at the inquiry stage, or inappropriate to share in a pre-purchase sample. Score clarity: required versus optional, included versus unavailable, structured versus free text, and fixed versus subject to change.
Read every field as evidence with a boundary
A field proves less than its label suggests. Review it with two columns in mind: what the value demonstrates and what remains unknown.
| Sample element | It can demonstrate | It does not demonstrate |
|---|---|---|
| Record ID | The provider has an identifier format | That two differently formatted records are not duplicates |
| Inquiry timestamp | The system can represent an origin time | That the time is accurate or delivery was prompt |
| Phone or email field | A contact value can be carried | That it works, belongs to the inquirer, or permits your outreach |
| Project category | A label or selection was captured | That the job fits your scope after a conversation |
| ZIP or area | A geographic value is present | That the property is serviceable or the person owns it |
| Source label | The record names an origin | That the source description is complete or substantiated |
| Recipient count | A distribution rule is stated | That the rule was followed for this record |
| “Qualified” status | A label exists | Which checks occurred or whether your sales criteria are met |
| Cost field | A price can attach to the event | Total acquisition cost or downstream return |
Public technical documentation reinforces the point. eLocal’s Call Ping API marks some values required and others optional, and separately documents ZIP, need identifiers, source-origin information, caller ID, question-and-answer arrays, and additional data. Google’s Local Services lead documentation describes multiple events that can count as leads within that ad product. These are useful examples of explicit field and event definitions, not templates that another seller must copy.
If a sales representative says a field means more than the dictionary does, ask for the stronger meaning in the accepted product definition. The FTC’s HomeAdvisor announcement is a useful warning: the agency described allegations involving false, misleading, or unsubstantiated claims about lead quality and source, including readiness-to-hire and direct-source representations. A buyer should record the exact claim rather than upgrading a vague label in their own mind.
Put source and permission evidence beside the record
“Source” should be more than a channel word. Ask what consumer-facing page, form, call flow, or partner path produced the inquiry; what action the person took; what notice appeared; which business or category the action covered; and what evidence is available if the contact is questioned.
The answer may sit outside the delivered payload. That is acceptable if the written product tells you where the evidence lives, how long it remains available, and how a record ID connects to it. What is not acceptable is treating the existence of a phone number as proof of permission.
Do not request extra personal information simply to make the sample feel complete. The FTC’s data-security guidance for businesses recommends inventorying personal information, keeping only what the business needs, protecting what it keeps, disposing of information no longer needed, and planning for incidents. Apply that discipline to sample files:
- Prefer a blank schema and field dictionary first.
- Use a properly redacted record only when structure cannot answer the question.
- Restrict who can download, forward, or import the file.
- Decide where it may be stored and when it will be deleted.
- Never upload a sample containing personal data into an unapproved tool.
That is operational guidance, not a legal determination. Permission, outreach, retention, and security obligations depend on the facts and applicable law; obtain qualified counsel for your process.
Keep distribution, contactability, and qualification separate
Three common inferences break the sample review:
- Distribution is a rule. It states who receives the lead through the provider. It does not show whether the homeowner independently contacted other contractors.
- Contactability is an observed outcome. It depends on supplied details, timing, channel, and your team’s attempts. A populated contact field does not settle it.
- Qualification is a decision. It applies your scope, territory, urgency, budget, authority, and other accepted criteria after contact. A provider label cannot replace undefined criteria.
Write each definition separately. If the product is sold as exclusive, ask for the recipient rule, the point at which allocation occurs, exceptions, source-partner constraints, and the evidence used in a dispute. If the provider performs checks, list each check instead of accepting a broad quality adjective.
Then document what your team still owns. The qualified-lead guide provides the qualifying-call framework; this page only makes sure the handoff gives that team enough information to start.
Map the sample to your CRM and acceptance rules
The best time to discover a mapping problem is before the first paid record arrives. Give the schema to the person who owns intake and have them complete a field map.
| Provider field or event | CRM destination | Required? | Missing-value action | Evidence retained |
|---|---|---|---|---|
| Record ID | ________________ |
Yes / No |
________________ |
________________ |
| Inquiry timestamp | ________________ |
Yes / No |
________________ |
________________ |
| Delivery timestamp | ________________ |
Yes / No |
________________ |
________________ |
| Service category | ________________ |
Yes / No |
________________ |
________________ |
| Territory value | ________________ |
Yes / No |
________________ |
________________ |
| Contact channel | ________________ |
Yes / No |
________________ |
________________ |
| Source or permission reference | ________________ |
Yes / No |
________________ |
________________ |
| Billable or remedy status | ________________ |
Yes / No |
________________ |
________________ |
Resolve format details too. Does time include a time zone? Are categories stable codes or editable labels? Is an empty value different from “not asked,” “not supplied,” and “not applicable”? Can the same identifier arrive through text and email without creating two CRM records? Which raw evidence must remain unchanged if a remedy is requested?
Turn these answers into acceptance rules. A rule should point to the written product definition, not quietly redefine the purchase after delivery. For example, “service category must map to an accepted category code” is auditable. “Lead feels low quality” is not.
Test for schema drift after delivery begins
A sample is a snapshot. The live handoff can change when a provider edits a form, adds a source, renames a category, changes a delivery service, or updates billing and remedy logic. Ask how schema changes are versioned and communicated.
During a bounded test, compare actual delivery with the accepted artifacts:
- Were required fields present?
- Did timestamps and time zones parse correctly?
- Did category and territory values match the dictionary?
- Did duplicate detection work across every delivery channel?
- Could the team retrieve the promised source and remedy evidence?
- Did the billable event match the written definition?
- Did any field, enum, or null state appear that the sample did not describe?
This is a conformance check, not a results claim. Use the lead-generation trial checklist for cohort tracking and the lead-generation contract checklist for product, billing, data, change, and remedy terms. Do not let a clean sample substitute for either process.
Apply the same sample test to theBuildd
The public facts about theBuildd define the commercial handoff at a high level: USA residential home-improvement leads in an agreed trade and ZIP scope, delivered by text and email within 10 minutes. There is one buyer per lead through theBuildd. The homeowner may still seek other quotes independently. Your team contacts and qualifies the homeowner. Records meeting the replacement criteria are replaced rather than refunded, and results are not guaranteed.
Those facts do not define the individual fields in the payload. The illustrative table in this guide is not theBuildd’s actual format and should not be read as one. Before purchase, ask which fields arrive, how they are defined, what source or permission evidence is available, how the record connects to the billable event, and what documentation supports a replacement request.
Review the current plans and terms for the commercial offer. Then contact theBuildd to confirm the trade, ZIP scope, payload, and acceptance rules in writing. If the actual handoff cannot be mapped to your intake process, the sample has done its job: it found the mismatch before the purchase.
Buy the definition, not the polished example
A useful sample contractor lead is deliberately boring. It exposes fields, meanings, missing states, timing, source evidence, distribution rules, charges, remedies, and change control without borrowing credibility from a fictional homeowner.
Make the provider reconcile the blank schema, dictionary, redacted example, and written product definition. Protect any personal information you receive. Map the handoff into the CRM. Then test actual records against the accepted definition and evaluate outcomes at the cohort level. A sample is a procurement instrument, not proof that the next person will answer or buy.