Certificate of insurance request: task, due date SLA and chase

Outcome. A certificate request stops being an email somebody remembers. It becomes a ticket with a named holder, a date the insured actually needs it by, one task, two reminders and a record of when it went out.

Workflow map Enrollment, branches and actions at a glance insurance-002

flowchart TD
    A[Enroll: certificate request, not yet issued] --> B{Holder and policy known?}
    B -->|no| C[Task and notify owner, then exit if still blank]
    B -->|yes| D{Due date known?}
    D -->|no| E[Priority Medium, task due in 2 days]
    D -->|yes| F[Priority by urgency, task due in 1 day]
    F --> G[Delay to 1 day before due date]
    E --> G
    G --> H{Issued?}
    H -->|yes| K[Wait for issued date, max 10 days]
    H -->|no| I[Reminder task and notify owner]
    I --> J[Delay to due date]
    J --> L{Issued?}
    L -->|yes| K
    L -->|no| M[Priority High, notify escalation contact]
    M --> K
    K --> N{Issued within 10 days?}
    N -->|yes| O[Close ticket, survey runs on closure]
    N -->|no| P[Notify escalation contact, leave open]

When to use it, when not to

• UseUse it in any agency with a commercial book. Certificates are high volume, low value and time critical, which is the exact shape of work that gets forgotten between two claims.
• UseUse it when the same certificate keeps being reissued because the holder name was wrong. This workflow forces the holder onto the record before the task is created.
• SkipDo not use it for the certificate that comes with a new policy at binding. That belongs in the binding checklist, not the service queue.
• SkipDo not build it before the service pipeline has SLA targets and a first response alert. Certificates inherit the desk's response clock, and without targets the reporting has nothing to show.