Your underwriting team has a shortlist of submission intake platforms. Every demo shows a clean screen and a confident walkthrough. Nothing in the demos tells you how to compare the platforms on the same terms.
The gap shows up later. A broker sends a spreadsheet, an MGA sends a structured file, a workbench vendor sends its own format, and each one reaches PolicyCenter in a different state of completeness.
This article gives you a five-check evaluation you can run against every vendor on your list. It covers what the platform must do, how to test each check, how to run a pilot, and how to score the results.
What Should a Submission Intake Platform Do for a Guidewire Carrier?
A submission intake platform receives submissions from brokers, MGAs and other senders, checks that each one is complete, and delivers it into PolicyCenter in the shape underwriters work from. Everything else a vendor shows you supports one of those three jobs.
Define the scope before you open a demo. The sections below separate the two intake routes in the market and the sender types you need to serve.
The Job in Three Parts
Receive, check and deliver. Receiving covers every route a sender uses. Checking covers mandatory fields and valid values. Delivering covers how the data lands in PolicyCenter.
A platform that is strong at one part and silent on another leaves your underwriters to close the gap by hand.
Two Intake Routes: Reading Documents and Receiving Structured Data
Platforms reach a submission in one of two ways. Some read the documents a broker sends, such as emails, ACORD forms and PDFs, and extract fields from them. Others receive structured data that a sender maps once and sends in a defined format.
Both routes are valid, and the right mix depends on who sends to you.
Route | How the data arrives | Fits when |
|---|---|---|
Document reading | Emails, ACORD forms and PDFs are read and fields are extracted | Senders have no system that sends structured data |
Structured data exchange | A sender maps its payload once and sends it in a defined format | Senders are MGAs, TPAs or vendors with their own systems |
Which Senders You Need to Serve
List your senders by type before you score anyone. Your MGAs, TPAs and brokers send submission data into PolicyCenter with very different technical capacity.
Your underwriting workbench vendors send for many brokers at once, and the workbench vendor route into a carrier’s Guidewire instance needs its own test. The sender list becomes your pilot sample later.
What Does the Five-Check Evaluation Cover?
The five-check evaluation scores a platform on channel coverage, mapping and review, the completeness gate, the PolicyCenter handoff, and upkeep. Each check has one question, one thing to ask for in the demo, and one score from 0 to 2.
Run all five against every vendor. A platform that scores well on four and fails the fifth is the one that costs your Guidewire team the most later.
The Five Checks at a Glance
The table below is the whole checklist on one page. Print it and score each vendor in a separate column.
Check | The question to answer | Ask the vendor to show |
|---|---|---|
1. Channel coverage | Does the platform serve every sender type on your list? | A live intake from each sender type |
2. Mapping and review | Who maps each sender’s fields, and who approves the mapping? | A mapping approval record with a named reviewer |
3. Completeness gate | Is incomplete data rejected before an underwriter opens it? | A rejected submission with the gaps listed |
4. PolicyCenter handoff | Does the data land in the fields your underwriters use? | A submission landed in your own PolicyCenter test environment |
5. Upkeep | What happens when a sender or a Guidewire release changes? | A change handled live, with no new build |
How to Score Each Check
Score 2 when the vendor demonstrates the check live on your data. Score 1 when the vendor describes it or shows it on sample data alone. Score 0 when the vendor cannot show it.
A total of 10 is the maximum. Treat any 0 as a stop, whatever the total.
How Do You Test Channel Coverage and Mapping?
Test coverage first, because a platform that cannot reach a sender type has no use for that sender. Then test mapping, because mapping decides whether the data arrives as the sender meant it.
Both checks reward the same habit. Ask for the live example, not the slide.
Check 1: Channel Coverage
Pick one sender from each type on your list and ask the vendor to take a submission from it. Watch how the sender gets set up, how large files are handled, and whether the sender can start without a call to your team.
Ask whether senders onboard themselves through a portal. A platform that needs your engineers for each new sender fails the check, because the carrier ends up writing a connector per partner again.
Check 2: Mapping and Human Review
Mapping matches each field in a sender’s data to the field PolicyCenter expects. Ask who produces the first draft, who approves it, and where the approval is recorded.
A person must review every mapping before it is used. Ask also how the platform handles fields that differ by carrier or by line of business, because your instance is configured differently from the next carrier’s.
How Do You Test the Completeness Gate and the PolicyCenter Handoff?
These two checks decide what your underwriters see. The gate decides what reaches them, and the handoff decides how it looks when it arrives.
Your underwriting operations staff should run both tests, with the integration team beside them.
Check 3: The Completeness Gate
Write down your mandatory fields and valid values for one line of business. Send the vendor a submission that breaks three of them and see what happens.
The right result is a rejection that names each gap and goes back to the sender, before an underwriter opens the file. A platform that accepts the file and flags problems later moves the cleanup onto your team.
Check 4: The PolicyCenter Handoff
Ask the vendor to land a submission in your PolicyCenter test environment and open the record with your underwriters. Check that line, risk and coverage data sit in the fields they use today.
Confirm that the platform delivers submissions into Guidewire PolicyCenter without custom engineering on your side. Then ask which Guidewire releases it supports, since your instance moves three times a year.
If you also receive claims or billing data, ask whether the same layer serves more than one Guidewire application or needs a separate build for each.
How Do You Test Upkeep and Partner Onboarding?
Upkeep is the check that vendors skip in demos, because nothing breaks on demo day. It decides your cost in year two, when senders change their formats and Guidewire ships a release.
Ask for evidence of change handled, not a promise.
Check 5: What Happens When Something Changes
Ask the vendor to change a sender’s payload during the demo and show what the platform does. Then ask the same question for a Guidewire release.
A good answer names who is notified, who reviews the change, and how long the sender keeps sending in the meantime. A weak answer sends the work back to your Guidewire team.
Build, Buy and Who Maintains It
Every platform you evaluate competes with a connector built in-house. Compare the two on ownership, using what maintaining a Guidewire connector involves as the baseline for the build option.
For each option, name the person who owns the integration when a sender changes and when the developer who built it leaves.
Where the Platform Runs
Ask where the platform runs and what your team provides to host it. The infrastructure a carrier needs to run an integration gateway in house is a fair list to hold each vendor against.
Your architects should also read why carriers run an integration gateway inside their own environment before the vendor calls begin.
How Should You Run the Pilot and Score the Shortlist?
A pilot on your own submissions settles what a demo cannot. Run the same files through every vendor on the shortlist and score them with the five checks.
Vendor-reported results do not replace this step. Your files, your fields and your PolicyCenter configuration are the test.
Build the Pilot Sample
Take real submissions from each sender type on your list and cover at least two lines of business. Include a few that are incomplete on purpose, so Check 3 has material to work on.
Give every vendor the same set. Different samples produce scores you cannot compare.
Score the Shortlist
Use the 0 to 2 scale from the table and add the results. Hold the vendors to the scores you saw live, not the scores they described.
Then review the stops. A vendor with a 0 on any check needs a written answer before it stays on the list.
Red Flags to Watch For
Some answers in a demo signal a check that will fail later. The table lists the common ones.
What you hear | What it signals |
|---|---|
“Your team writes the mapping rules” | Check 2 fails, and the work lands on your engineers |
“Incomplete files are flagged for review” | Check 3 fails, because the file still reaches an underwriter |
“We support the latest release” with no process described | Check 5 fails, because upkeep is unplanned |
“Each new sender needs a short project” | Check 1 fails, because every partner becomes a build |
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving sender data into Guidewire. Yazh (Yaal), the InsOps Integration Gateway, is a data exchange platform. A sender maps its payload once, and Yazh translates it to your Guidewire format. LiLa, our insurance-trained LLM, assists the mapping, and a person reviews every mapping before it is used.
Yazh delivers inbound data into PolicyCenter, ClaimCenter and BillingCenter. Senders use a self-service portal and test in a sandbox before they send real data. Yazh rejects incomplete data, handles changes to a payload or a Guidewire release, accepts large payloads by file location, and applies tenant-specific mapping. Guidewire has its own product called Integration Gateway, which is a developer framework. Yazh adds the portal, the test harness and the sandbox beside it.
Yazh receives structured payloads and does not read emails or PDFs, so score it against the sender types on your list. You can read more about dynamic data exchange for insurance before you start your own scoring.
If you are evaluating how to take submissions from many senders without building a connector for each one, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is insurance submission intake software?
It is software that receives submissions from brokers, MGAs and other senders, checks them for completeness, and passes them to an underwriting system. For a Guidewire carrier, the destination is PolicyCenter.
What criteria should I use to evaluate submission intake vendors?
Use the five checks in this article: channel coverage, mapping and review, the completeness gate, the PolicyCenter handoff, and upkeep. Score each from 0 to 2 on a live demonstration, and treat any 0 as a stop.
What questions should I ask submission intake vendors?
Ask each vendor to show a submission from each of your sender types, a mapping approval record, a rejected incomplete file, a record landed in your PolicyCenter test environment, and a payload change handled live.
How do I compare submission intake vendors effectively?
Give every vendor the same pilot files and the same scorecard. Compare the scores from live demonstrations and set aside scores based on descriptions.
What is the difference between reading documents and receiving structured data?
Document reading extracts fields from emails, ACORD forms and PDFs. Structured data exchange receives a payload that the sender mapped once to a defined format.
What common challenges show up after go-live?
Senders change their formats, Guidewire ships three releases a year, and each new partner needs onboarding. Check 5 and Check 1 test for exactly these.
Which metrics show that an intake platform is working?
Track the share of submissions rejected at the gate, the share of rejected files that return corrected, and the number of new senders onboarded without a new build.
How does Yazh assist with submission intake?
Yazh lets a sender map its payload once and translates it to your Guidewire format. LiLa assists the mapping, and a person reviews every mapping before it is used.