Handling Awaiting User Three‑Strike Rule When User Meeting Is Scheduled (Looking for Best Practice)

[danesh]

Hi Everyone,

We currently have a three‑strike rule on Incident → Awaiting User that sends reminder notifications to the affected user after a defined inactivity period and may eventually lead to escalation/closure.

 

Problem / Use Case

There are scenarios where the fulfillment team has already scheduled a future meeting (call/workshop) with the user, sometimes more than a week out due to user availability.
In these cases:

• The user is not unresponsive
• The delay is mutually agreed
• However, the incident remains in Awaiting User, which causes the three‑strike reminders to trigger, sending unnecessary/confusing emails.

We want to avoid firing strike notifications when a future engagement is already planned.

 

Proposed Solution (Initial Thought)

Introduce a separate governed incident state, for example:

• “Pending – User Scheduled” (or similar)

High‑level behavior:

• Used when a meeting/call with the user is scheduled for a future date
• Requires a mandatory Next Engagement Date
• Excluded from the three‑strike logic and reminder notifications
• Once the engagement date passes, the incident automatically moves back to Awaiting User, and the standard strike logic resumes

 

Questions for the Community

1. Is introducing a separate incident state the recommended approach, or is there a more standard pattern?
2. Has anyone solved this use case using:
   • On Hold reasons?
   • Flags/attributes instead of a state?
   • SLA or Flow‑based suppression logic?
3. Any gotchas to watch out for (reporting, SLAs, state model integrity, analytics)?

We’re aiming for a solution that is process‑accurate, auditable, and scalable, without introducing too many exceptions into the strike logic.

Appreciate any insights or examples from real‑world implementations.

Thanks in advance!

[brianlan25]

I would recommend adding an on hold reason rather then a state. We have a custom state that was added by our first vendor called Assigned even though it is counted in performance analytics I cannot get it to display properly on dashboards like Incident state monitor.