Where the process runs
Draw the process once, it runs itself.
A trigger, then a readable tree of checks, actions, waits and AMI steps — authored by the support manager who owns the process, not by an engineer.
- 19
- triggers
- 16
- checks
- 25
- actions
- 12
- waits & AMI steps
New ticket triage and routing
When ticket created
SLA breach prevention
When sla approaching
Out-of-hours chat capture
When no agents online
Resolution follow-up and CSAT
When ticket resolved
Capabilities
What Workflows does
Every line below is something you can open in a trial and point at.
19 triggers across the whole desk
Nine on tickets, seven on chat, two on SLA deadlines, plus a schedule. Including the two that matter most: nobody has picked it up, and the customer has gone quiet.
16 checks that stay readable
Split by priority, status, category, impact, channel, plan, team, tag, SLA health or your own custom field — every path named, with an explicit everything-else.
25 actions covering the real job
Assign, route, re-queue, transfer, retag, re-prioritise, note, message the customer, notify a manager, escalate, open and close.
Waiting is a step, not a gap
Wait a duration, wait until you are open again, wait for a reply with a timeout path, or wait for a share of the SLA target to elapse.
SLA policies with a clock that pauses
Targets per priority, a business-hours clock, coverage by plan, team or category, and thresholds that warn the agent before they escalate to a manager.
Templates, publish checks, run history
Start from a template, publish only once the required fields are filled, then read every run back as a step-by-step timeline.
Works with
No connectors. Same records.
In practice