Recent searches
No recent searches
Ability to Use Phone Numbers as Conditions in Triggers/Automations
Posted Dec 19, 2022
Hi,
We would like to have the option to use Talk lines numbers in business rules conditions, similarly to "Receive at" condition for emails:
We would like to create a view for calls that were directed to a specific number, no matter if the team responsible for this number actually answered the call or it was routed to another group.
Example: if a player calls our "VIP Customer Service" number, all VIP agents are busy, and a member of the secondary group for this line (regular "Customer Service Team") answers the call we would like to be able to add a "vip_customer" tag via a trigger, despite the fact that non-VIP agent answered the call. And we want to achieve this based on the number which the player called.
Please, consider adding "Talk number" conditions for triggers and automations.
Thank you.
Regards,
Yanko Chakarov
19
33 comments
Official
Bailey Whitaker-Lea
Hi all! I've notified the Talk PM to chime in on their roadmap plans on this thread. They will take it from here, thanks.
0
Anastasia Kachanova
+1
4
Bailey Whitaker-Lea
Hi @... - PM for Triggers and Automations here. I've captured your feedback for the Talk team to review. Thanks for providing your use case!
4
Valerie Hines
I absolutely concur! We have one number set up for extremely urgent issues and we need to set up some type of notification for those after hour calls.
3
Miguel Cordero Collar
+1 this is a very useful and probably easy to implement feature
2
Noelle Cheng
hi @..., do you have a timeframe of when this will be available? We currently really need this as to help sort or tickets to trigger other automations. Thanks!
1
Sydney Neubauer
+1 This is a must for our team now. We are using triggers to look for ticket COMMENTs with the specified number but the issue this causes is that if someone submits a ticket and their signature includes the number, the trigger fires incorrectly and it causes a big mess for our team
It would be more safe to have a trigger condition specifically for the number so it would not matter if it was contained in the email to us in Zendesk
3
Atanas Tomov
+1
1
Carlota Bergillos
+1
2
Steve Hehl
+1
2
Ethan Martin
Ditto. Being able to use a specific Talk line/number as a condition in triggers would be very very very helpful for us.
2
Nora
Yes please!
1
Carlos Garcia
YES PLEASE! some way to do this?
1
Widson Reis
Hi, here from the Talk Team!
The ability to create conditions based on phone numbers is something we don't have in our roadmap just yet, but there's a simple workaround that should work for most cases.
All tickets created by Talk have comments containing fields "call from" and "call to" (or simply "from" and "to" when the caller leaves a voicemail or abandons the call). So, you can create a trigger based on finding these specific strings in the ticket comment text. Make sure to use the additional condition "Ticket > Channel is Phone Call Incoming" so your trigger won't be triggered by any phone number, like in emails or comments left by the agent etc.
An example:
0
Tony
I think that could be considered as an update in the ticket.
Best,
0
Widson Reis
Hi Alan Yedid
That's a comment to the ticket indeed — a "voice comment", as a matter of fact. For regular inbound calls, this voice comment is added to the ticket at the end of the call, while an internal comment, with the phone numbers, is added at the beginning of the call.
1
White Label Storage
Hi Widson Reis , thank you for your workaround of creating tags based on ticket comment “Call to: …” This has solved an issue I was having. I am now trying to understand how I can use this for inbound text messages. I don't see anywhere in the ticket information which phone number the user texted. Do you have a solve for this? Thank you.
1
Richard McCauley
Hi Widson-Reis. Same issue as above. How do I do this for inbound text?
0
Widson Reis
Hi, White Label Storage , Richard McCauley
I've been looking for a workaround that would work for texts too, but I'm afraid we don't have one at the moment. It looks like we don't expose the Talk number that the user texted to.
I have added this to our backlog though.
0
Richard McCauley
Thanks Widson-Reis. Question – given that in my flow starts with an outbound text, is there a way to set a trigger for the customer reply, that is based in something that appeared in the original outbound?
0
Widson Reis
Hi Richard McCauley
That should be ok. You just need to create a ticket based on the conditions channel = “Text” and ticket is “Updated”.
0
Chris Batt
+1
Looking for native support for this in trigger options. I have some apprehensions about relying on the workaround, as it is not bound explicitly to the product, it's just kind of a hack. If there is ever a change in how the call information is translated to the ticket, it could cause the string matching to fail and break the trigger workflow. I really hope this can make it on to the roadmap.
1
Richard McCauley
Widson-Rei Really do appreciate your help, but I must be exlaining poorly. The goal is to differentiate certain inbound SMS from others.
The workflow I was addressing here happens to start with an outbound SMS, but so do other of my workflows.
My question was if there was something we could put in that initial SMS that would allow the reply to be specifically identified. The update fix you just described would apply to all workflows that start with an outbound SMS.
Again, given that we cant segregate by phone number (in which case I would have just started added dedicated phone numbers), is there any way in the world to distinguish certain inbound SMS from other inbound SMS? Right now, the only thing that will work is directing the requestor to enter certain text – but this is obviously impractical and unreliable. Thanks again.
0
Kristian Korsgaard
Given Omnichannel custom queues, having the option to use specific phone lines as conditions is extremely valuable.
0
Widson Reis
Hi Richard McCauley
I'm sorry, I did misunderstand you.
I assume that the outbound text is fired as a notification trigger. These notifications can use all sorts of placeholders to display fields from Tickets, Organisations, and Users. The full list of placeholders is here. You could add one or more placeholders that uniquely identify the user either to the message itself or to an internal comment in the ticket (you could also simply add a tag to the ticket that you can check later). When the user replies to the message and the ticket is updated you can check (using a variation of the conditions above) if the ticket contains the field you seek.
Do you think something like this could work?
0
Richard McCauley
Wilson Reis. Thanks again for you attention and kindness. I have tried myriad means of having the new inbound SMS relate to the original SMS. The most basic way (obviously) is through tags. The outbound SMS always uses a unique tag, so the trigger on the inbound or view-rule for it, should simply look for that tag. But this just doesn't work, and I believe this issue (combined with the fact that ZD cannot differentiate by phone number) that is driving much of this conversation.
It just always seems like the inbound is totally blind to the outbound. I have simply found no characteristic that causes the new ticket to look at the original one. That said – it IS the case that original SMS, and its original ticket number DO appear within the new inbound ticket which of course has a new ticker number. And this makes this problem all the more frustrating! Thanks again.
0
Katie Duck
+1 we need options for routing voicemails - we have high level groups but use a dropdown for routing tickets to sub teams. When we receive voicemails, there's not a great way to route via rule
0
Diego Colognese
please do it asap!!!! we need this!
anyone has come with a workaround to suggest me?
ciao from Italy!
0
Widson Reis
Hi Katie Duck
You are correct. There is no way currently to route voicemails and tickets from expired callback requests. This is a part of our plan for next year.
1
Francisco Serna
Is this still planned to be worked on? Very important feature for AvantStay
1