Celso_Pedrosa | 2018-07-23 13:55:15 UTC | #1
Hi,
Need help setting Architect to Screen-Pop a new ticket on Zendesk for the customer profile that is calling.
I have read available articles from the Knowledge Base and PureCloud support team redirected me to here. I was already able to use this integration successfully in 2 different ways, as instructed by the article - but they actually does not cover this need specifically. Those ways are:
- Screen-Pop customer register that is calling on Zendesk (but not creating ticket)
- Screen-Pop a new ticket on Zendesk (however the ticket is created on the agent profile, not on the customer's)
I tried combining attributes of method #1 and #2, passing SearchType CONTACT and SearchValue cust_id, together with SearchType TICKET SearchValue NEW - but it still does not work.
Can anyone provide guidance on how this can be achieved?
Thanks.
Richard.Schott | 2018-07-30 15:47:30 UTC | #2
You can't "stack" the screen pop attributes like that. The integration will only process a single screen pop event per call, and the contact screen pop is the one likely to get processed if both are present.
The new ticket screen pop should already attempt to add the requester based on the inbound phone number. If there is only one contact in your zendesk org with that phone number, then we will set the requester automatically. If there is more than one contact with that phone number, then we will pop a modal with the search results for that phone number and allow the agent to select the requester from the list. If there are no contacts in your zendesk org with that phone number, then we will set the requester to the agent handling the call, which should be an indicator to the agent that they need to create a new contact with that phone number in your zendesk org.
It's worth noting that zendesk can be somewhat particular about phone number string matching, so it might be worthwhile looking into whether there is a difference in the formatting of phone numbers for your contacts in Zendesk and how PureCloud is searching (PureCloud uses e164 formatting).
Another alternative you have at your disposal is to use a data action to create the ticket in the IVR, then screen pop to the newly created ticket by id. This would allow you to collect all the relevant information from the customer in the IVR concerning their ticket, potentially saving the agent a significant amount of time. This approach will actually pair very well with the upcoming Amazon Lex integration with the IVR. This would allow for a bot to triage calls and create tickets within the ivr, then screen pop those completed tickets to agents when they are determined they need to be escalated for human assistance.
Celso_Pedrosa | 2018-08-06 14:20:17 UTC | #3
Hi Richard,
thank you for your answers.
I did some tests and noticed that the Screen-Pop is still not working as expected. Calls on PureCloud uses the international code 55 for Brazil while Zendesk CRM stores phone numbers without the 55 code.
The data dip block uses the parameter Right(toString(toPhoneNumber(Call.Ani)),11) and works just fine to capture information from the CRM. However, the Screen-Pop appears to be searching the CRM with the 55.
Can the Screen-Pop also query the CRM disregarding the 55 BR code, as the data dip is set?
As for the alternative you mentioned in the last paragraph, you are saying that Architect is now able to create tickets in Zendesk whenever the customer reach a given block on the IVR? Can you provide more information on how this can be done?
Thank you.
Richard.Schott | 2018-08-06 14:44:13 UTC | #4
At this time, I don't believe there is a mechanism for ignoring country codes for the ANI based lookups within Zendesk.
As for creating data actions to create a ticket in zendesk, I would look at these two articles: https://help.mypurecloud.com/?p=141862 and https://developer.zendesk.com/rest_api/docs/core/tickets#create-ticket
To get started, you can copy the get ticket by id action and rearrange things while setting the HTTP method to "POST" instead of "GET" in the action request configuration. You'll need to build out a request body to populate the relevant fields of the ticket, substituting in "input.{{AttributeName}}" to fill in information with values from the input contract.
I highly recommend testing the action to confirm it's working as expected before publishing the data action and dropping it in your call flow.
system | 2018-09-06 14:44:15 UTC | #5
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 3227