Darren Schreiber

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.

This is very helpful feedback, thank you. Let me discuss again with the team.

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.

I guess we could do that, but there's no automated background script to do it. So you would want us to allow E911 provisioning, and then you'd come in again and save it again post port-in to re-send it to the upstream provider upon port completion?

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.

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.

If the existing provider does not use our same service provider, than no, that is not correct.

OH! Yes I think that's a good idea, except don't forget they may have already hooked up their phones to our system if you're giving them new phones, so if they dial 911 the right Caller ID transmit but there will not yet be an address assigned to it.

That was our assumption, too. For a long time. And it generally works. Except when it doesn't. :-) Which is the problem. The issue is, if the OLD carrier happens to ALSO use the same 911 provider as we do, and the OLD carrier complains about the data being wrong or requests the data be removed when the number ports out, the carriers sometimes screw up and erase our settings (or their system can't handle the difference between the accounts and erases our settings). Thus, we lose the E911 provisioning. But we think it's still provisioned, so we continue to show it as such in the portal. Of course you only find this out once the customer goes to actually dial 911. EEK. Nasty. Which is why we're putting an end to this. Soooo with all that in mind, I'm all down to optimize the crap out of the port process and automate almost ALL of it EXCEPT the part for setting E911. Which I really think, for sanity, we should ONLY do when the number is owned by us and the port completes.

It's frankly even worse than that actually. The reality is E911 doesn't come from the upstream carrier at all. It is overlayed by a third-party carrier (bandwidth happens to have purchased Dash but it's still run as a separate service). Imagine 911 being a completely different company. (In fact, if you wanted to, you could simply buy 911 and never buy minutes at all!). It has nothing to do with the phone number you bought OR the service you have OR where the service currently lives. Instead, when you dial 911, we send the call to a special company that is NOT the normal carrier. (This is what everyone does in VoIP). THAT company then ships the call to a PSAP (Public Safety Access Point) in the area where the Caller ID is set. So when you are setting E911, it has absolutely nothing to do with the port or the number. Heck I can set E911 on the whitehouse's main number right now if I wanted to. And that's exactly the problem :-) We have no ownership of the number, and someone ELSE might ALSO be setting E911 during that time period/window while the number is being transferred. This can cause various issues. Thus, we really should not be allowing E911 to be set until we are sure we actually own the number.

I am working on a guide to "how 2600Hz recommends setting up, and testing, new clients" and also some recommended firewalls. They are old asks that I think we are comfortable answering with more confidence at this point regardless of the installation type. This will be part of that.

One sec though... We get billed for internal customer to customer calls? Maybe I read that wrong? > Yes, across customers you do. People have complained about this but actually the code change required to fix this is like $20,000 worth of work, for a benefit of usually like $0.30. And we then eat bandwidth costs, which will grow as we end up with video. So we'll probably change this at some point but right now it's just something that irritates people but is low $ that we're not going to change (or, if you are calling a crap-ton across our system without the PSTN, then frankly you should pay because you're chewing up bandwidth). Twilio today deals with this by charging $0.0025/min for SIP to SIP calls, which is an option I'd consider. Bottom line is PSTN is only part of the resource calculation when making calls. > We DON'T charge for extension to extension within the same account. Oh one other followup question if I could. When I setup a webhook for call distroy, it looks like I get all of the lose_race call destroys from call groups. Any way to eliminate those?    > This seems like a different topic, can you post in a new thread plz?

I believe we take billing seconds from either the time we detect ringing or the time of answer. But total call duration should always be higher for processing time (or ringing, can't remember). But that should be the differential. The only exception might be on a transferred call, where one of the call legs may have a lower duration but higher billing but I believe since we always bill on the PSTN leg and you can't transfer the PSTN leg that issue actually should only exist for internal customer to customer calls (so i.e. very rare).

Honestly messing with the E911 logic is about as attractive as getting a root canal. If we break any of it, we get blamed, so while it may be more convenient for you, it really is less risky to just ask resellers to, on the day of the port (When you're confirming the port was successful anyway) re-check 911. You should be dialing 933 anyway as soon as the port completes to verify that the 911 address took to start with. This is the best procedure out there to be sure things are really correct. I'd rather save you time/energy through automation via the porting process itself, which is what we're currently focused on. While your idea is sweet, the implementation is a nightmare and the risks are very high if anything goes wrong (And all of the risks land squarely on our shoulders i.e. labor costs).

Hi Rick,      The goal is to have instant access to config EXCEPT E911 until the day the number ports for E911. Then it will be just as fast (or faster) than sending it in as a ticket.

"In any case I want to be able to configure E911 right away without having to configure a temp number and then later configure the actual number." This is actually not going to be allowed much longer. Basically we can't guarantee the E911 update works properly if another company has the number still with the upstream provider, but the upstream provider is the same despite it "porting". This is an edge case we've run into and is a big problem and has nothing to do with us frankly. The upstream provider clears the E911 after the port and then we have to have a way to re-apply it without knowing they did that.

Yup, this is agreed. It was actually an internal miscommunication (see Karl's comments about it previously) where that is how it was SUPPOSED to work, but apparently it's not actually doing that. We're working on that (and retooling more bugs in the port tool). Net - net, we need people to start using that tool. Why? It allows us to integrate into automated ports so there are less delays in processing ports and you're in direct communication with the provider when there are issues. It takes us out of the loop (saves time/money) and speeds up your port submissions (yaaay) and also avoids errors (our guys can't "typo" things) and fixes billing. So the advantages are high, but yes, the experience needs to be more functional, so, working on that. One step at a time.

Hi, sorry, we have some enhanced call recording features coming out that are way more flexible then the current call recording stuff, and also have a GUI, and AWS integration, etc. etc. Some of this was demo'd at KazooCon. The GUI isn't done and neither is pricing, so I was really just commenting that you're giving me ideas on what would be acceptable. But that said we are NOT ruining or removing the ability to do what you're already doing, and if you want to continue to build out your own call recording solution you absolutely can. In fact nothing we're building ourselves can't be done by you, too. So the real difference is, you can choose to pay us for a "pre-packaged" call recording solution (not just storage but linking to CDRs, on/off dynamically, etc.) or you can build it yourself. So there's not really any restrictions on what you can do, the question is do you put your own labor and customization in (and thus it's "free"), hire someone to do it for you (in which case you pay someone else) or pay us a monthly fee for having done it for you. I believe that's what we're discussing re: call recording. All the above said, I'm intending to confuse you :-) All of this is premature because no decisions have been made on the new call recording stuff yet. What I was trying to point out is that OVERALL, for all features (new and current) in the system, we need to do a better job covering our costs. Thus, I'm looking for better ways to spread out those costs amongst features people are willing to pay for. People don't actually WANT to pay for some things that cost us the most money to do and DO want to pay for some things that are just more convenient for them. So, like any business, we've got to figure that out now. Thus, the call recording question pricing/comments - you're giving me insight into your thoughts around what things should cost. Ultimately if you don't feel you can sell it at the price we're offering it, then you won't sell it. If you don't sell it, we don't sell it, thus we don't make money either, thus we fail to cover our development costs. So we have an inherent goal to ensure we're pricing things both competitively but also in a way we're neither of us are getting screwed. (We may not be thrilled with the cost either but it should be manageable).

You'd prefer a minimum over a base fee? That surprises me. OK, let's see what we can do!

OK, stay tuned, let me see what we can do!

OK, so we should lower the call queue price and start charging for call recording then. Good info to know. Let me take this back to the team and I'll see what we can do here.

@Rick, sorry it's confusing. Maybe we make it simpler. Our system has the ability to do tiers. What we DON'T want is resellers who sign up ONE QUEUE ONLY and yet still demand features, support, documentation, etc. It's just not worth it unless the price is either higher, the feature set is smaller, or we can guarantee we won't lose money handling all their requests (labor is our biggest cost, like yours I imagine). Based on feedback from FastDevice the big sticker shock seems to be around the $499/base. So I am going to work internally to see if we can lower that significantly and then instead charge a higher fee per agent. That said, your perception of it being only worth $5/agent seems out of touch. Most vendors we know get at least $10/month additional out of the combination of call recording (which, yes, you can already do) and call queues alone. And they charge that on ALL seats just to have the feature turned on for a single account. So a 10 person office pays $34.99/seat for example for access to 5 agents and 1 queue, BUT in our case the reseller is paying $12.99 + $3 ONLY on the users who are configured as an agent, which isn't all 10 people. Thus, you can sell a deal for $349.90/month but if there's only 5 actual agents, and one queue, it's costing you ($12.99 x 10) + ($3 x 5) + ($20 x 1) = $164.90 . So on a $349.90/month deal you're making $185. Three of those and you've easily made back the base fee. Nonetheless, I'll see if we can't do a ramp strategy so the base fee is less up-front significantly but the per-agent is higher, and then you get the benefit if you add seats of a lower price with more agents.

Getting some good pricing suggestions via email. Like it so far, thanks guys :-) So what if we did tiers instead? I have to make sure we can do this. Basically lower base fee but higher per-seat charge to start, then the seat charge goes down as you increase in volume?

OK, thanks. We are working on releasing the other items at KazooCon too like operator console, call recording, etc. so that may help.

Please note that we are trying really hard to communicate more with monthly newsletters and asking for feedback. Rather then dismissing our new pricing and apps outright, please give feedback instead. "This price is too high, I was expecting XYZ..." Things of that nature. Assuming you're reasonable, we'll work to take them into account, but we need the feedback. Hopefully you do that before just running somewhere else.