Settings and activity
23 results found
-
1 vote
Matt Chalupsky
shared this idea
·
-
2 votes
An error occurred while saving the comment Matt Chalupsky
shared this idea
·
-
2 votes
An error occurred while saving the comment Matt Chalupsky
commented
Our partners need to be able to edit all parts of the system for their accounts, but we don’t want to be giving them full super-user access. We need a way to give them super-user access at a single account level.
Matt Chalupsky
shared this idea
·
-
2 votes
An error occurred while saving the comment Matt Chalupsky
commented
When a WWW node times out there is no reason code in the debug. We need to see the reason code so that we can determine why it’s not working.
Matt Chalupsky
shared this idea
·
-
2 votesMatt Chalupsky
shared this idea
·
-
2 votes
An error occurred while saving the comment Matt Chalupsky
commented
Other contact center platforms have the ability to trigger manual closure branches. Currently the only way to configure something like this in EV is to put a Javascript snippet that the customer needs to go in and change, which is far from intuitive. This is an important feature to customers, and we need it built in a way that’s familiar to people moving over. A good addition to the base feature would be a way to tie a phone number to the switch so that the customer can call in to manage it in case they’re in a situation where they have no internet access.
Matt Chalupsky
shared this idea
·
-
3 votes
An error occurred while saving the comment Matt Chalupsky
commented
A complainant that comes up on many projects is that agents need an admin account to see dashboards. This is especially disruptive for companies where everybody is working remotely. This is a feature that is currently available to CC customers, and has cause several new EV customers to question whether the platform will work for their company.
Matt Chalupsky
shared this idea
·
-
2 votes
An error occurred while saving the comment Matt Chalupsky
commented
Many APIs require an initial authentication call in order to make the main API request. This means we need to be able to fire at least two API calls for an event.
Matt Chalupsky
shared this idea
·
-
3 votes
An error occurred while saving the comment Matt Chalupsky
commented
This is standard for IVRs. Why it’s in the agent scripting studio but not the IVR studio is confusing. While we can do things through Javascript to accomplish the same outcome, it really does need its own node in IVR studio so that the call flow can be more easily understood without having to open up and analyze SCRIPTING nodes.A good example would be zip code routing. The GETINPUT node is simply going to look for five digits, not whether or not it's valid. The use case here would be for a JavaScript snippet to see if it's a valid zip code and then go to a loop node. If it was valid it routes it to a queue, if not then it loops back to the GETINPUT. After a couple times through the loop finishes and the caller is disconnected. Technically we can accomplish this now through JavaScript, but this would make it simpler and more easily visible and editable to the customer.
Matt Chalupsky
shared this idea
·
-
2 votes
An error occurred while saving the comment Matt Chalupsky
commented
Currently there is no way to get return data out of a web service to be used in an agent script. The lack of this makes the whole feature of event driven web services more or less useless. The system receives this information. We just need to be able to access it from scripts.
Matt Chalupsky
shared this idea
·
-
2 votesMatt Chalupsky
shared this idea
·
-
2 votesMatt Chalupsky
shared this idea
·
-
2 votes
An error occurred while saving the comment Matt Chalupsky
commented
It would be helpful to have several pre-built roles for customers to choose from. It would also be easier on us so we don't have to build them for every account, and easier on customers since the permissions section of EV is clunky and awkward to use. We've had repeated complaints about this during delivery.1) Full Access - Super admin for the account (this one's already there).2) Agent Admin - Access to view and change all agent settings, as well as analytics.3) Reporting Admin - Access to analytics only. No access to view or change anything in the admin section.
Matt Chalupsky
shared this idea
·
-
2 votes
An error occurred while saving the comment Matt Chalupsky
commented
This is a critical issue, as it forces the sales team to move projects to CC if a customer needs an API integration to their CRM for outbound calls, even if EV is the better platform for their overall use case. This can also kill deals completely if the customer needs this basic functionality but doesn't want CC.Receiving servers currently see API calls coming from agent scripts as originating from a website. This has to potential to cause issues due to security settings on the receiving end. Currently this is causing a large problem for customers asking for an API integration with their CRM for outbound calls. The CORS restrictions on the CRM doesn’t allow the requests to get through, even after you’ve whitelisted a domain (in the case of SF). This blocks integrations for outbound calls to many CRMs, including Salesforce, Hubspot, and Zendesk (if the customer wants to use OAuth).Bill Fisk and I have suggested adding a drop down menu or a checkbox to the WWW node in agent scripting that switches between client side requests (that should be default so it doesn't break any current builds) and server side requests. The server side requests would simply run through a proxy, which will resolve the issue.Fixing this would increase EV sales, and give us more room to clean up our CC backlog. This has been a known issue since the platform was Connect First. We first identified and reported it for Engage Voice in late 2019 with our first SF integration, and it's been in Aha on the SE ideas board since February of 2021 where it has been marked as "future consideration." Everybody involved in selling and deploying EV, as well as customers that have been affected by this, would agree that this is a top priority fix.
Matt Chalupsky
shared this idea
·
-
2 votes
An error occurred while saving the comment Matt Chalupsky
commented
Not being able to see debug results for web services and agent scripts makes troubleshooting very difficult. We need to be able to easily access those logs.
Matt Chalupsky
shared this idea
·
-
5 votes
An error occurred while saving the comment Matt Chalupsky
commented
The lack of the ability to be able to split an IVR into several scripts and transfer between them as needed is one of the most obvious differences between EV and CC. This functionality allows us to keep scripts focused so that we’re not having to build everything into a single setup. It's also critical that call data is maintained between the IVRs. The ability to use containers is helpful, but doesn’t truly cover this gap.This is another issue that sometimes forces sales to move projects to CC instead of EV.
Matt Chalupsky
shared this idea
·
-
4 votes
An error occurred while saving the comment Matt Chalupsky
commented
Having to program holidays in the IVR through Javascript is unacceptable. This needs to be handled in the DATE TIME node. Customers are very often frustrated by this.
Matt Chalupsky
shared this idea
·
-
7 votes
An error occurred while saving the comment Matt Chalupsky
commented
This has come up several times. Contact Center has the ability to check whether or not agents are logged into the queue periodically while a caller is waiting, as opposed to only checking when the call enters the queue. Our CC customers use this to make sure people aren't continuing to wait if everybody logs out while they're waiting. This could be due to the end of the work day, but it could also be due to unplanned things like a power outage, fire alarm, etc.We've had several EV customers ask for the same functionality, and they're frustrated when we tell them we can't provide it. While not all customers need this, the ones that do find it very important so that their callers aren't waiting, possibly for a significant amount of time, for agents that are on longer logged in.
Matt Chalupsky
shared this idea
·
-
2 votesMatt Chalupsky
shared this idea
·
-
2 votesMatt Chalupsky
shared this idea
·
EV currently sees a * keypress as a terminator. For customers who are using the * and # keys in their IVR menus this is a major problem. At the very least the * key needs to no longer be automatically seen as a terminator. The best result here would be to give the ability to define a key as a terminator which is currently a capability in CC.