Jump to content

Rick Guyton

Customers
  • Posts

    628
  • Joined

  • Days Won

    41

Posts posted by Rick Guyton

  1. Just now, Darren Schreiber said:

    Also, we were debating allowing you to add a backup credit card.

    I like that idea as well. But, I'd personally probably still be a bit uneasy because it wouldn't account for potential issues between 2600hz and their processor. I understand this kind of thing is SUPER rare but, when you are talking about shutting down all of our clients... Maybe I'm being overly concerned about it, but that' just scary as hell not having time to react to something.

  2. After the billing webinar yesterday, I'm left with a nagging concern. I intend to use the "bill this card directly" feature as the idea of having to pre-pre-pay my account isn't very appealing to me. My concern is though, as I understand it, one attempt will be given and if it doesn't succeed, all of my accounts will be shut off immediately. And that would be catastrophic to our business. On the one hand, I kind of understand it. I mean, if you don't have money on your card, that's your problem for not having that sorted. And if that were the only concern, I'd think, well heavy handed, but fair. But in the past 3 years I've had 4 cards replaced due to fraud. It's terrifying to think that if one of those indents could have lined up just right, it could have the effect of shutting all of my customers down. Not because of anything I personally caused, but because some dude skimmed my card at some point and bought the bar a few rounds in a bar in France (yep, that really happened).

     

    And this sets aside a plethora of other issues. Like, what happens if we have an issues like those fiber cuts on June 28th... Man, that was pretty close to the end of the month. What if that affected 2600hz's merchant processor. Or 2600's ability to reach their merchant processor? Or what if the merchant is just down? Or they enable a new cipher unexpectedly? What if VISA/MC/AMEX/DISCOVER, just randomly decided that the charge this month looks fishy and does a security decline until they can get ahold of me and approve it. AMEX is notorious for this. I mean the edge cases are everywhere. Just seems like some small safety net is in order.

     

    So, can we please have something a bit safer than that? Some ideas:

    1) Give us at least 3 days to respond (in case it happens on a weekend)

    2) Allow us to have the balance pulled a few days in advance. AKA,  change "bill this card directly" to "Bill this card directly [NumberInputBox] days in advance". That way if someone really wants to live on the edge, they can put 0 in there. But, the rest of us can put maybe 3, 5 or 7 days in there.

     

    Thoughts?

  3. 11 minutes ago, Logicwrath said:

    Are you not able to pre-pend anything to the caller ID name on mobile?  I suspect you tried that first thing but I am curious.

    Well CallerID doesn't come through to the cell. I'd considered adding a callerid number prefix. But, even after dis-associating the phone from my user in SmartPBX, I can't create a call flow for my personal number. ADV callflows says there's another callfow with that number already. Tempted to just delete that callflow via API, but not quite sure what that'd do on the 2600hz side...

  4. 1 hour ago, Darren Schreiber said:

    @Rick Guyton I think your response is more on a chronic issue, where as Travis's issue is that suddenly today all of clients started complaining at the same time. From our side, we saw 100% packet loss to his customers from ORD. I don't think your issue is the same in AZ frankly. The symptoms and timeframes don't match.

     

    Yea, probably right. Mis-read the original post I guess. I'm thinking mine is more of an ongoing local issue with Cox. Thought it might be realted

  5. Hey Travis,

         We've been seeing a lot of this too in AZ. I'm trying not to have a tin foil hat over here. But it started after net neutrality started to get knocked around for us... At the end of the day, we use Queue Trees on our MikroTik routers and I just have to limit down the max throughput on them. On a 25/5 connection I used to set a max of 24/4 throttle to insure we controlled prio. But more and more I have do go down to 23/3. 😕

         I'm really hoping some day we'll get a definitive process for trouble shooting call quality issues from 2600... I understand it's a complex issue. But it'd sure be nice to know what they expect us to do on our side before going to them.

  6. The customer specifically requested they be split. So.. yea, can't do that. Wish I could.

     

    So, update, the APIs will at least allow me to upload a device with it's ID included. I 1/2 expected it to kick that back. I'm feeling pretty confident now. I'll be deleting the old devices from the old account shortly and the devices seem to be coming online ok...

     

    EDIT:

    So, basically, I had a three questions here...

     

    Q1: Will Kazoo allow you to use an ID from one account and PUT it into another?

    A1: Yes, it allows this.

    Q2: Even on the same cluster??

    A2: Yup.

    Q3: Will the fact that there's is an  identicalobject with an identical ID in another account cause any call routing issues. Obviously, it's not best to keep objects in both accounts long term. But, there is some benefit to being able to fall back to the old account if needed.

    A3: No, devices/callflows/ect seem to work fine even with an identical object with an identical ID in a different account.

  7. I've got a client that purchased a whole bunch of companies and brought into our phone system. They are now divesting of a bunch of them and so we are having to move these phones/users/VMs/callflows into their own separate account. I'm thinking about simply GETing the JSON objects our of the source account and POSTing them into the new account. Does anyone know if I can simply keep the existing IDs? It'd hugely de-complicate this if I can keep the IDs.

  8. 11 hours ago, extremerotary said:

    @Rick Guyton

    I believe there is also a parameter when creating a queue, that, if an agent rejects a call, it automatically sets them to away. Again, not optimal, but works. I know that Mark and his team are actively working on giving qubicle more intelligence and visibility into agents being on non-queue calls.

    Yea, I've floated that with my clients and it doesn't go over very well for me at least. They complain about having to constantly watch the portal to see if they've been kicked away.

  9. 49 minutes ago, mc_ said:

    There's a new callflow action, "set_variables", that you can use in Kazoo 4.2+ to set key/value pairs on the call. These will then exist on call events and the CDR under "custom_application_vars". This is probably the saner way to accomplish your goals.

    Man, everything I want is always in the next release. :) Not sure if that's a good or a bad thing. But, yea, that seems a lot more sane a way to address this. I'll wait. Out of curiosity, can you append to existing values? For instance could I have a key "menus" that's set to ":LocationAMainMenuOpt3", and then later append ":LocationBMainMenuOpt4" to that?  This way later, I could split on ":" and know the client originally called location A and punched a menu to go to location B and pressed option 4 there as opposed to calling Location B directly and pressing option 4?

    Or maybe (even better) can I assign a key like "Menu_%Timestamp%"?

  10. 17 minutes ago, Tuly said:

    There's a new option in each prepend, To either ignored the old ones or to add to the old prepends,  I'm not by a computer so I'm not sure what the options are,  but look at the prepare box, 

    Oh, good point, I didn't think about that. That'd make the situation a lot better.

     

    But, I'm still curious about those zero length unicode characters though. It'd be nice to be able to track this by looking through CDRs without it popping up on user's phones.

  11. A couple of our client's systems are getting quite large and we are running into an issue. That issue is we frequently can't figure out how a particular call was routed to a particular phone/user/mailbox. To dig further into this we need to put a ticket in with support to have the logs pulled. This works, but it's not optimal. So, I considered putting caller ID prepends into each menu options. But, some of the menus get 3-4 deep and that's just too many prepends, users would have trouble seeing hte actual caller ID. Then it occurred to me, there's a few zero width unicode characters. I could prepend with those... But if I do that, am I going to break anything? Has anyone done this before?

    I was considering using:

    U+200B

    U+200C

    U+200D

    U+200E

    and

    U+200F

×
×
  • Create New...