Statement of work · draft for review

Enroll Now: the August build

A 30-day sprint to solve enrollment — an assisted enrollment layer built on top of the platform Enroll Now already has, in front of members before the September 1 window opens.

From Sharemeister To Enroll Now Issued 31 July 2026 Covers 1–31 August 2026

Terms

Twenty thousand, in two payments

Due on receipt

$10,000

Starts the sprint. Discovery into the rules engine begins immediately — it is the long pole and everything else waits behind it.

Due 15 August 2026

$10,000

Mid-sprint. By this date the conversational agent is answering from your own logic rather than from a static script.

Total, August $20,000

Fixed fee for the defined set of tasks in this document. Third-party and metered AI costs are billed to your accounts at cost, with no markup.

How this sits against the wider engagement

The $20,000 is not a draw against the wider engagement, and it is not that engagement in miniature. It buys the specific scope set out below — a first, self-contained step, priced so the work can start immediately rather than waiting on a full negotiation.

It is a down payment of faith on both sides. You get a working agent in front of members before the window opens; we get a starting point and a working relationship. The equity and revenue-share terms travel with this first sprint rather than being held back for later.

The difference between this figure and the engagement value is settled in September, once both parties have seen how the other works. That conversation is expected, not a contingency.

The seam

Your platform keeps the logic. We build the way in.

Enrollment is the problem being solved, and the enrollment platform already exists. Nothing in this sprint rebuilds it. The rules, rates and calculations you have spent years getting right stay exactly where they are — "it's an ugly, ugly, ugly thing to build… we don't have to rebuild that." What is missing is the assisted path into them, and that is all August builds.

Stays in your platform	Built in August, reading from it
Rules and eligibility tables	Questions answered against those rules, never a second copy
Rates, states, premiums, coverages	Cost explained to the member in plain words
Calculations	Results surfaced and narrated, never recomputed
Brochures and plan PDFs	The same documents, delivered as interactive explanation
System of record	Writes back to you; the layer holds nothing of its own
Carrier and product configuration	The shelf a member sees, driven entirely by your config

One direction of truth. If the two ever disagree, your platform is right by construction — because the layer has no independent copy to disagree with.

Three requirements that follow from this, and do not bend

No duplicate rules engine. Every rate, rule and eligibility decision is read live. Nothing is cached into a second system that can drift out of agreement with yours.
You remain the system of record. The enrollment layer writes to your platform and keeps no authoritative store. This is the term you walked away from another vendor over.
Restricted retrieval. Answers come from your own material — your PDFs, brochures and plan documents — and your APIs. Never from a general model's own knowledge.

Position

Enrollment first, and the rest serves it

The four workstreams below are not four products. Enrollment is the deliverable; AI Agents, Call Center and Payroll & Benefits exist in this sprint only so far as enrollment needs them — the agent so a member is not left confused, the call-center pieces so the ones who need a human get one, the payroll rail so the money actually moves. Anything in those three that enrollment does not require is September's problem.

August · sprint one

The load-bearing four

Enrollment · AI Agents · Call Center · Payroll & Benefits — on the member path only, proven on the Advantage package. A lite version by design, not a full platform.

September · sprint two

Widen to the other user types

Employer console, operator tooling and the partner surface. The complex insurance products, additional payroll rails, the diagnostic, and continuous change while the window is enrolling.

October – January

Scale, then hand over

Co-branded partner rails, life-event engine, business intelligence, bilingual parity, then training and handover of an asset you own and can resell.

Scope

What the twenty thousand buys

Four workstreams, each asked for by name in the 31 July session. The sequencing is yours: the wellness package first because it is not an insurance product and carries far fewer questions, then the harder products once the scripting is proven.

EnrollmentThe reason for the sprint

✓

Step-aware enrollment agent on the member surface

She knows which screen the member is standing on and explains that screen, so people stop dropping out at the point of confusion.
"It knows what screen you're on, we can have the script to explain that."
✓

Off-season and new-hire capture

Members arriving outside a window are set up and held ready, so when the window opens the enrollment is one tap with no selling left to do.
"When we get into enroll, it's one tap… you're not even having to sell them."
✓

Voice-to-email-to-click confirmation

Nothing is committed in conversation. A recap email carries one button; the member confirms spelling, sets their own password and ticks their own consents — a timestamped written act rather than a verbal yes.

AI AgentsYours, and answering from your logic

✓

Restricted retrieval against your rules engine

She answers from your APIs — rates, states, premiums, coverages, eligibility — never from a general model's own knowledge. Nothing about your rules gets rebuilt. This is the load-bearing item and everything else waits behind it.
"We're not using ChatGPT to answer a question… that's where the logic is."
✓

Eyes-free mode for drivers

Audio-only operation for members who cannot look at a screen or type — the Ohio Council population of 1,500–2,500. Details are read back and confirmed; anything taken by voice stays provisional until confirmed in writing.
"You're not going to be on your phone… you just have to listen."
✓

Compliance layer

Automated-assistant disclosure, refusal to advise or bind, health disclosures never recorded nor used to steer a plan, and a redacted ledger of every exchange. A licensed agent still reviews and signs every enrollment.
✓

Your instance, documented for handover

You remain the system of record. The module is yours, documented well enough to be resold — stated as a term, not a preference.
"Once this is built, I want to be able to take this module… nobody's built it."

Call CenterDeflect the 70, route the 30

✓

Appointment booking to a licensed agent

"I want to talk to a person" produces a real booked time on your calendar, not an email handoff. Runs on your system, not a third-party scheduler.
"That is big to them… this to them is like so important."
✓

Ticket capture for anything unanswered

When she cannot answer, the question becomes a ticket in your system with the member's context attached, for a human to follow up.
"It's unanswered. It gets to our system. Then somebody can follow up."
✓

Always-available human escalation

A member can ask for a person at any point and get one. The goal is that fewer need to, never that they cannot.
"We could always say agent, agent, agent — I want to talk to somebody."

Payroll & BenefitsThe rail and the shelf

✓

Payroll adapter, first integration

One rail live end to end — the pattern the remaining adapters are then cut from.
✓

Benefits shelf driven by your tables

Products, eligibility, rates and state availability read from the rules engine, so the shelf is never a second copy that can drift out of agreement with yours.
"All of the rules have to be used. This is already there."
✓

Advantage package scripting

Urgent care, telemedicine, prescription drug. Sprint one, because it is a subscription benefit rather than an insurance product.
"A very basic wellness program is easy to sell… that can be done fairly quick."
✓

Documents pulled through the API

Brochures and plan PDFs surfaced as interactive explanation instead of attachments.
"We want to get people off the PDFs if we can."

Traceability

Von's list, in the order he walked it

On the call Von took the page from top to bottom — "these are just some of the things that I would say all the way down." Reconstructed here in his sequence, with where each one lands. Nothing on it has been quietly dropped.

01

The rules already live in tables — don't rebuild them

"Right here is where all the rules and everything is built on tables… it's an ugly, ugly, ugly thing to build. We don't have to rebuild that. This is already there."

August
02

The AI reads your system; it never learns insurance

"All we're wanting you to do is look at the system… you don't have to learn anything. Don't worry about states and premiums and coverages."

August
03

You stay the system of record

"This other company, they've got the experience, but they're not letting us be the system of record. We have to be the system of record."

August
04

The module is yours to sell

"Once this is built, I want to be able to take this module… I can sell this piece to other people because nobody's built it. It's not just a record, but it's ours that we control."

August
05

Restricted retrieval — his term, and he claims it

"I use my term… it has to be restricted retrieval. I don't know what you want to call it — restricted retrieval. In other words, we're not using ChatGPT to answer a question. Using our PDFs… that's what I call it. Has to be that way."

She answers only from your own material — your PDFs, brochures and plan documents — plus your APIs for logic and calculations. Never from a general model's own knowledge. The same documents serve as both the answer corpus and the interactive member content in item 07.

August
06

Pull the logic and the calculations through the API

"You're pulling the APIs from our system, because that's where the logic is. That's where the calculations go, you name it."

August
07

Brochures and PDFs through the same API, turned interactive

"That includes anything down to brochures, any of the PDFs… we want to get people off the PDFs if we can, and get into an interactive."

August
08

Integration between the platforms

"Then we also the integration between the platforms — we have to be able to have that."

August · first rail
09

Security to carrier standard

"The security, I've got security over here that we've got to have. Insurance carriers… SOC 2 is even more restricted."

Penetration testing offered and declined — "I don't do that… this is a closed system, besides the normal security stuff." Baseline posture in August; formal SOC 2 later.

Part
10

Calendar and appointment booking

"'I want to talk to an agent — can I set a time for an appointment?' That is big to them… we won't have to do it on Gmail. It'll be your booking."

August
11

Ticket system for anything unanswered

"If you can't answer it… it's going to go in the ticket. It's unanswered. It gets to our system. Then somebody can follow up. Calendar and ticket system is kind of together."

August
12

Outbound robocall

"That's big to them. Can you do an outbound robocall?" — but also "I hate most of those, they look like spam" and "I'm not working on that."

Carries a per-minute cost when it comes. Deferred at your direction.

Deferred
13

Scales past a handful of concurrent people

"You having two or three people or even more, and we're scaling like 20 people… we're scalable for that."

September
14

Built by people who actually know insurance

"Health insurance people — we gotta know insurance side." On another vendor: "I might as well have been talking Greek when it comes to understanding insurance."

Standing

Reconstructed from the session audio. Item 05 was re-transcribed against the recording to confirm the wording — "restricted retrieval" is his own coinage and is used here as he uses it.

Dependencies

What we need from your side, and when

A layer that reads from your platform cannot be built without access to it. These are the only hard dependencies, and they sit on the critical path — the first week is where a 30-day sprint is won or lost. Everything else we can work around.

Week 1

Sandbox access and API documentation

Read access to rules, rates, eligibility and product configuration, against non-production data. The single largest risk to the September date is this arriving late.
Week 1

A named technical contact who knows the platform

Someone who can answer questions about the rules engine within a day, not a week. You have one developer; we need scheduled access to him, not ad-hoc.
Week 1

Advantage package documents and plan detail

The brochures, plan PDFs and benefit descriptions that become both the answer corpus and the interactive member content.
Week 2

Test member records and a test employer group

Enough realistic data to prove the path end to end before a real member sees it.
Week 2

Write path and its rules

How an enrollment is written back, what validation you enforce, and what a licensed agent must sign before it is active.
Week 3

A licensed agent for the escalation path

A real person and a real calendar behind "I want to talk to somebody", so booking and ticketing can be tested against something live.

Where a dependency slips, the sprint does not stop — we build against a stub and reconcile when access arrives. But stubbed work carries rework risk, and that risk sits with the delay rather than with the build.

Boundaries

Not in August

Named so that nobody discovers the boundary in September. Each is available, and each is priced in the engagement that follows.

The one that matters most

August does not deliver the full Bookah platform across all user types. The finished platform serves four distinct audiences — the member, the employer, the operator or administrator, and the payroll partner — each with its own surface, permissions and workflows. That is the engagement, not the sprint.

What August delivers is a lite version at best: the member enrollment path, proven end to end on the Advantage package, with the four workstreams above standing behind it. Employer console, operator tooling and the partner surface are September and beyond.

This is said plainly here because it is the easiest thing in the engagement to assume otherwise, and because $20,000 buys a first step rather than a platform.

Full platform for all four user types
Employer console
Operator / admin tooling
Payroll partner surface
Outbound robocalls
Deep scripting for the complex insurance products
Payroll adapters beyond the first
Bilingual EN/ES parity
SOC 2 audit
Penetration testing
Realm
Summit

Robocalls and penetration testing were both raised and both set aside by you in session. Realm and Summit were explicitly compartmentalised for later.

Two deliberate departures from the six-month plan

The build comes first; the diagnostic moves to September. As originally written, Month 1 inventories the stack and produces the kill list, with the build sprint following. We have inverted that on purpose, because your primary pain point is the enrollment window and it does not wait. August ships the agent so September 1 can be won.

The diagnostic is not merely postponed. Building against your rules engine in August means we are inside the systems all month — so the technology inventory, the integration map and the early savings signals accumulate as pre-work while we learn the current stack. September's diagnostic starts from evidence rather than from a blank page.

September onward

The engagement this sprint belongs to

Ongoing support from September is to be finalised. The full platform engagement is a six-figure commitment across six months, and the shape of it is already proposed — but none of that is what is being agreed today.

The agreement is this first sprint. Twenty thousand dollars, the scope in this document, and a working enrollment path before the window opens. What September costs, and on what terms, is a conversation both parties will be far better equipped to have once we have built something together.

Where it goes from here

The proposed shape of the six months, for context only. August is re-sequenced as set out above — the build first, the diagnostic following.

01 · AUG
Diagnostic and gate
- Complete technology inventory — systems, vendors, costs, licenses, integrations
- Carrier certification per product: individually issued, 100% insured, no trust wrapper
Output: stack ledger, kill list, annualised savings figure
02 · SEP
Build sprint
- Bookah employee surface live: assessment, explanation, cost, agent sign-off
- Payroll adapter #1 deployed
- Employer console v1 complete
03 · OCT
First payroll partner
- Co-branded rail live with the first partner
- Deduction sync and reconciliation automated
04 · NOV
Scale the rail
- Payroll adapters for iSolved, Asure, PrismHR, Execupay
- Agent-of-record workspace active
- EN/ES bilingual parity; accessibility compliance pass
05 · DEC
Asset visibility
- Life-event engine launches — Bookah active after enrollment, not only during it
- Business intelligence: enrolled lives, revenue per life, channel P&L
- Gig and 1099 pilot opens
06 · JAN
Handover
- Your team trained on the platform; runbooks delivered
- Governance programme transferred; steady-state operations begin

What the diagnostic covers

Against the $60,000 monthly burn, this is the workstream that produces the savings figure.

Inventories	Hunts for savings in
Every system, vendor, annual cost, contract owner	Middlemen on card and ACH processing
Renewal dates and exit clauses	Thin revenue lines carrying high compliance cost
Overlapping tooling and duplicate costs	Duplicate benefits administration tooling
Integration dependencies — files, feeds, SFTP, APIs	Legacy platform features that can be consolidated and retired
PHI and PII data flows, and BAA coverage	Unused seats and auto-renewing licences
Credentials, keys, access controls	High-risk vendors carrying compliance exposure
Licence seats: provisioned against used

The diagnostic does not cut load-bearing infrastructure. Payroll rails and carriers stay exactly as they are; the exercise separates mandatory expense from optional vendor relationship.

Draft for your review — not yet issued to the client. Figures for the six-month engagement are reproduced from the existing Summit Ascent proposal. Dates, names and quoted material come from the 31 July session recording; quotations are from an automated transcript and should be checked against the audio before this is sent.

Nothing here constitutes insurance advice, and no enrollment is created by this document. A licensed, appointed agent reviews and signs every enrollment.