Ticket Creation and Assignment
This document outlines possible scenarios from combinations of different settings and other circumstances in the Zendesk app and related expected behaviour of the app.
Terminology used
attribute | A Connect custom attribute which, if specified in the contact flow, can override the default configuration setting value. Example: |
to pop | To automatically open a new tab (or shift focus to existing one) in Zendesk Support UI for a specific user or ticket. |
auto assignment | Operation mode where tickets are created and/or assigned to the call automatically based on conditions and rules described in this document. Agent has no control over the process (default behaviour). |
manual assignment | Operation mode where users or tickets are presented to the agent (popped) but then it’s up to the agent to decide whether to create a new ticket (and for which user), or pick an existing ticket and attach the call to it. Manual assignment mode is activated by setting the attribute |
recognised user | A caller that was identified as an existing Zendesk user. If a user ID was passed via |
unrecognised caller | A caller that could not be identified as an existing Zendesk user, although their details may have been provided in one of the above described ways. Their CLI will be used when creating a new user (except when anonymous - see below). |
anonymous caller | A caller whose CLI came across as “anonymous” or “private” and therefore could not be identified as an existing Zendesk user . |
recent ticket | A ticket of a recognised user that has been updated within the last x minutes, as specified in either the corresponding application setting or in the contact attribute |
Scenarios for inbound calls
No. | Circumstances | Auto assignment | Manual assignment |
---|---|---|---|
1. | Unrecognised caller, ticket attribute not set | A new user is created and a new ticket is attached to this user. | Agent can press the |
2. | Unrecognised caller with a valid ticket number in the attribute. If the ticket number is invalid, empty or equals | A new user is created and a new ticket is attached to this user as there’s no guarantee that the unrecognised caller is the actual requester of that ticket. | Ticket is presented (popped) to the agent and they can identify the caller and confirm they are an existing user and the quoted ticket belongs to them before clicking on the |
3. | Recognised user, ticket attribute not set, the recent ticket timeout is not set, or no recent tickets exist | A new ticket is automatically created for the recognised user. | User is popped and the agent has the option of either creating a new ticket for that user or if the call relates to an existing ticket pick that one and attach the call to it. |
4. | Recognised user, ticket attribute not set, has at least one recent ticket within the specified recent timeout. | The most recently updated ticket is popped and the call is attached to it. | The most recently updated ticket is popped and the agent can attach the call to it by clicking on the |
5. | Recognised user with value | A new ticket is automatically created for the recognised user, same as in the scenario 3. | User is popped and the agent has the same options as in the scenario 3. above |
6. | Multiple recognised users with the same calling number, other circumstances the same as in scenarios 3. to 5. above | The user which has the number as a direct line is selected. Then, depending on other circumstances one of scenarios 3. to 5. applies. | The user which has the number as a direct line is selected and popped. Then the agent has the same options as in scenario 3. above |
7. | One or multiple recognised user with a valid ticket number in the ticket attribute. If the number is invalid, or doesn’t match any of the recognised users it’s treated as in the scenario 3. above | The specified ticket is popped and the call is attached to it. | The specified ticket is popped and the agent can attach the call to it by clicking on the |
8. | Anonymous caller, ticket attribute not set | A new ticket is automatically created with the agent as the requester. Agent then has to either find an existing user or create a new one and change the ticket requester to that user. | Agent has the option to either create a new user through Zendesk UI and then create a new ticket for them, or find an existing user and decide whether to create a new or select an existing ticket to attach the call to. |
9. | Anonymous caller with a valid ticket number in the ticket attribute (if ticket number is invalid, it’s treated the same as scenario 8. above) | A new ticket is automatically created with the agent as the requester as we can’t guarantee that the anonymous caller is the actual requester of that ticket. Then the agent should take similar actions as in the scenario 8. above | The quoted ticket is popped and the agent can attach the call to it by clicking on the |
Scenarios for outbound calls
No. | Circumstances | Auto assignment | Manual assignment |
---|---|---|---|
10. | The call originates from the user tab in Zendesk UI, clicking on a number in the | A new ticket for the selected user is automatically created and the call is attached to it. | The agent can either create a new ticket for that user or, if the call relates to an existing ticket, pick that one and attach the call to it. This may apply in situations where a customer requested a call but it’s unclear what their query is related to. |
11. | The call originates from the softphone dial pad or quick connects, with the phone number of an existing (recognised) user. | A new ticket for the recognised user is automatically created - same as scenario 10. above. | The recognised user is popped, then same applies as in scenario 10. above. |
12. | The call originates from the softphone dial pad or quick connects, with the number that matches multiple existing (recognised) users. | The user which has the number as a direct line is selected. Then, a new ticket for that user is automatically created - same as scenario 10. above. | The user which has the number as a direct line is popped. Then the same applies as in the scenario 10. above. |
13. | The call originates from the ticket tab by opening the | The call is attached to the selected ticket. | The call is attached to the selected ticket (same as in auto assignment). |
14. | The call originates from the ticket tab by opening the | The call is attached to the selected ticket (same as in scenario 13. above). Note: The number dialed is not automatically attached to the ticket requester. This scenario is mainly for calls going out to 3rd parties and attaching call details to the ticket. | The call is attached to the selected ticket (same applies as in auto assignment). |
15. | The call originates from the softphone dial pad or quick connects, to an unrecognised number. | Nothing happens. The call is not attached to any new or existing ticket. Useful in situations where calls are general in nature and unrelated to specific Zendesk users or tickets. This can be overridden though by setting the | Nothing happens, unless the behaviour is overridden by setting the |
Out of the box defaults and assumptions
Out of the box installation settings for inbound calls have default values which, if not modified, will lead to scenarios 1., 3., and 8. with related auto assignment behaviour, as described above. Default values for these settings are as follows:
Create ticket after minutes | (blank) | ignore recent tickets, always create a new one |
Contact attribute name containing Zendesk Ticket Number |
| assuming attribute with this name is not set in the contact flow. |
For outbound calls all scenarios (10. to 15.) apply with their respective auto assignment behaviours.
For detail description of all configuration settings, their default values and related attributes which can override them please see Custom Contact Attributes Used in the Connector App.