Cutting commercial broker paperwork from 11 forms to 1 flow.

Picture a mid-market US commercial broker. Sixty producers, four hundred renewals a month, books spanning trucking, manufacturing, contractors, and a long tail of small commercial. The team handles every ACORD form you have heard of plus a dozen carrier-specific supplemental questionnaires. When a new account binds, eleven forms move together in a packet. When a renewal comes up, the same eleven forms move again with last year's data refreshed.

At some point the back-office team stops growing in proportion to the book. They cannot. The brokerage is hiring producers, not form-fillers. The teams that survive this wall do not throw more people at the forms. They 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 pack, briefly

The exact pack varies by account, but a typical commercial renewal packet looks something like this:

• ACORD 125 - Commercial Insurance Application (the core)
• ACORD 126 - Commercial General Liability section
• ACORD 140 - Property section
• ACORD 130 - Workers Compensation
• ACORD 137 - Commercial Auto section
• ACORD 25 - Certificate of Liability Insurance for additional insureds
• A carrier-specific supplemental questionnaire (often two)
• A loss-runs request authorisation
• 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.

And yet, in the typical brokerage, each form is filled separately. The account rep types the insured name eleven times.

Where the time actually goes

I sat with an account rep at one of these brokerages and timed a renewal packet from scratch. Fifty-two minutes. Of that:

• Nine minutes pulling up last year's submission from the AMS.
• Twenty-eight minutes filling the eleven forms, copy-pasting the shared fields, looking up the producer license per state, switching between PDF tabs.
• Eight minutes assembling the packet in the right order, generating the cover letter, naming files for the underwriter's preferred convention.
• Seven minutes sending the carrier's submission portal upload and confirming receipt.

The twenty-eight minutes in the middle is the productive theft. The other twenty-four are unavoidable interfacing with humans and systems that are not the forms. If the eleven-form fill went to zero, the rep could move from eight packets a day to eighteen.

The insured's legal name appears eleven times in a renewal packet. The account rep types it eleven times. Every brokerage at scale eventually decides this is the bug they want to fix first.

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 https://api.mezdoc.com/v1/workflows/commercial_renewal_v4/runs \
  -H "Authorization: Bearer $MEZDOC_KEY" \
  -H "Idempotency-Key: renewal_2026_06_NS-LOG-001" \
  -d '{
    "environment": "production",
    "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 137 (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 authorisation, 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 individual signed PDFs for the audit log. The account rep's twenty-eight minutes of 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 on the workflow run and the corrected packet regenerates. 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

ACORD updates the 125 form once every few years. When that happens, the brokerage publishes v6 of the ACORD 125 template, tests it on staging against a representative sample of accounts, and promotes it to production. The workflow run pins the version it ran on, so an audit two years from now can show exactly 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 has a one-screen upload flow instead of a fifty-two-minute assembly drudge.

What it costs to actually do this

Three weeks of focused work, give or take, for a brokerage with reasonable IT support and an AMS that exposes account data through an API. The breakdown:

• Week one: recreate the eleven core templates with proper aliases. Map every visible field to a snake-case key.
• Week two: build the workflow with shared fields, document includes, and a sample-cover-letter dynamic template. Test on twenty real-but-anonymised accounts.
• Week three: wire the workflow trigger to the AMS's renewal-initiation event. Test on five live accounts with the ops team observing. Move the rest of the book over a week later.

That is the real number. Not three months, not three days. Three weeks for the first version. The brokerage's next renewal cycle is the one where the per-packet time drops.

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.

The India parallel

Indian commercial brokers (Marsh, Aon, Howden, Policybazaar for Business, Renewbuy) have their own version of the 11-form packet. The packet is smaller (insurers publish their own proposal forms rather than a shared ACORD library) but the structural problem is the same: the same insured details land on the proposal, the surveyor questionnaire, the policy schedule, the COI, and the GST invoice. A workflow with shared fields collapses the typing the same way it does for a US ACORD pack. The Mezdoc condition language and version-pinning are identical whether the underlying forms are ACORD or IRDAI.

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 ten test renewals with real-but-anonymised account data.
• Compare the rendered packet to your account reps' manual versions. Fix what is off.

After that, every additional ACORD form takes a half day to add. The brokerage that figures this out first is the one that grows the book without hiring three more form-fillers a quarter. See the request shape in the live demo before you commit to anything.