Workflow handoff
COI Request Handoff Checklist: From Requirement to Accepted Package
A certificate package passes through requirement, clarification, insurance review, issuance, internal comparison, delivery, receipt, correction, and client acceptance. Record each handoff so a later status cannot erase the source, owner, or prior package version.
Reviewed September 2026 · Educational information, not insurance or legal advice
Nine controlled handoff stages
1. Requirement received
Preserve the current written source, version, date, project reference, requested entities, trade, location, phase, evidence list, and deadline. Do not begin from a remembered summary or another client’s checklist.
2. Requirement clarified
Split ambiguous or conflicting items. The client or reviewer clarifies its expected scope and evidence. Contractual conflicts go to qualified commercial or legal review. Keep the original request and clarification together.
3. Project facts confirmed
The contractor verifies the legal contracting name, actual operations, site, schedule, subcontractors, vehicles, and other facts needed for an accurate request. Avoid policy numbers and unnecessary personal data in general workflow notes.
4. Issuer request sent
Send the licensed agent or issuer the exact requirement plus verified facts. Identify each policy or endorsement question separately. State the client deadline and the output needed.
5. Issued evidence received
Record the actual arrival event. “Received from agent” does not mean internally reviewed, submitted, or accepted. Preserve the original issued documents without editing them.
6. Package compared
Compare the named insured, policy periods, coverage lines, limits, holder, requested parties, descriptions, and supporting endorsements with the current requirement. Route mismatches back to the responsible owner.
7. Package delivered and receipt verified
Freeze the package version, use controlled filenames, submit through the approved route, and preserve the final destination record, timestamp, category, and receipt reference when available.
8. Reviewer response resolved
Separate every reviewer comment into an owner, input, expected output, due date, status, and next action. A corrected document creates a new package version; it does not overwrite history.
9. Acceptance and future checkpoint recorded
Preserve the exact acceptance source and scope. Record renewal, project-change, or closeout checkpoints that remain. Do not upgrade acceptance into a coverage conclusion.
Control the handoffs
Assign each unanswered question and expected output.
Build a private owner matrix for client, issuer, contractor, portal, and contract-review workstreams.
Minimum handoff record
| Field | Why it matters | Example |
|---|---|---|
| Issue or task | Keeps one answerable item per row | Confirm exact certificate holder |
| Workstream | Separates requirement, policy, package, and portal work | Business or entity facts |
| Primary owner | Identifies who controls the answer | Client or reviewer |
| Contributor | Shows who supplies necessary input | Contractor or vendor |
| Input needed | Prevents an owner from guessing | Current project instruction |
| Expected output | Defines an observable completion record | Exact legal name and address |
| Source state | Preserves clearly stated, inferred, missing, or conflicting information | Conflicting sources |
| Due date | Connects action to the actual project deadline | 2026-09-15 |
| Status | Prevents drafted, sent, received, reviewed, and closed from merging | Waiting on response |
| Next action | States the immediate controlled step | Ask client to reconcile exhibit and portal |
Stage gates before moving forward
- Before issuer request: current source, exact entities, operations, location, phase, evidence needed, and deadline are available or marked unresolved.
- Before package review: issued documents are preserved, source files are distinguishable from working notes, and every expected item is inventoried.
- Before delivery: each document has been opened, compared, named, versioned, and matched to the correct destination category.
- Before resubmission: reviewer issues are mapped to changed files, unchanged files, open questions, and the new version.
- Before closeout: acceptance source, unresolved exceptions, active project dates, renewal checkpoint, and retention location are known.
Common handoff failures and recovery
A requirement is forwarded without interpretation boundaries
Recover by splitting client meaning from policy evidence. Ask the client to clarify scope and the issuer to confirm what can accurately be issued.
An agent response has no connection to the original item
Reconnect the document or message to one requirement row, package version, date, and expected output. If the match is unclear, keep the status “response received—not reviewed.”
A package arrives with mixed versions
Stop delivery. Preserve the files, compare version and dates, obtain corrected evidence if needed, and build a clean snapshot. Do not rename an older document to appear current.
The portal shows success but one item is rejected
Preserve the package banner and file-level error. Assign the technical issue to the portal owner and any evidence issue to the relevant issuer. Do not call the entire package accepted.
The client changes requirements after submission
Preserve the prior source and acceptance event. Create a requirement-change record, identify the effective date, route new questions, and issue a new package only when needed.
An owner misses the due date
Record the missed milestone as an observable event, escalate through the approved project path, and ask the client about deadline impact. Do not fabricate an earlier submission timestamp.
Communication templates
Client clarification
“For project [reference], source [version/date], please confirm [one requirement question]. We need [exact output] by [date] to route the request accurately. This question concerns the client requirement; the licensed issuer will review policy-backed evidence separately.”
Issuer evidence request
“For project [reference], the client’s current written source requests [one item] for [entities/scope]. Accurate project facts are [brief facts]. Please confirm what certificate or endorsement evidence can be issued and identify any limitation or additional information needed by [date].”
Portal support
“For package [version], attempted [timestamp/time zone], file [visible name] under [category] shows [exact error/status]. Please confirm the destination record or authorized retry path. No credential or coverage interpretation is requested.”
Close a row with evidence, not memory
A row can be closed when the expected output is available, reviewed for the intended administrative purpose, linked to its source, and any downstream task is created. The closing source might be a client clarification, issued endorsement, corrected certificate, portal receipt, reviewer acceptance, or legal decision.
Do not delete earlier states. Preserve question drafted, sent, response received, correction, delivery, and acceptance events when they matter. The U.S. National Archives’ naming guidance is designed for federal records, but its principles of descriptive, consistent names and fixed date or version placement are useful for keeping these snapshots distinguishable.
King County’s guidance says contractors must provide evidence before contracted services and continue providing evidence through its contract life. That program-specific example shows why acceptance at one stage does not eliminate later renewal or project-change handoffs.
Closeout checklist
- Every row has one primary owner.
- Every completed row points to an authoritative output.
- No conflicting source is silently marked closed.
- The final package version and receipt are preserved.
- Reviewer acceptance is recorded exactly as communicated.
- Outstanding exceptions or commercial decisions remain visible.
- Renewal and post-completion checkpoints are scheduled when the written source requires them.
- Issued evidence remains unaltered.
- Credentials and unnecessary sensitive data are excluded.
- Retention follows the organization’s approved process.
Frequently asked questions
When is a handoff complete?
When the receiving owner has the necessary input and the workflow records the assignment. That does not mean the issue itself is resolved.
Can I close the matrix after client acceptance?
Close the current package rows while retaining renewal, change, or closeout tasks supported by the written requirement.
Should every email become a row?
No. Use rows for distinct issues, decisions, evidence outputs, and material status events—not routine conversation.
Who preserves the final package?
The contractor or organization should follow its approved record process. The client and issuer may retain separate authoritative records.
Does the checklist send or store documents?
No. It creates local text and CSV outputs from user-entered labels and does not upload evidence.
Sources and scope
- King County: Evidence timing and contractor requirements
- U.S. National Archives: File naming and version controls
- Texas Department of Insurance: Certificate boundaries
The stage gates and handoff record are original administrative guidance. The controlling contract, policy, jurisdiction, and authorized professionals determine actual obligations and authority.