Jump to content

Darren Schreiber

Administrators
 View Profile  See their activity

  • Posts

    1,202

  • Joined

  • Days Won

    27

 Content Type 

Profiles

Forums

Resource Library: Monster UI Apps for KAZOO

Events

Downloads

Posts posted by Darren Schreiber

  11. Call Queues, looking for competitve solution

    in Product Discussion

    Posted

    OK, works for me.

    Let me talk to Mark about removing the dashboard altogether, BLF light status for agent login/logout (since this is costly to us to maintain anyway), custom hold music, the works. I'll see what it would take to make a stupidly dumbed down version of what we've built.

    So then you'll have two options.

    And we'll continue persuing yet a third option, which includes the reporting, CRM integration, screen pops and eavesdrop/whisper/barge and we'll mark those up as the "high end" product.

    The HUD product is a totally different discussion, has nothing to do with call queues.

    Good stuff. Thank you for sticking with me here and sorting out the details until I understood.

  12. Call Queues, looking for competitve solution

    in Product Discussion

    Posted

    I will work with the team to remove the dashboard component's live updating and some of the features, then remove the queue price. By doing that, we risk less work to maintain the special queue functionality we have, so you can meet your price point for your client. I can't guarantee my team can accomplish this because now they have to, ironically, program MORE stuff (which costs more money) so that we're capable of delivering less stuff, but at the same time if it keeps users and customers happy, I guess that's what we have to do.

    And that way there's an upgrade path as well.

    Thank you so much for all the feedback. Despite my frustrations, which are no doubt quite clear in this thread and based solely on how much time and money we spend on our work and feeling a bit under-appreciated for it, I actually really NEED the feedback and appreciate it.

    We will find some happy medium.

  13. Call Queues, looking for competitve solution

    in Product Discussion

    Posted

    There are a lot of things that confuse me about your reply. The conference call thing - it certainly seems to be treated like a secret! We were literally asked NOT to join. Weird. We beg for feedback, get none or barely any, then hear about all these "complaints" via some secret conference call. Why aren't you sending these people here to talk about it? So unbelievably strange. I don't even know what to say to that one.

    Anyway, as for the call queues thing, maybe I'm just not understanding you. We're trying to sell a call center product. It seems like you just want "queues". So if there is an element in the advanced callflow tool that lets you queue up callers and then ring whoever is available next, and that's IT, no other features (no custom hold music, no reports, one ring strategy, etc.) then maybe what we do is make a second version of this that's super, super, super basic and make that the cheap tier.

    If that's the hangup, OK, got it. Let me go back to the team again and see if we can make another version of call center. We called this one Call Center Lite because we know it already lacks features people expect in a call center you pay for. But if you're going to compare us to FOSS stuff then perhaps what we do is provide a "Call Center Super Basic" that has almost no features, no support services, and a really crummy UI textbox like FreePBX has. Then we'll at least be talking apples to apples.

    Let me stew on this.

    But also, you said "For me it's all about the long term vision. To me, I need to know I can get under$5/agent including average queue and flat costs eventually."

    We literally took that and made the pricing $7 at the high end, $3 at the low end, BEATING your price target, with a $99/month base fee. So we literally gave you your pricing. We set the $7 tier pretty low.

    What am I missing here.

    We effectively just offered you MORE features than you're asking for so you can go IMPRESS your client, and you're still complaining about the price? I literally have to be missing something here...

  14. Call Queues, looking for competitve solution

    in Product Discussion

    Posted

    Also, @Matt, a few notes on your comment specifically.

    "The open source model allows us to contribute with code instead of with $."
    We are working on a way to trade time spent on docs or code for money that you can then use to get licenses for free (or cheaper). I am happy to look at what you've contributed and use that as leverage to knock the price down (or make it free for you). I absolutely agree, if you've helped us with code, it's a big deal, and we want to reward you. We have a new system for forums I'm trying to launch that actually lets you do just that.


    "I always thought giving us that option was honorable, righteous and it feels like whining, and asking for something for free so I can go out and make money."
    It IS whiny and self-righteous :-) But I understand that comes with the territory. I also have the right to set boundaries. If you all are going to go out and use our work to make money, it seems like once in a while that bounty should be shared. We are not restricting or preventing you from using the base product yourself, or building your own version of call center, nor are we against other people making competing products in ANY way. If theirs is better, great! We'll offer it, too, and stop offering ours, because hey, I can go work on something else. There's plenty to do in telecom. Always been my motto.

    "But, hey, thats the industry we are in, when Mark released Asterisk for free, he changed the game, and the VOIP market subsequently is what it is, its rooted in open source.  "
    That one is a huge reach:
    a) Mark did not release a full PBX product, he released a library + an engine. We are releasing the full product. It's NOT the same thing and most people who release a PRODUCT (even with Asterisk) charge for it, because the complexity, support and other maintenance requirements increase dramatically.
    b) FreeSWITCH also has queues, and we use FreeSWITCH. You're welcome to add a small adapter to just go start using FreeSWITCH queues. So your "loudness" is unwarranted, you have a perfectly reasonable alternative available to you.
    c) Mark also started a company called Digium as his business model, where selling cards would support Asterisk. Because he needed a way to support the work he was doing. He didn't JUST give it away for free, he found a way to continue supporting said free software with some paid income while leaving the free stuff available for people who don't want to pay. We've done exactly the same thing here. You are not required to turn on, or use, our call center. You can use, build or link to your own. Nothing has been crippled.

  15. Call Queues, looking for competitve solution

    in Product Discussion

    Posted

    I would entertain one-time fees for some fixed license or something. Is that what you're looking for? Sounds awesome frankly, I'd love to get the larger cash funds up-front. I thought you guys all wanted monthly fees that were small.

    OK.

    That actually sounds even better. If you are willing to do that immediately, drop me a note. darren@2600hz.com

    Tell me the specifics of what you need. Indicate what your past contributions were. That will go a long way to lowering the price because it means you've got skin in the game, too, which is a big deal for us. We get VERY FEW contributions considering the amount of code we work on and maintain. I'm happy to figure something out. Happy to do one-offs.

    The goal is to pay for our work, plain and simple. I'm trying to work with you guys here, all you're doing is yelling and calling us names. Ugh. We give away $6 million of labor toward the software we build and now it's "but why isn't THE REST ALSO free". Well, simple, we have bills to pay, too.

    I have to be able to pay our staff, or you get NOTHING - literally, and that's not my fault, that's called life. If the staff don't collect a salary they can't feed their kids and they can't eat. We need a source to pay them. Contributions don't provide that and, frankly, we don't get many of those anyway. But if you've contributed a lot, then I'd be happy to trade, too. Labor cost is labor cost, regardless of who does it.

    So, pick your poison.

    But, really, you can't on the one hand say "we support you so much" then on the other hand when we actually need you to support the things we do because they cost a lot of money say "OMG WHAT IT COSTS MONEY?" Ridiculous.

    If there's a middle ground, let's find it.

    Rick you literally were the first one to write me saying how you wouldn't be able to feed your kids if BLF didn't work 100%. Well, back at ya, buddy. I was considerate and sympathetic to your plight. You seem completely unsympathetic to mine. And now on top of that, after I took your feedback and lowered the price (at the risk it will take longer, or possibly be never, to get paid back for our work), you're saying how we've somehow wronged you. Your behavior is pretty telling if you ask me. This is on TOP of the fact that you continue to maintain some secret group in the background where you try to get people to gang up on us and our product. *sigh*. Getting kind of tired of this frankly.

  17. New Porting App Feedback

    in Product Discussion

    Posted

    Your suggestions are always welcome. They are taken seriously.

    I will note that many suggestions focus around "small things." May seem glaring to you but overall they won't move us as a company, or you as a reseller frankly, forward in the market in the long-term. If we spent all our time on the suggestions you note, we would probably have an amazing set of existing features while falling completely behind on new features.

    So, like most things in life, there's a balance. It means nobody is ever perfectly happy, but we progress on the "small stuff" and the "big stuff" at the same time, based on resource availability.

    Thus, we won't always be able to fix the "things that make resellers lives easier" features without also scheduling things that people aren't even necessarily asking us about yet but are probably 1+ years worth of work so we need to be strategic and get them started.

    This particular conversation revolves around porting. Today, we spend $82,000 a year processing ports (just processing them). This number is too high based on our volume. I'd estimate we port-in about 10,000 numbers annually, so that's $8.20/port (we charge you $5/port). So, clearly a problem. Hence, the energy is now on porting. Thus, if we can pair the feedback with the financial goals and the overall objectives of porting in general (i.e. fixing both nuisance and functionally broken items), then everyone wins.

    So we take your feedback to heart, figure out it's cost + value, measure it amongst other cost/value scenarios, and go from there. That's why we don't provide ETAs, those values change often frankly. But they do eventually get done.

  18. New Porting App Feedback

    in Product Discussion

    Posted

    This is already in progress.

    1) The monthly webinars. The next one is already announced, you should sign up. We'll use half the webinar to present a topic we think is going to be interesting, and the other half for Q&A on, well, pretty much anything. You should have already received a notice about the next one. We did these last year toward the end of the year but stopped when we got too busy with 4.0 launch but frankly they were supposed to have stayed at once a month. We just only had so many staff to plan them (and they take a LOT of planning). But we intend to pick them back up and keep them consistent. Please do come to those!

    2) Re: up-votes, I intend to bring back JIRA's voting system and use loyalty points to allow people to "spend" the points on votes. We are working on such a system. Your points are based on your contributions to the product and/or forums (you earn points for helping others) and/or the amount you contribute financially.

  20. New Porting App Feedback

    in Product Discussion

    Posted

    Not sure what you mean. In general, when a call comes into the system we have less than 1 second to process the call before we risk the carrier giving up on the call and thinking we're down/not working. Thus we always must avoid any processes that "block" during call processing.

    When a number is in "port in" state and the IP is from an outside carrier, we quickly adjust the number document to "in service" because it means the port completed and we know that our system's database queries have to respond in a few milliseconds so there is no risk in requesting a database document update on our side. Thus, we can afford to change the state during inbound call processing.

    We also already have an email queueing mechanism locally (postfix) so connecting locally to postfix and queueing an email (even if the email itself takes a while to go out) is quick, so we can do that.

    But calling an external API (which is what you're calling "push the button for us") and asking them to update the E911 address information while the call is still being processed requires us to wait for them to reply (and then we record their response for legal paper trail reasons - we have to note that they accepted the address and provisioned it - so we must wait for the reply). That might take longer than a second, thus causing the call to fail. We could potentially build a queueing system that queues E911 update requests so that the call processing just puts something into the queue and they're re-processed later but now you have to build and manage a queueing process for E911 requests, something we don't have today.

    So what you're stating as "push the button for us" is a gross over-simplification of the feature request you are asking for, thus driving up engineering work/labor/costs for the whole system for the sake of convenience.

    Is it that hard to just re-provision and check 911 after the port completes? I do not think the technical challenge is worth the reward on the automation front.

    Another option, it's probably $5k of work to build a queue-based E911 re-provision system and some cost to maintain it. If we did what you're suggesting Rick, would you pay an extra $2 on port completion (one-time) to have it auto-re-provision? We certainly handle 2,500 or more ports a year, so THAT would pay for itself... Then I could see the value here. And $2 seems like a pretty insignificant fee for the assurance you are asking about.

  22. New Porting App Feedback

    in Product Discussion

    Posted

    No, there's no central database (unlike Caller ID Name).

    You are correct, however, that Caller ID NAME lookup works that way - it looks at whoever set it last globally - regardless of the carrier. But not E911.

    With E911 the address info is transmitted by whomever processed the call to the PSAP, which in our case is generally either Intrado, Level3 or Dash, and it's up to them to get it right. And sometimes during the port process they seem to screw it up (like only 1% of the time). But it's not worth the risk.

    So, that's why, again, if we're going to save people time and effort while improving the process, I'd rather:
    * Automate generation of LOA and RespOrg forms that you give to the client and apply your white-labeling automatically
    * Automate validation that the area you're wanting to port TO is serviced by us
    * Automate submission of those forms once you send them back, all the way to the upstream carrier (saves possibly 12-24 hours of processing)
    * Automate responses from the carriers direct back to you
    * Intervene on our side only when you actually need our help and we add value (saves you time and us time & money)
    * Eventually get E-sign enabled with the above so we can avoid needing physically signed documents

    The above should save lots of headaches. To the point where the only step post-port will hopefully be E911.

  23. New Porting App Feedback

    in Product Discussion

    Posted

    That's not how it works.

    The PSAP does get the call, yes, but they get the address information about the caller from whoever sent them the call (the company we contract with). They are paired together.

    Example:

    You port a number to us from RingCentral. But RingCentral is really using bandwidth.com and Dash E911. We are also using bandwidth.com and Dash E911 for this port. RingCentral has configured the number with an address. You go into the portal and configure a different (or the same) address on the number but we don't own it yet. It's POSSIBLE that when RingCentral releases the port, they contact Dash and tell them to remove the E911 mapping. Dash is SUPPOSED to be smart enough to NOT delete what we put in and only delete RingCentral's data. But, sometimes they screw up, and they delete the data from both. Meanwhile, we think E911 is actually set, so we show you the setting on the screen showing it's set. But it's not. Fail. When 911 is dialed, Dash transmits the info to the PSAP with number + address, except there is no longer an address.

    Another example:

    You port a number to us from Verizon. Verizon has their own interconnects with PSAPs via alternate parties. We use Intrado for our 911 on this particular number. Verizon sets an address on their equipment. You do not set 911 address on our portal (so it's not set on Intrado). The customer then dials 911 from their new VoIP phone. Well, we route that to Intrado, who locates the PSAP and sends them the Caller ID + Address. Except there is no address. So, no E911. Even though Verizon still has the address paired with the number, that's via THEIR provider on THEIR system, not Intrado.
×
×
  • Create New...