Cutting commercial broker paperwork from 11 forms to 1 flow

Picture a mid-market US commercial broker, with books spanning trucking, manufacturing, contractors, and a long tail of small commercial. The team handles the core ACORD applications plus carrier-specific supplemental questionnaires. In the illustrative packet below, eleven forms move together when a new account binds, and the same eleven move again at renewal with last year's data refreshed.

At some point the back-office team cannot grow in proportion to the book. The brokerage is hiring producers, not form-fillers. The alternative to adding people is to collapse the eleven forms into one workflow with shared fields and let the workflow assemble the packet. This post is about that move.

The eleven-form packet, briefly

The exact packet varies by account. Consider an illustrative 11-document commercial renewal packet:

• ACORD 125: Commercial Insurance Application (the core)
• ACORD 126: Commercial General Liability section
• ACORD 140: Property section
• ACORD 130: Workers Compensation
• ACORD 127: Business Auto section
• ACORD 25: Certificate of Liability Insurance for additional insureds
• A carrier-specific supplemental questionnaire (often two)
• A loss-runs request authorization
• A premium financing application (if the account finances)
• A broker of record letter (if mid-term move)
• A summary cover letter for the underwriter

Now look at what these forms share. The insured's legal entity name appears on every one of them. The federal tax id appears on most. The mailing address appears on all of them. The years in business, the operations description, the prior loss-runs reference, the producer name and license, the carrier code: all of these are shared across the packet.

Where each form is filled on its own, the account rep types the insured name once per form: eleven times in this packet.

Where the time goes

A renewal packet built by hand breaks down into four kinds of work:

• Pulling up last year's submission from the AMS.
• Filling the eleven forms: copy-pasting the shared fields, looking up the producer license per state, switching between PDF tabs.
• Assembling the packet in the right order, writing the cover letter, naming files for the underwriter's preferred convention.
• Uploading to the carrier's submission portal and confirming receipt.

The form filling and the assembly in the middle are the part a workflow can take over. The first and last steps are work with people and systems outside the forms, and they stay.

In this packet, the insured's legal name appears on all eleven forms. Typing it once, instead of once per form, is the first thing to fix.

What the workflow looks like

The shift is from eleven templates to one workflow with eleven document includes. The workflow holds the shared fields once. The templates hold the form-specific fields. When the workflow runs, the shared fields are mapped 1:N into every included template, and the right addenda are included by rule.

curl -X POST "https://api.mezdoc.com/api/v1/workflows/commercial_renewal_v4/runs" \
  -H "Authorization: Bearer $MEZDOC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data": {
      "insured_legal_name":    "Northstar Logistics LLC",
      "insured_dba":           "Northstar Logistics",
      "insured_fein":          "12-3456789",
      "insured_address":       "412 Industrial Pkwy, Houston TX 77002",
      "years_in_business":     11,
      "operations":            "Long-haul trucking, dry van, contiguous 48 states",
      "producer_name":         "Anchor Risk Advisors",
      "producer_license_state":"TX",
      "producer_license_no":   "TX-1234567",
      "lines_requested":       ["GL", "Property", "Auto", "WC"],
      "current_carrier":       "Pinnacle Commercial",
      "current_policy_expires":"2026-06-30",
      "premium_financing":     true,
      "wc_class_codes":        ["7228", "7229"]
    }
  }'

On that one call, the workflow assembles the packet:

• ACORD 125 with the shared fields filled.
• ACORD 126 (GL) because the lines include GL.
• ACORD 140 (Property) because the lines include Property.
• ACORD 127 (Auto) because the lines include Auto.
• ACORD 130 (WC) because the lines include WC.
• The carrier-specific trucking supplemental because operations mention trucking.
• The loss-runs request authorization, pre-populated with the current carrier.
• The premium financing application, included because the flag is true.
• The cover letter, dynamically composed with the lines, the current carrier, and the renewal date.

The workflow returns one merged packet PDF for the underwriter and each document as its own PDF for the file. The form filling becomes one API call.

The four moves that make this work

Workflow-level shared fields

The insured's legal name lives on the workflow run, not on any specific template. Every template that includes the alias `insured_legal_name` gets the value. When the rep needs to correct a typo, they correct it once and run the workflow again, and every document picks up the fix. They do not chase the typo across eleven PDFs.

Per-document include rules

The ACORD 130 (WC) is included when the lines requested include WC. The premium financing addendum is included when the flag is set. The state-specific supplemental is included by state. These rules live on the workflow, not on the templates. A new state adds one rule.

Per-template version pinning

When ACORD releases a new edition of the 125, the brokerage publishes v6 of the ACORD 125 template, tests it on staging against a representative sample of accounts, and publishes it to production. Each workflow run records the workflow version it ran, and that version records the template version of every document in it, so an audit later can show which form revision a particular renewal used.

Carrier portal as the boundary

The workflow produces the packet. The brokerage uploads the packet to the carrier's submission portal. That is the boundary. The carrier's portal is not Mezdoc's problem. The brokerage's ops team uploads a finished packet instead of assembling one by hand.

What the work involves

How long this takes depends on how many templates you start with and how easily your AMS exposes account data through an API. The work comes in three stages:

• Templates: recreate the core forms with proper aliases. Map every visible field to a snake-case key.
• The workflow: build it with shared fields, document includes, and a cover-letter smart document. Test it on real-but-anonymized accounts.
• The trigger: wire the workflow to the AMS's renewal-initiation event. Test on a few live accounts with the ops team observing, then move the rest of the book over.

What stays your problem

• The underwriting decision is the carrier's. The workflow produces a clean submission, not a yes.
• The class codes, the operations description, and the loss history are your account rep's job. The workflow does not invent data.
• The carrier portals each have their own quirks. The packet is portable, but the upload is per-portal.

A practical first step

• Pick the one renewal pattern you do most often. Probably the GL + Property + Auto bundle for a particular industry segment.
• Recreate that subset of forms as Mezdoc templates with proper aliases.
• Build one workflow with the shared fields and two or three document includes.
• Run test renewals with real-but-anonymized account data.
• Compare the rendered packet to your account reps' manual versions. Fix what is off.

After that, each additional ACORD form is another template and, if it is conditional, another include rule. A brokerage that works this way can grow the book without growing the form-filling team at the same rate. See a packet assemble by rule in the live demo before you commit to anything.