Book Importer: the bet
What it is, what it costs, what it unlocks, and what we need to decide
What it is, what it costs, what it unlocks, and what we need to decide
Every prospect we win has to get their existing book into Plansight, and we are not starting from nothing. The plan builder already does this well: a user uploads plan documents, Plansight reads them and verifies what it found. What we do not have is throughput. It works a plan at a time, and a book is thousands of plans. The Book Importer is that same proven capability pointed at a whole block of business in one process, which turns our most-cited objection into a reason to pick us.
Why this is live right now
Baldwin put the objection in writing before the finalist: "strong integrations and modeling but requires extensive setup and maintenance." On August 9, three days after the presentation, Laura Wieners wrote asking for exactly one thing: "the deep dive details of implementation, specifically how we get our data into your system with the least amount of lift on our teams." This plan is the answer to that email, and the call is being scheduled this week.
One pipeline, several source adapters, sold as a service.
A document library, an agency management system, spreadsheets.
The pile sorts itself, then our extraction engine reads it.
Engine existsClaude normalizes everything into one neutral book format.
Live groups and plans, through the path our AI quoting already uses.
ExistsAnything uncertain is reviewed by a person before signoff.
We already read documents well. What we are adding is throughput.
Be precise about this internally, because the sloppy version undersells what we own. Plansight does not make anyone hand key plan data. The plan builder takes uploaded documents, extracts the plan from them, and puts the result in front of a user to verify, with every value traceable to the page it came from. That is a real, working, differentiated capability and it has been in production for years.
The limit is not accuracy and it is not manual entry. The limit is that it runs a plan at a time, and a person has to tell it what each document is first. A user drags documents up and tags them: this employer, this carrier, this line of coverage. Extraction takes it from there. Call it drag and tag.
The technical shape of that limit
The extraction call in V1 takes the plan type as its first argument. The system is told what the document is. Open Plan can determine that for itself, and has been able to for a while, but the product has never had a reason to ask it, so V1 does not call that step at all today.
Drag and tag is fine for one renewal. It does not survive a book. Two thousand employer groups, several lines of coverage each, multiple documents per line, means tens of thousands of individual drag-and-tags. The bottleneck moves from typing to handling, and it is why "we already have AI extraction" has never been a sufficient answer to a conversion question. The answer has to be about volume, not about capability.
A person uploads a document and tags it to an employer and a line of coverage. Plansight extracts the plan and presents it for verification, every value traceable to source. Excellent per plan. Linear in human effort.
Point it at an unsorted pile. It determines what each document is, which carrier and employer it belongs to, which lines it covers, and which pages matter, then runs the same extraction and verification across all of it. Same engine, no tagging, whole book.
Why this makes the ask smaller and the payoff bigger
We are not funding a new extraction engine. We already own that and it is the expensive part. We are funding the classification and conversion layer that lets the engine we own operate on a whole book instead of one document. That is a materially smaller build than it sounds like from the outside, and it is the difference between a feature and a conversion service.
Three choices that make this cheap instead of expensive.
Decided, not open for re-litigation
1. Universal importer, not a point-to-point connector. Every source normalizes into one neutral format, so adding a source is a small adapter rather than a new integration. Building one connector per competitor is a treadmill, which is precisely the argument we make about carrier integrations.
2. Import only, never write-back. Two-way sync is what made BenefitPoint a 324-file, 55,000-line, multi-year effort. A conversion tool does not need it, and refusing it is the single biggest cost control on the project.
3. Open Plan's schema is the canonical layer. Open Plan is the reader we have been teaching for years and it eventually moves into Phoenix. Storing converted books in that schema means that when Phoenix takes over, every book we have converted re-lands there with no re-extraction and no re-purchase of compute. The V1-specific piece is the only part we throw away.
What a customer can do the moment their book lands.
A data migration ends when the data is in. This does not, because we land each employer's plans as a package rather than as loose records. That distinction is the difference between a completed chore and a running workflow.
Plansight already treats a set of plans as a portable, reusable, shareable unit. A bundle of plans can be detached from the employer it came from, kept available to the whole brokerage, and applied to a different account later. So once an employer is converted, that employer is immediately marketing-ready:
The converted plans seed an RFP directly. Out to carriers, quotes back in, presentation produced. No re-entry step between conversion and doing the actual work.
Save the package as a template and apply it to the next employer that looks like it. The work of converting one group pays off on every similar group after it.
Individual plans go into the shared library, named and searchable, available to the whole team and not tied to a plan year. Load once, everyone has it.
We import and export these bundles already. Conversion does not create a one-way door, which is a materially easier thing to sign.
Why this matters commercially
It reframes what we are selling. Not "we will move your data for you," which is a cost centre a buyer tries to minimise, but "your entire book arrives ready to go to market, and every plan you convert stays available to your whole team." The second one is worth paying for, and it is the direct answer to a buyer whose current tooling makes plan reuse an annual re-entry exercise.
Pre-spike estimates. These get replaced with measured numbers before any pricing decision.
The cost structure works because conversions are overnight batch jobs, which qualifies the entire workload for batch pricing, and because the same field specification repeats on every group in a book, which makes caching enormously effective. The pricing principle is to charge on the labor replaced, not on tokens consumed. Any labor-anchored price leaves a very large margin.
Do not take these numbers to a customer yet
They are calculated from current model pricing, not measured from a real run. The spike produces the real figure, and it must be measured on one genuinely messy book before it informs a price. Our internal demo document kit is tuned for extraction and will flatter both accuracy and cost.
Demoable in weeks, production-grade in about a quarter.
| When | Milestone | Gate |
|---|---|---|
| Now | Spike: documents in, converted book out, real cost measured | No blockers. Buildable today. |
| After the spike | Pricing conversation, informed by measured cost on a messy book | Needs the spike number |
| ~October | Phases 1 and 2 in progress: book inventory, then rates | Engineering capacity |
| End of Q4 2026 | Production-grade conversion tool | Phase 3 review UI complete |
| January 2027 | First prospects converted into production | Aligns with Baldwin's February go-live target |
| Risk | Exposure | Mitigation |
|---|---|---|
| AMS API access | Applications register inside the customer's own Zywave admin. There is no vendor-side self-serve path. | The document path needs nothing from Zywave. It is deliberately the first build, which makes the whole project independent of that negotiation. |
| Accuracy on a messy book | Real customer documents are worse than our demo kit. | Review queue plus a hand-verified golden set per line of coverage before any tenant is declared converted. |
| Cost overrun per group | Estimates are calculated, not measured. | Open Plan reports per-call cost telemetry, so the spike measures the full pipeline rather than guessing. |
| Build-it-in-V1 pushback | Roster hit this and the pushback won. | Recommend an external service first with one small V1 endpoint, and cite the Roster precedent up front rather than being surprised by it. |
Mapping to Weston's sequence: get the details, then the numbers, then call a plan.
On Laura's implementation call, we need to learn where their plan data actually lives, which systems of record they run, roughly how many employer groups, and who owns the document library. The client-facing page is built to run that conversation and ends with exactly those questions.
No external dependencies and no Zywave involvement. It produces the sales demo, the measured cost-per-group figure, and the golden set we verify against from then on.
The pricing conversation should happen after the spike returns a real number, validated on one messy book. The framing to bring is labor replaced, not compute consumed.
Whether Baldwin or anyone else in the book runs BrokerageBuilder, who the first conversion tenant should be, and whose document library holds the plan documents.
Status: research, mapping, and build plan are complete and verified against source. No code is written yet. The document path has no blockers. The agency management system adapter is blocked on tenant access, which is a business step rather than an engineering one.
Working documents live in the Plansight Brain vault under BrokerageBuilder Integration/.
Engineering detail is on the engineering version of this page.