Documentation

Getting started

What a program includes, how onboarding runs, and the shortest path from a conversation to a lead ringing on a desk.

What a program includes

A program is one vertical, one set of filters, one delivery path, and one pacing configuration. You can run several at once, and most buyers do: a Medicare program during the annual enrollment period alongside a final expense program that runs all year. Each program has its own caps, its own filters, and its own reporting, so one can be paused without touching the other.

Everything else comes with it rather than as a tier: pre-delivery filters, consent capture and storage, delivery into your stack, disposition feedback, credits under written criteria, reporting, and a named contact. There is no platform fee and no monthly minimum to start. Pricing is quoted per lead by vertical and varies with the program, the filters you apply, and the volume you commit to; see the pricing page.

How onboarding runs

Onboarding is a conversation rather than a signup form, because a lead program has to match the licenses, the staffing, and the hours you actually have. We ask for four things: the vertical and program you want, the states and counties your agents are appointed in, the daily volume your floor can genuinely work, and where the leads should land.

You leave with a program identifier, delivery credentials for the path you chose, an agreed field mapping, and a test plan. Credentials are issued by a person, not generated from a self-serve page, because a delivery endpoint receives consumer contact data and consent records. See the API reference for what the credentials are and how they are scoped.

Choosing a vertical and a program

Three verticals, and the right one is usually decided by what your agents can already place rather than by what looks interesting. Medicare splits into Advantage, Part D, and Medicare Supplement, and into calendar programs: the annual enrollment period, the Medicare Advantage open enrollment period, year-round special enrollment, and age-in or turning-65 demand. Each of those is a different prospect and a different opening line.

Life insurance splits into term and permanent, with the coverage amount the prospect asked about captured at the form. Final expense captures burial coverage intent with the monthly budget the prospect had in mind, which is the field that decides whether the agent builds to budget or guesses.

Test leads before the first live lead

Every integration is proven with test traffic first. We send sample records through the exact path your live leads will take, carrying the same field names, the same formats, and the same headers, with a flag on the envelope marking them as tests. You confirm they land in the right queue, with the right fields populated, assigned to the right campaign or user.

Test leads are not billed and do not count against a cap. Run them again any time you change something on your side: a CRM field rename, a new routing rule, or a rebuilt endpoint. A five-minute test is cheaper than a morning of leads landing in a table nobody reads.

Go-live checklist

• Test leads arrive at your endpoint and return a 2xx within the response window.
• Every field you care about is mapped and populated, including the consent fields.
• The lead id is stored on your record, because it is the key for every later conversation about that lead.
• Your delivery window matches the hours your agents are actually on the phone.
• Your daily cap matches what the floor can work today, not what you hope to staff.
• Licensing geography is loaded and current, down to the county where it matters.
• Your own disqualifiers are in place, so you are not billed for leads you would never work.
• Someone owns the first dial, and you know how you will measure the time to it. See outcome reporting.
• A disposition path back to us exists, even if it starts as a daily file. See disposition feedback.

Back to contents

Delivery via HTTP post

The default path into any CRM that can accept a request. One post per lead, sent on submission, with a response contract you control.

How HTTP post delivery works

When a prospect submits a form and the record clears every filter, we post it to the HTTPS endpoint you named. One lead, one post, sent within seconds of the submission rather than collected into a nightly batch. Your endpoint answers with a status code that tells us whether you took it.

That is the whole mechanism. There is nothing to install, no agent to run, and no polling loop. If your CRM can expose a URL that accepts a JSON body, it can receive leads; see integrations for the shapes this usually takes.

The request we make

A POST with a JSON body, a content type of application/json, and headers that identify the delivery and let you verify it came from us. The full header and field reference is on the API reference. A live delivery looks like this.

Field mapping

Two ways to do this, and the right one depends on who owns the endpoint. If you control the code behind the URL, take our field names as they are and map them on your side; that keeps the contract stable and means a new field we add is available to you the day it ships.

If the endpoint belongs to a system you cannot change, give us your field names and we post to them, including flattening the nested objects into the dotted or underscored names your system expects. The mapping is agreed at onboarding and proven with test leads before the first live record.

Either way, store lead_id somewhere you can search. It is the key for credits, for consent record requests, for disposition feedback, and for every conversation about a specific lead.

The response contract

Answer with a 200 or a 201 and we treat the lead as delivered. Answer with any other status, or fail to answer inside the response window, and the delivery is treated as failed and enters the retry schedule. A 409 is the one exception: return it when you already hold that lead_id and we record the lead as delivered without retrying.

Answer fast, then do the work. An endpoint that runs enrichment, scoring, and a round trip to a third-party service before replying will time out, be retried while it is still working, and process the same lead twice. Accept the body, return 200, and finish the work out of band. The status codes we act on are listed in full under expected responses.

Retries and failed deliveries

Failed deliveries are retried on a backoff schedule. Retries carry the same lead_id and an incrementing X-Solvedmarketing-Attempt header, so a consumer that keys on the lead id can tell a retry from a new lead without guessing.

If a lead cannot be delivered after the full schedule, it is held rather than discarded, and you are not billed for it. We tell you when a program is failing to deliver rather than letting it quietly stop, because an endpoint that has been returning 500s since Tuesday is a worse problem than any individual lead.

Testing your endpoint

• Confirm the endpoint is reachable over TLS from the public internet, with a complete certificate chain including intermediates.
• Post a sample body from your own machine first, so you know the endpoint works before the network is a variable.
• Ask us for test leads and watch them arrive in the destination queue, not just in a log.
• Deliberately return a 500 for one test and confirm you see the retry arrive with a higher attempt number.
• Post the same test lead id twice and confirm your system does not create two records.
• Check that the consent fields survived your mapping. They are the ones most often dropped.

Back to contents

AgentTech Dialer integration

Native delivery into a dialer campaign, because the sister company that built the dialer is the one delivering the leads.

Why this path is different

AgentTech Dialer and Solved Marketing are both part of Solved Ventures, so delivery into a dialer campaign is a native path rather than an integration project. There is no endpoint to build, no field mapping to agree, and no signature to verify. You name the campaign, we put leads in it, and agents start dialing.

The practical effect is on the clock. The gap between a form submission and a ringing phone is the largest single lever on contact rate, and removing an integration hop removes seconds from it. See speed to dial for why that matters more than it sounds.

Mapping programs to campaigns

One Solved Marketing program maps to one AgentTech campaign. Keep them one to one rather than pooling several programs into a single campaign, because a pooled campaign makes it impossible to read which program is actually producing conversations.

Lead fields arrive on the record the agent sees, so the opening line can reference what the prospect actually asked about rather than a generic script. The lead id travels with the record, which is what lets a disposition find its way back to the right lead.

Dispositions come back automatically

On this path the feedback loop closes itself. Call outcomes recorded in the dialer flow back to us against the originating lead id without anyone exporting a file, which means program tuning starts from real outcomes in the first week rather than the first quarter.

If you deliver into AgentTech but manage outcomes somewhere else, tell us, and we will treat the other system as the source of truth instead. Two conflicting disposition sources is worse than one imperfect one. See disposition feedback.

Calling windows and pacing

Dialer calling windows and our delivery windows are separate controls and both apply. Delivery pacing decides when a lead enters the campaign; the dialer decides when it is legal and sensible to dial. Set them deliberately, because a lead delivered at the edge of a calling window will sit until the next morning and arrive at the agent stale.

The prospect time zone on the lead record is what both should key on, not the time zone of your office. See contact and identity fields.

Back to contents

Filters and disqualifiers

Everything that runs between a form submission and a delivery. A lead that fails one of these is never sent and never billed.

What runs before delivery

Five checks, in order: phone validation, duplicate suppression, licensing geography, age and product fit, and your own disqualifiers. They run before the post goes out, not after, because a lead you have to dispute is a lead your agents have already spent time on.

Filters are settings rather than policy. If one is too tight for your desk, or not tight enough, it is a conversation and a change rather than a contract amendment.

Phone validation

The phone number is checked for line type and reachability before the record is sent, and the result arrives on the payload as phone_type. A number that does not resolve to a reachable line is not delivered.

Line type is useful downstream too. A landline and a mobile deserve different dial cadences and different expectations about when someone will answer, and a dialer that treats them identically wastes attempts on both.

Duplicate suppression

Duplicates are suppressed across programs and across time, not just within a single campaign. The same person filling out two different offers in the same week is one lead, not two, and a prospect you already bought does not come back to you later wearing a different program name.

This is a different thing from exclusivity, and both apply. Exclusivity means the record is never sold to a second buyer. Duplicate suppression means you are not sold the same person twice. See the exclusivity policy.

Licensing geography

Leads are filtered to the states, and where it matters the counties, your agents are actually appointed in. Keeping that list current is the one piece of housekeeping worth doing on your side, because an out-of-date licensing map is the most common cause of a lead that looks wrong on arrival.

Medicare plan availability is frequently county-level, so a state-level filter is not enough for a Medicare Advantage program. County is on every record for exactly this reason.

Age and product fit

A 52-year-old asking about Medicare is not a Medicare lead and is not billed as one. Age and product fit rules are per program: a turning-65 program has a tight age band, a special enrollment program has a wider one, and a final expense program cares more about the budget band and health flags than about the exact birth year.

Fit rules are the filters most worth revisiting after a month of real dispositions, because your own outcome data is better evidence than any assumption we started with.

Your own disqualifiers

Add the rules your desk has learned the hard way and stop paying for leads you would never work. Common ones: exclude a state your best agent just let lapse, exclude a budget band your carriers cannot serve, exclude prospects already holding coverage when your pitch is a first policy, exclude a county where your appointment is pending.

Send them as plain sentences. We turn them into rules and confirm the logic back to you before anything changes, because a disqualifier that means something slightly different from what you intended quietly removes volume you wanted.

Back to contents

Disposition feedback

The part most lead vendors never close. Send outcomes back and the filters tighten on your traffic specifically.

Why feedback changes the program

Without outcomes, a lead program is tuned on proxies: form completion, field quality, and complaints. With outcomes, it is tuned on what actually happened when your agents called. Those two produce different programs, and the second one is the one you want.

This is also the honest self-interest argument. Our sister companies sell on these leads, so a program that produces contacts rather than records is our problem too. Feedback is how that gets measured rather than asserted.

The disposition set

Keep it small enough that agents use it consistently. The set we work from is: contacted, not contacted after the full dial cadence, wrong number, not interested, appointment set, application started, application submitted, policy issued, and do not call. A timestamp and an attempt count alongside each one is worth more than a finer taxonomy nobody applies the same way twice.

If your CRM already has its own set, send yours and we map it once. Changing an agent workflow to match a vendor taxonomy is a bad trade.

How to send dispositions

Three ways, in order of preference. Natively, if you deliver into AgentTech Dialer or Solved Enroll, in which case it is automatic. Over the API, by posting outcomes against the lead id; see posting dispositions. Or as a scheduled file, if that is genuinely all your stack can do.

A daily file beats nothing by a wide margin. Do not let the perfect integration stop the feedback loop from existing.

What we do with them

Dispositions feed filter tuning, source weighting, and program comparison on your traffic specifically rather than in aggregate across all buyers. If one channel produces records that reliably do not answer your phones, we can weight away from it for your program without waiting for it to show up as a complaint.

They also change how credits are handled. A pattern of one outcome on one program is evidence about the program, which is a more useful thing to fix than the individual records. See pattern review.

Back to contents

Reporting and exports

You should be able to compute your own cost per acquisition without asking us for a spreadsheet.

Delivery reporting

Every lead, when it was sent, which program it came from, how many attempts the delivery took, and what your endpoint answered. This is the record that settles a question about whether a lead was delivered, and it is available over the API as well as in your reporting view; see delivery reports.

Reconcile it against your own inbound log once during onboarding and once a month afterward. Silent mapping drift on your side is invisible until you compare counts.

Outcome reporting

Once dispositions are flowing, reporting can show contact rate, appointment rate, and issued policies by program and by day. The number worth instrumenting first is not any of those; it is the time between delivered_at and your first dial attempt, because it moves all of them.

Measure that distribution rather than its average. An average of four minutes made of half the leads at thirty seconds and half at eight minutes is two different programs sharing a report.

Comparing programs

Compare programs on cost per acquisition, never on cost per lead. A program with a higher price per record and a better contact rate can be the cheaper program by a wide margin, and the only way to see that is to carry the outcome all the way to an issued policy.

Hold the other variables still while you compare. Same agents, same script, same hours, same cadence. Changing the lead source and the pitch in the same week produces a result you cannot attribute.

Exports

Pull the raw records into your own warehouse rather than living inside a reporting view you do not control. Records can be queried over the API by date range and program, or delivered as a scheduled export to an endpoint you name.

Load on the delivery window rather than on the file timestamp, so a late arriving record lands in the period its lead actually belongs to and your month-over-month arithmetic stays correct.

Computing your own cost per acquisition

Take the leads delivered in a period for one program, subtract anything credited, multiply by your program rate, and divide by the policies issued from that cohort. Attribute to the cohort the lead belongs to rather than to the month the policy issued, or a good cohort with a long sales cycle will look like a bad one.

Then look at the same number a quarter later including persistency. A cheaper acquisition that does not stay on the books is not cheaper, and it is the arithmetic that separates a lead source that works from one that only looks like it does.

Back to contents