So Steve, I am not sure I fully understand the questions you are posing here, but I believe it is a simple integration issue that we can resolve easily. Since you have been live with us less than 2 weeks I am sure it is simply a setting that can be adjusted. I will email you off-list so we can set up a call to address the concerns.
To address the comments mentioned by some others in the thread: 1. We do not route calls overseas unless it has been authorized by the ISP. The exception mentioned on the list here is that if and ISP has a complete outage and has 50-100 calls drop into queue before the outage is identified we may use the overseas agents to simply pick up the call and confirm to the customer there is an outage. Once the outage is identified we put a message up on the phone system to stop the influx of calls. Jeremy if that was a deal breaker for you we would certainly have looked for an alternative, sorry that created a problem. For us it is a balance to make sure that one ISPs outage does not create long hold times for all other clients. 1. Our average hold time is typically between 1 and 2 minutes. For example today it is 1:33. Month to date it is approx. 1:28. It is certainly possible to shorten that time, but not while maintaining our standard pricing structure. It is a balance between cost and service, much in the same way that a WISP can usually provide more bandwidth but the balance between cost and speed has to be considered. 1. We definitely do not have a mandatory hold time, only an average which we are always working to decrease, most customers calls are answered within seconds. I would pose a question to the group, would you be willing to pay say 30% more for the service, if the hold times dropped by 30 seconds? Most people I have spoken with have said no, but it was admittedly a small sample size. We have considered a scaled pricing model with a hold time SLA of < 3 min, < 2 min, < 1 min. What are your thoughts? Layne Sisk ServerPlus 801.426.8283, ext 102<tel:801.426.8283%2C%20ext%20102> [New logo xl]<http://www.serverplus.com/> [http://i.imgur.com/VOz763A.png] [http://i.imgur.com/xvQYYWa.png]<https://www.facebook.com/ServerPlus365/> [http://i.imgur.com/ELG0AB1.png]<https://twitter.com/RealServerPlus> [Utah 100] [fast50-01] [Inc 5000] From: Af [mailto:af-boun...@afmug.com] On Behalf Of Steve Jones Sent: Monday, July 10, 2017 9:49 PM To: af@afmug.com Subject: Re: [AFMUG] Serverplus/powercode users, OT I also meant offlist, not OT On Jul 10, 2017 10:31 PM, "Steve Jones" <thatoneguyst...@gmail.com<mailto:thatoneguyst...@gmail.com>> wrote: Oh yeah, the powercode ticket vs the email ticket formatting is night and day awful, why bother with an api if you cant actually tell what the heck is happening. ... and the api generated ticket cant be reassigned for the customer, though i believe thats a powercode issue... and given the "new" powercode, i dont see that getting fixed....simon... simon, where are you? On Jul 10, 2017 10:27 PM, "Steve Jones" <thatoneguyst...@gmail.com<mailto:thatoneguyst...@gmail.com>> wrote: Im not sure how they pay, but it looks alot like when we used to comission new sales, a new account for each call based on who answered the phone.... if thats tje case, comission calls, then why bother Ive seen multiple existing tickets restarted... bad juju on that. Anybody know if they actually look at existing tickets? Closing and resolving unresolved issues is bad business for me too. Im thinking its just a matter of getiing on the same page, but if others have had similar issues and found workarounds ... or walked away, please let me know. Serverplus was not my first choice for an outsourced it, so i may be jaded. On Jul 10, 2017 10:13 PM, "Steve Jones" <thatoneguyst...@gmail.com<mailto:thatoneguyst...@gmail.com>> wrote: Not impressed, a short time in, by any means. Serverplus guys, no offense, i need info to make this work outside a retention response. I know luthman uses them, but anyone else with powercode, please OT me so i can find out whats broke on our side before i have the boss talk.
