Escalation workflows and settings
Decide which engineering updates reach your support agents, when Pluno follows up with the team, and which agent Pluno posts its internal notes as.
After a ticket is escalated, Pluno watches the conversation on both sides and decides what to pass on. Escalation workflows are the rules it follows when it decides.
You need the Admin role for everything on this page.
What Pluno does after an escalation#
Pluno looks at the ticket again whenever one of these happens:
- The team updates the issue or replies in the thread.
- The customer writes on the ticket.
- A reminder it scheduled comes due.
It sees the whole conversation on the ticket and the whole thread or issue history, including comments, status changes and assignments. Then it can do any of these:
| Pluno can | Effect |
|---|---|
| Add an internal note to the ticket | Your agent is told about the update. The ticket is set to Open |
| Suggest a message for the customer | Shown in the sidebar for the agent to send |
| Message the customer | In autonomous mode, Pluno relays the update itself |
| Comment on the issue or reply in the thread | For example, to pass on information the customer supplied |
| Schedule a reminder | To check in with the team later |
Pluno does not edit fields on the issue, create new issues or threads, or assign agents or groups.
The default workflows#
Every workspace starts with five workflows. Together they keep Pluno quiet unless something matters.
| Name | What it tells Pluno |
|---|---|
| Check in with internal team, but only once. | If support is waiting on the team after they started work, check in after at most 96 hours. Only once |
| Almost never send messages to Jira/Slack (Always applies) | Interrupting the team is costly. Only write to them when they are actively asking for information |
| Assignment handling | Ignore assignee changes |
| Status update handling | When the status changes to Done or Resolved, inform the support agent. Otherwise send nothing |
| Handling resolved Zendesk tickets | If the ticket is already solved or closed, send nothing more |
You can edit or delete any of them.
Change a workflow#
- In the Pluno web app, open Escalation Copilot, then Workflows.
- Select New Workflow, or the pencil icon on an existing one.
- Enter a Name and a Description.
- Select Create or Save.
A workflow is active as soon as you save it. Your workflows take priority over Pluno's general behavior, and one set applies to your whole workspace.
Examples#
| Goal | Workflow description |
|---|---|
| Hear about more than the final status | Also inform the support agent when the Jira status changes to "In Progress" or "Ready for Release". |
| Follow up sooner | If no update is received from the internal team within 3 business days, send a reminder to the Jira thread. |
| Pass on customer answers | When the customer provides information the internal team asked for, post it to the issue. |
| Stay silent on a project | Never send any message for issues in the INFRA project. |
Write the condition into the text, as you would for Deflection workflows.
Choose the agent Pluno posts as#
Pluno's internal notes are posted by an agent in your help desk. Choose which one:
- Open Escalation Copilot, then Settings.
- Under Which agent in Zendesk should the Escalation Copilot use?, select the agent.
- Select Save.
If you do not choose one, notes are posted as the agent you chose for ticket deflection. If that is not set either, they appear under the account that connected Pluno.
The notes Pluno writes#
All notes are private. This is how to read them:
| Note starts with | Meaning |
|---|---|
| Pluno - Update from Jira: (or Slack, or Linear) | The team shared something your agent should know |
| Pluno: followed by a link and "created via Pluno" or "linked via Pluno" | The ticket was escalated or linked |
| Pluno: followed by a link and "unlinked via Pluno" | A link was removed |
| Pluno: followed by "has been moved to" | The issue was moved to another project or team and has a new key |
Last updated