A group underwriting platform is the system a group carrier runs its new business on: cases, plan designs, rating, proposals and the hand-off to installation. A rating engine, inside it or beside it, applies the carrier's manual to a census in the carrier's own layout. Both assume the census is already clean, and neither reads the spreadsheet and RFP letter a broker actually sends. That gap is filled today by a spreadsheet desk in sales support, by a rules-based upload tool, or by agents. Botminds' Group Census & RFP Intake Automation is the third: it sits in front of the platform and hands it a checked, quote-ready census. This page runs one fictional broker census through all three approaches and scores them on the same twelve errors.
The census is the sample case in the solution: Corvane Precision Components, a manufacturer, sent by its broker with a nine-page letter. The file has 440 rows under a merged title, the broker's own headers, an SSN column, 63 problem birth dates, 17 salaries on the wrong basis or set to $1, 22 dependents and 6 duplicates on employee rows, 38 class cells carrying labels the letter does not use, and 7 blank sexes. And it is missing a whole plant.
One census, three ways: what reaches rating
Fixed, sourced: found and fixed with the source or arithmetic shown, accepted by a person. By hand: found and fixed by an analyst, usually without a trail. Flagged: stopped or marked, but someone still has to fix it. Missed: passes into rating.
What is a group underwriting platform?
A group underwriting platform is the case system for group new business and renewals. It typically holds the case and its documents, the plan design library, the rating manual and rating engine, the proposal generator and the workflow that routes a case from sales to underwriting to installation. Its strength is consistency: every case is priced from the same tables and every proposal comes from the same templates.
Its input is the weak point. A platform needs a census in its own layout, with ages, earnings, classes and locations already resolved. Brokers do not send that. Public employers publish what they send, because procurement rules require it: the City of Providence answered bidders' requests for a census with "Please refer to the census posted on the City website", and bidders still had to ask what the file's abbreviations meant (City of Providence, life insurance RFP questions, 2024; the employee census template quotes their full request). Somebody turns that file into the platform's layout. The question is who, and with what trail.
What does a group rating engine do?
A group rating engine applies the carrier's rates to a census: manual rates by age band and plan design, factors for industry, area and size, and, for larger groups, a blend with the group's own claims experience. It produces rates per $1,000 of life volume or per $100 of covered payroll, and the premium those imply. It is arithmetic, done consistently.
It cannot tell whether its input is true. A rating engine given a salary of $27.00 prices it; given a birth date of 01/01/1900 it prices a 127-year-old; given a census with a plant missing it prices the group it was given. The State of Indiana's 2019 group life RFP shows how input differences surface even in a well-run public procurement: a bidder found the basic life volume in the cost proposal, $1,232,225,647.84, did not match the $1,817,691,000 in the historical exhibit, and the state explained that one came from summing the census salaries of enrolled employees (Indiana RFP 19-112, questions and answers). How each census field moves a disability rate is worked in how long term disability rates are calculated.
Do group carriers still use spreadsheets for quoting?
For intake, very often, because the broker's census is a spreadsheet and the fastest tool for an unknown layout is a person with a spreadsheet. The spreadsheet desk's strength is flexibility: an experienced analyst can read any file. Its weakness is what it leaves behind. Fixes are made in place, the file as sent is overwritten or saved as "v3 FINAL", and the reasoning behind each change lives in the analyst's head.
It also tests validity better than accuracy. An analyst converting a birth-date column sees that the values are dates now; whether a two-digit year landed in the right century, or a placeholder date belongs to anyone, needs a second source the analyst may not have open. The statistical framework the federal agencies use calls the risk processing error and lists "data entry, coding, editing, imputation" among its causes (FCSM, A Framework for Data Quality, 2020). Hand cleaning is all four.
The same Corvane file, two ways
Spreadsheet desk: The RFP waits in a shared inbox until an analyst is free.
Agents, with a person accepting: Read on arrival: header found on row 3, 12 columns mapped, SSN column dropped, 183 cells marked by 07:51.
Spreadsheet desk: Converted in place; placeholders and two-digit years look like dates afterwards.
Agents, with a person accepting: 63 suggested fixes, 50 from the current carrier’s billing roster and 13 two-digit years expanded; accepted as a column with each source in view.
Spreadsheet desk: Retyped where they look wrong; the $27.00 row may pass.
Agents, with a person accepting: Seventeen fixes with the working shown, such as $27.00 × 40 × 52 = $56,160.
Spreadsheet desk: Noticed, if at all, when someone compares lives with the letter.
Agents, with a person accepting: Found on arrival: three plants in the letter, ZIPs for two on the file.
Spreadsheet desk: One at a time, as each problem is found.
Agents, with a person accepting: Four points in one message with the evidence attached, sent by the underwriter.
Spreadsheet desk: A clean-looking file, without a list of what changed.
Agents, with a person accepting: The census in the rating layout, plus every change with its source and who accepted it.
Can a rating engine read a broker census?
Not as sent. A rating engine reads its own layout, and a broker's census arrives in the employer's: a merged title across the top, headers such as "DOB", "DOH", "Dept/Class" and "Sched Hrs", sheets per location, and codes that mean something only to the employer's payroll. Indiana's census needed bidders to ask what "Basic Life TaxSaver" and "JUD10K" meant; the answers were a pre-tax deduction status and a judges' class "limited to a basic life benefit of $7,500" (Indiana RFP 19-112). No rating engine resolves a code like that from the data alone.
Some engines accept an upload template, and that is where the second approach comes from: make the broker, or sales support, put the file into the template, and let the rules reject what does not fit.
The rules-based upload: the right checks, at the wrong moment
A rules-based intake tool checks a file against a template and a set of validations: required columns, date formats, age ranges, a salary floor, unique IDs, known relationship codes. That catches most of the twelve errors, which is why its column in the scorecard is mostly flags. But a flag is not a fix. A two-digit year flagged is still a two-digit year; a blank birth date flagged still needs a value from somewhere; a class label rejected still needs someone to decide which class it is. The work is moved back to sales support or to the broker, and the file waits.
Rules also cannot read the letter. Whether the census has as many lives as the letter describes, every location the letter names, and the same plan design as the current carrier's summary are questions about two documents, not one file. Clark County, Washington's 2023 RFP shows why that matters: bidders found "difference between the certificates and the plan summaries", and the county replied that "the certificates were not the most current version" (Clark County RFP 868 questions and answers). No template validation would have seen it.
A platform prices what it is given. The decision that matters happens before: whether what it is given is the group the broker described.
Where agents fit: in front of the platform, not instead of it
Group Census & RFP Intake Automation does the reading and checking the platform cannot, and hands over what the platform expects. Its RFP reader turns the letter into plan design fields, each cited to its page. Its census mapper finds the table and maps every column, by header and by values, to the carrier's rating layout. Its data-quality checker and roster matcher suggest a fix for every cell that would break the rating, and the reconciler compares the file with the letter and the current plan. The underwriter accepts fixes, sends one message to the broker and signs.
What the platform then receives is the clean census in the rating layout, the plan designs as fields, and a case summary: lives by class and location, ages at the effective date, earnings and benefit volumes, readiness checks and every assumption in writing. The rating engine is unchanged. What changes is that its input has a source for every value.
After the broker’s answer, the census tells the same story as the letter
Hours: the same census through each approach
The working hours differ most in the steps a platform never sees. Botminds' estimate, from carrier sales-support practice, puts a hand-cleaned mid-market census at about 20 working hours before any broker wait, and the same work with agents at about 2.6 hours of people's time, mostly accepting fixes and signing. A rules-based upload sits in between and depends on how many flags come back; we have no fair single estimate for it.
Where the working hours go, by hand and with agents
- Mapping3 h
- Dates, salaries, classes8 h
- Dependents, eligibility3 h
- Letter check2 h
- Questions2 h
- Sign-off2 h
- People’s time2.6 h
A named underwriter signs what rating receives
What should a group underwriting platform include?
Whatever platform a carrier runs, the intake in front of it should answer ten questions on the carrier's own files. Ask them of a platform vendor's intake module, a rules-based tool and an agent product alike.
Ten questions for a group underwriting platform and its intake
- Does it read a census in the broker’s layout?
Merged titles, hidden tabs and the employer’s own headers, without a template step.
- Does it read the RFP letter into plan design fields?
Each field tied to the passage it came from.
- Does it compare the census with the letter and the current plan?
Lives, locations, classes and plan designs, before pricing.
- Does it fix, or only flag?
A flag moves the work back to a person; a sourced suggestion lets a person decide in seconds.
- Where does each fix come from?
A roster line, a rule with its arithmetic, or the broker. Never a guess at a rating factor.
- Is the broker’s file kept as sent?
And can any group of changes be undone?
- Who signs the census, and is the meaning recorded?
Including a co-signature above a case size you set.
- Are your rules settings you own?
Rating layout, eligibility hours, salary floor, roster matching, retention, with versions.
- What happens to SSNs and other identifiers?
Dropped on arrival if the quote does not need them.
- Will it run a back-test on last season’s RFPs?
Scored against what your team actually changed.
A six-week plan for that back-test and a parallel run is in AI in group insurance: a six-week go-live, and the field-by-field census layout a platform should expect is in the employee census template.
Questions people ask
What is the difference between a quoting system and census intake?
A quoting system prices a case and produces the proposal from a census in its own layout. Census intake turns the broker's file and letter into that census: mapping, checking, reconciling with the letter and asking the broker. One is arithmetic on clean data; the other decides whether the data is clean.
Does an agent-based intake replace the group underwriting platform?
No. It sits in front of it and hands over a census in the rating layout, the plan designs as fields and a case summary. Rating, proposals and installation stay on the platform the carrier already runs.
Why not make brokers use the carrier's census template?
Brokers quote many carriers at once and send each the employer's export; most will not rebuild it per carrier. Even a template-perfect file can carry placeholder dates, wrong pay bases and a missing location, which only a second source or the letter reveals.
Can a rules-based tool check a census against the RFP letter?
Only if someone first types the letter's lives, locations, classes and plan designs into fields the rules can read, which is most of the reading work. Reading the letter into cited fields is the part an RFP reader agent does on arrival.
How do you choose group underwriting software?
Run your own files through it. Give each candidate a set of last season's RFPs as the brokers sent them, hold back what your team changed, and count what each finds, misses and gets wrong, along with the trail it leaves for every change.