// Policy servicing automation
A resolved conversation is not a resolved policy.
An ID card for a lienholder, an address change, a vehicle added, a payment date moved, a coverage question three days before renewal. Small tasks, relentless volume. Answering the customer correctly and leaving PolicyCenter untouched is an unfinished job that comes back next week.
Dearborn Labs is an AI-native software development firm built specifically for insurance. There is no Dearborn Labs product in this — you hire the engineers, and your servicing team owns the workflows afterward.
// The situation
The people who absorb servicing volume are leaving.
The servicing bench is retiring faster than it is being replaced, and the market for replacements is tight.
Servicing is where the shortfall lands first, because servicing headcount scales with the book and nothing about a renewal cycle waits for a hiring cycle. So the first exercise is a contact census: every inbound interaction for a full month, classified by subject and by whether the job it asked for could be completed in the system of record at all. That census, not a containment target, is what decides the scope.
// The stack you actually run
Channels, systems, and the transactions underneath them.
Two structural facts that decide whether this works.
Most servicing contacts are transactions rather than questions. A correct answer that does not change the policy record is a resolved conversation and an unfinished job, and it returns as a second contact that most dashboards will count as new demand. So the build is organized around completing the transaction in the system of record, effective-dated, with the audit-trail entry an examination would later read — and anything it cannot complete there is routed rather than answered.
And the channel mix moves. Volume shifts toward self-service and chat as transactions become completable there, so measurement has to be defined per contact and per subject rather than per channel. Measure by channel and a migration reads as an improvement.
// The build
Four builds. The fourth makes the number honest.
Intent resolution against the policy record
An inbound contact resolved to a customer, a policy, a term and an intent before anything is generated. Most errors in servicing are not language errors. They are identity and term errors: a correct answer about the wrong term, the wrong vehicle or a policy that lapsed in March.
Surface: the servicing channels joined to the policy system of record before any response is composed.
Transaction execution with write-back
An address change, a lienholder update, a payment-date change or a document reissue written into the policy record, effective-dated, with the audit-trail entry attached. Reading the record is straightforward. Writing to it — through the versioned API, inside your change-control calendar, so it survives the next endorsement — is where the engineering time goes.
Surface: the policy system's write path, versioned, with effective dating respected.
An enumerated boundary, per state and per product
The system is allowed to complete a fixed, enumerated list of transactions checked against the filed rules for each state and product. The enumeration is a configuration file your compliance function can read, not a model behavior. Everything outside it routes to a person with the conversation, the policy context, the state and the governing requirement attached.
Surface: the filed rules and notice requirements as a reviewable configuration, with the ticketing queue as the fallback path.
The measurement layer, built first and kept separate
Contact counting, resolution, reopen and correction instrumented independently of the system doing the work, because a system that scores itself will always score well. Built before the automation ships, which is the only way there is a before-and-after at all.
Surface: the event stream from every channel, plus the ticketing and policy records.
What we measure, and what the words have to mean
A contact is one inbound customer-initiated interaction on any channel, counted once; a retry inside the same session is not a second contact. Resolved with no human means no employee touched the contact and the transaction the customer asked for completed in the system of record. Reopen means a further contact from the same customer on the same subject inside a defined window, and a reopen retrospectively cancels the resolution it followed. Correction rate is the share of completed transactions later amended by a person. Those four definitions do more work than any percentage, because a containment figure quoted without its reopen window and its correction rate is not comparable to anything, including its own previous quarter.
// We ran one of these
The servicing build we ran inside our own carrier.
That is Clearcover’s operating result, on the four definitions above — our own record as operators, not a client outcome and not a forecast of yours.
Clearcover · verified July 2026.
It is the only number on this page, and the least useful part of it. What transfers to another book is the definition work, the enumerated boundary and the failure modes. The percentage is set by your own transaction mix, which is a baseline exercise rather than a benchmark.
// We ran one of these
Containment and transaction counts are defined before they are reported, because a servicing number nobody can reconstruct is a number nobody trusts.
The operating record →// What's hard about this
Two limits, and what we do about each.
Containment measured at the contact level rewards deflection.
A contact closed without a person that produces a phone call two days later was never resolved, but it counts as resolved on almost every dashboard this industry uses. The incentive that creates is to end conversations rather than finish jobs.
The answer is structural rather than cultural. Resolution carries a reopen window, reopens cancel the resolution they follow, and containment is never published without the reopen rate and the correction rate beside it. The instrumentation sits outside the servicing system so it cannot be tuned by the thing it is grading.
Servicing runs on regulated artifacts, so a confident wrong answer is a filing problem.
A cancellation, a reinstatement, a coverage change or a document reissue carries state-specific notice requirements and effective-dating semantics. Getting one wrong is a regulatory event rather than a bad review, and the exposure scales with the automation.
So the transactions the system may complete are enumerated against the filed rules for each state and each product, the enumeration is a configuration artifact rather than a model behavior, and anything outside it routes to a person with the state and the governing requirement attached. The boundary starts narrow and widens on evidence, one transaction type at a time, with the correction rate on the last widening as the gate for the next.
// What ships with it
The governance file, for a policyholder-facing system.
A model inventory entry with a risk tier, transcript and decision retention, the enumerated transaction boundary as a reviewable artifact, drift thresholds with remediation triggers, and a human-override specification naming who can act outside the boundary. Roughly half the states have adopted the NAIC AI Model Bulletin and a customer-facing servicing system sits squarely inside it; Connecticut requires an annual AI compliance certification attested by a named officer.
NAIC and state bulletins · current at September 2026.
What the governance file contains →Bring us one month of contacts.
We will tell you which contacts could never have completed in the policy record at all.