Documentation index

The shared client data model

One description of a person that six companies read and write, and the reason the group is structured around it rather than around six separate customer tables.

Why one record instead of six

In a fragmented chain, the same household exists six times: as a form fill at a lead vendor, as a contact in a dialer, as a prospect in a quoting tool, as an applicant at a carrier, as a commission line in an agency system, and as a policy in a service platform. Each copy is created by a different company, keyed differently, and corrected independently. Within a month they disagree, and no one is wrong enough to be blamed.

Owning the chain lets the group carry one description of a person and pass references to it rather than copies of it. That is not a tidiness argument. It is the reason a fact-find collected to pre-qualify a life case can quote Medicare later without a second interview, and the reason a consent record captured at acquisition is still attached when a compliance question arrives two years on.

The trade is that a shared model has to be governed. A field that means three things to three companies is worse than three fields, so the model is deliberately small at the center and extended per company at the edge. See the core entities.

The core entities

The shared center is short on purpose. Everything else hangs off it as a company-owned extension.

• Person. A natural individual: name, date of birth, residence state, and the identifiers that resolve to them. The residence state matters more than the mailing address, because licensing, product availability, and filing all turn on it.
• Household. The people who buy together. Medicare and final expense decisions are made in pairs far more often than a per-person model expects.
• Contact channel. A phone number, an email address, or a mailing address, each with its own reachability state and its own consent state. A person can have several, and they age at different speeds.
• Consent. The exact disclosure text shown, the timestamp, the source page, and the capture context. Immutable once written.
• Lead. The acquisition event: program, vertical, intent captured, filters applied, and the delivery it produced.
• Client. A person the group is actually working with, rather than one it has merely acquired. This is the boundary where a marketing record becomes a servicing record.
• Health profile. Height, weight, tobacco use, medications, and conditions as answered by the applicant, versioned by the session that collected them.
• Quote. A priced option from one carrier product, tied to the profile version it was priced against.
• Recommendation. A ranked set of quotes with the reasoning that produced the ranking.
• Application. What was submitted, to whom, by which licensed producer, and what came back.
• Policy. The in-force result, with its premium mode, its effective date, and its persistency history.

Note what is not in the center: campaigns, dispositions, agents, hierarchies, carrier rules, commission schedules, and call recordings all belong to a single company and are referenced rather than shared. See tenant and hierarchy boundaries.

Resolving a person across companies

Matching is conservative by design. A confident match merges the working record; an uncertain one creates a candidate link that a human confirms or rejects, and the two records keep operating separately until then. Over-merging two people is much harder to unwind than carrying a duplicate for a week.

The signals used are the ordinary ones: normalized name, date of birth, residence state, and normalized contact channels in E.164 and lowercase. A phone number alone is not a person, because numbers are reassigned and households share them. The match decision and the signals behind it are recorded, so a merge can be explained and reversed.

Consent as a first-class record

Consent is stored as the thing that happened rather than as a boolean. The record carries the exact disclosure language displayed, the timestamp, the originating address, the page, and the program it was captured for. It is written once and never edited, and a later change of mind is a new record rather than an amendment to the old one.

That shape is what makes a consent question answerable years later. The question is never "did they consent", it is "what were they shown, when, and on what page", and only a stored copy of the language answers it. Suppression and opt-out are evaluated against the current state of the channel, before any contact attempt, in every company that can place one.

Versioning and change history

Anything that can be priced against is versioned: the health profile, the carrier rule set, and the recommendation output. A quote references the profile version and the rule set version it was produced from, which is the only way to reconstruct a recommendation after either one has moved.

Corrections are additive. A field is not overwritten in place; a new value is written with its source and its timestamp, and the current value is the newest one. That costs storage and buys the ability to answer what the system knew at the moment a decision was made. See audit readiness.

Back to contents

Identity and access across companies

One person, one identity, and a separate grant of access per company. Shared identity is not shared authorization, and the distinction is the whole design.

One identity, scoped grants

A producer, an agency administrator, or a carrier contact has one identity in the group and a distinct grant of access in each company they are entitled to use. Signing in once is a convenience. Being authorized everywhere is not, and the model deliberately refuses to conflate the two.

Practically: a contracted producer might hold a dialer seat, a quoting platform login, and read access to their own lead delivery reports, and hold nothing at all in telephony administration or in the products company. Each grant is issued, reviewed, and revoked on its own.

Roles and least privilege

Access is granted by role rather than per person, so a role change is one edit instead of a scavenger hunt. Roles are scoped to the smallest unit that makes sense: an agency, a hierarchy branch, a campaign, or a program, rather than to a whole company.

• A producer sees their own clients, their own calls, and their own statements.
• An agency administrator sees their hierarchy branch, and not a sibling branch.
• A support role sees the accounts it is working, with access to regulated content logged.
• An engineering role reaches production data through a reviewed path rather than through a standing grant.
• Administrative roles that can widen someone else access are held by few people and reviewed on a schedule.

Machine credentials

Service-to-service traffic inside the group uses credentials scoped to a company and a purpose, not shared group-wide secrets. A token that can read lead delivery reports cannot read a health profile, and a token issued to a partner cannot reach anything outside the tenant it was issued for.

Credentials are issued per environment, rotated on a schedule, revocable individually, and never embedded in a client application. Partner and carrier credentials come from the individual operating company rather than from the holding company; see APIs across the group.

Tenant and hierarchy boundaries

Every platform in the group is multi-tenant, because every platform has customers outside the group. That is load-bearing for the access model: an external agency on AgentTech Dialer is a tenant exactly like an internal one, so there is no privileged internal path that only works because the caller is family.

Hierarchy adds a second boundary inside a tenant. A downline branch is visible to its own upline and to nobody sideways of it, which is what makes an FMO structure workable without exporting one agency book to another.

Audit logging

Reads and writes against regulated content are logged with the identity, the record, the time, and the grant that permitted it. Recording playback, health profile access, and consent record access are treated as sensitive reads rather than as ordinary queries.

Logs are retained separately from the records they describe and on their own schedule, so shortening a data retention window does not erase the history of who touched the data while it existed. See retention.

Back to contents

Data flows between companies

Six flows carry almost everything that moves between the companies. The diagram above renders the main path; this section describes what each hop actually carries.

Leads into the dialer

Solved Marketing to AgentTech Dialer, on submission rather than on a schedule. The payload carries the lead identifier, the program and vertical, the intent captured, the consent reference, and the filter results, and it lands in a named campaign.

Sending the consent reference rather than a consent flag is the detail that matters. A flag tells a dialer it may call; a reference lets a supervisor see what the person was actually shown. The flow is idempotent on the lead identifier, so a retried delivery does not create a second contact.

Dialer outcomes into enrollment

AgentTech Dialer to Solved Enroll, triggered by a disposition that indicates real interest. This is the promotion described in contact and disposition: the contact becomes a client record, and the call context travels with it so the producer is not starting the conversation over.

What crosses is a reference plus the context needed to continue: the client record, the disposition, the call identifier, and the transcript reference where one exists. Recording media itself does not cross; it is fetched from the company that holds it, under a scoped grant.

Enrollment into carrier submission

Solved Enroll assembles the application, checks producer licensing and appointment state against Solved Solutions, and submits or hands off the packet depending on what the carrier accepts. The response comes back onto the application record, including a decline and its reason where one is given.

A decline is a routing event rather than a dead end. The comparative model already evaluated the case against other carriers and products, so the next option is known rather than researched. That is the practical argument for comparative rather than sequential evaluation.

Commission and settlement records

Solved Solutions holds hierarchy, levels, advances versus as-earned, and statement reconciliation, and it is the company that reconciles a commission event against a placed policy. Other companies read appointment and hierarchy state from it rather than keeping their own copy.

Inter-company settlement is separate from producer commission and is kept that way deliberately. Each operating company is expected to carry its own weight on its own customers, so the flows that bill one company for another company service are ordinary invoices rather than internal accounting fictions.

Records into the warehouse

Every company lands its own records in a shared analytical store on a schedule, in complete files per window, so a late-arriving record appears in the window its event closed in. This is the only place where data from all six companies sits together, and it is read-only and governed as such.

Health detail is minimized on the way in. The warehouse needs to know that a case was quoted, ranked, submitted, and placed or declined; it does not need the underlying medical answers to compute any of the group operating numbers.

The feedback path back to acquisition

The flow that makes vertical integration worth the cost runs backward. Placement rates, decline reasons, and persistency on business that was actually written are fed back to Solved Marketing at the program and filter level, so acquisition is tuned against what stayed on the books rather than against what answered the phone.

In a rented chain this loop is either missing or delayed by a quarter and three vendor contracts. Owning both ends is what shortens it, and a shorter loop is most of the reason the three levers in the strategy compound instead of merely adding up.

Back to contents