Rick Guyton

Hey guys, I'd like to create an app that will allow us to rapidly deploy new accounts. Basically the app would take a few settings like realm name, local or global carrier, number of trunks to assign and possibly numbers to begin porting on. Then, a CSV for each device that contains columns like device name, MAC, Make, Model, Presence ID/extension, UserFirstName, UserLastName, UserEmail. Finally, checks it for sanity and conflicts and applies the whole bit at once. This is a little bit more than I can bite off myself at the moment. So, I'm curious, would anyone be interested in purchasing an app like this if I were to bring in some help for development? If so, what would you think was fair on a per device basis for a service like this? Also, am I missing anything you guy's want in there?

How could we notify the customer if they get logged out so that they know to log back in? AFAIK most FOSS queues statically assign users to queues in the config. There's no logoff/on. Maybe we could get an email? Like: Subject: You have been logged off of Sales Queue Body: You have been logged off of the sales queue due to inactivity. EDIT: Just looked at Matt's list and that'd about do it. If we had webhooks for queues I could generate those emails myself. Seems weird that custom music would be removed. But, I could work with that as long as it defaulted to the account music at least.

So, if there's no BLF status, would you just have the phones permanently logged into the queue?

Why not do a no-dashboard at all option like you were talking about above? With a crappy text box that's basically used 100% via the phones themselves. That's what I've been trying so hard to get across. A lot of us are doing 3-20 phone installations. A lot of them. those clients don't need and don't even want to load up the HUD. I know once I'm more comfortable with the service, I'm going to start going after BIG call centers. (that's why I'm working on a rapid deployment tool BTW) They will want and need the HUD and reporting. And they will pay for it willingly.

The queue price is $18 man. So it's $18/queue + $7/agent + $99. Take away the per queue cost and I'm pleased as punch

Ok, I'm just going to ignore the personal attack there. But, yea I'm in transition right now. I just divested in my MSP company, made a huge leap of faith in the 2600hz platform and my margin right now between when my family needs and what I make is uncomfortably close. I'm not super proud of that. But, you are right there. Then, right when there was no going back for me, my biggest client was seriously talking about moving away us/2600 because of BLF issues. So, yea, I was freaking out a little... If you think I'm running some secret group to gang up on 2600hz we need to talk man. I help people out where ever I can and people feel free to call me with all sorts of issues they have. And I like to help out if I can. Most times we don't even talk about 2600hz. Often its networking stuff, faxing stuff, business plans or cool tangential services we can offer. But, I also hear a lot of complaints. I thought I was helping giving you guys a heads up when I keep hearing the same thing over and over. But if you guys are interpreting this as me CAUSING instead of REPORTING issues or if I'm aggravating things that's not my intention and I'll stop immediately. There is a monthly conference call, that I got rolling originally, but I'm not the one who sets up the call or the time anymore. In fact, I haven't even been able to do it anymore because I can't do the day of the week. >after I took your feedback and lowered the price Verbatium the email I sent Patrick about the pricing: "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. Maybe I need to have 300 phones on the system before I hit that. But, then that's just a number I have to hit. Right now, for me personally, both of these options serve the same purpose. To fill a short term problem that's preventing me from fully landing 70 more phones with my ***BIG CLIENT***client and allow me to start selling on that feature. More widely, from the resellers I've talked with they have a problem with the a /month+ b/month + c/month style pricing and they want you guys to "pick one". Even boarder view, I think there is a huge gap between what you built (awesome beyond words, and really worth every dollar you are asking for it) and what many of us really needed. Many of us just need to have callers go into a queue and have those calls round robin to agents as they become available. We don't need a HUD or real time call control or the fancy reporting you guys are talking about. We just need super simple queues like all the other FOSS solutions have already. And I'm not sure the value for this more basic need is worth what you are asking. I'm not saying there isn't a market for what you guys built. I do think it's there. But, I think many of us are going to have to get more comfortable selling much bigger accounts than we currently are before we are going to hit the market that wants the HUD and fancy reporting. Just my $0.02. Maybe too much info. Call me if you have any questions: ***My Cell***" I tried to call on the front end to talk, but he wasn't available. I get it he was busy. I also left my number. Maybe I didn't convey it very well, but the old and the new pricing are pretty equal to me. Basically, they both are nearly equally unfit for my needs. Because I'm concerned about having some way to be profitable on the service eventually. But, I do think you will have better luck with some of the other resellers with it. At least I hope so. And I was going to do it either way because I figured out how to make it work, because I have to. >You seem completely unsympathetic to mine. Honestly, I can't relate to spending $6 million on anything. I really wish I could... I know it's got to be a ton of pressure. I don't know what numbers are going to make that work. But, I know that with both of the pricing plans you offered, I'm going to have to sell it at a loss. Even at scale. I can't do that forever... > would entertain one-time fees for some fixed license or something. I'm not sure if that was to me or Matt. But if it was to me, I am curious what that number would be. You know things are tight for me, but if I can make it work I will make the additional commitment. I do still believe in the platform. And the only thing that made me really waver was the BLF craziness.

Yea even with the new pricing they released I feel like they are way over valuing it. It's true every other FOSS solution has basic queues built in. It's a shame really. I feel like they would have had much more success releasing the core queue capability and upcharging for the sweet HUD I've seen and the reporting they are talking about. It's putting me in a bad position personally. If they don't wake up on this pricing thing, I'm going to need to write our own queue service eventually. Or buy that guy's that's asking $3k upfront and maintain it myself. Then once you have it, it's hard not to want to sell it to others.... and well that's just going to get awkward fast. And I just don't want to go there, but I feel like my hand is being forced...

Yea even with the new pricing they released I feel like they are way over valuing it. It's true every other FOSS solution has basic queues built in. It's a shame really. I feel like they would have had much more success releasing the core queue capability and upcharging for the sweet HUD I've seen and the reporting they are talking about. It's putting me in a bad position personally. If they don't wake up on this pricing thing, I'm going to need to write our own queue service eventually. Or buy that guy's that's asking $3k upfront and maintain it myself. Then once you have it, it's hard not to want to sell it to others.... and well that's just going to get awkward fast. And I just don't want to go there, but I feel like my hand is being forced...

Where's the webinar signup? I didn't see any thing come across from eventbright.

Yea, I was hoping I could pull something resembling real-time CDRs off the webhook. But, I think I'm better off just downloading CDRs at night.

I setup a channel_destroy webhook and I'm getting a lot more responses than I was expecting. I'm getting a bunch of lose_race hooks. This makes sense I guess because a lot of my callflows dump into a call group and technically, I guess you are destroying a channel whenever one of the attempted legs of the call groups looses to another one. But, is there any way to filter this so that I don't get all of these unnecessary (in my case at least) updates?

Have you tried hitting * while the VM outgoing message is playing? You can then enter the PIN and gain access that way. I think you can change settings this way too But I'm not 100% sure on that one. I know you can play back/delete voicemail this way though.

Just FYI, a lot of the things I bring up are intentionally small stuff. Because I don't want to burden you guys with anything that I can do myself. It's a credit to your platform and why I love it really. All of the big stuff I want to do, I already have 99.99% of the ability to do now. There's just some sticking points here and there. I'll use the building analogy you gave at KazooCon. I'm effectually asking you the bare minimum I need. I'm not telling you that I'm building a waterpark with a wave pool on the 5th floor. I'm telling you I need 10 more PSI in the pipes, 10,000 lbs more support in the floor and a 6 inch drain pipe for my floor. :) The whole reason I brought this thread up is that I want to build a rapid onboarding tool for us. There's so much to do when making a new account especially if the new account has multiple locations. But almost all of this can be boiled down to an excel spreadsheet. My vision is to be able to onboard any account under 100 phones and 3 locations in a day by importing the sheet, drop shipping the phones and going onsite to train. To get where I want to go, I can't keep chugging away setting everything up with a macro recorder that literally copy/pastes from an excel sheet and clicks buttons like I have been doing. And mentally keeping track for a dozen different steps and where each location is in each. Making the numbers available immediately upon port request allows me to set everything up instantaneously. And being able to pre-provision 911 removes a ton of logic that I need to apply otherwise. Additionally, this will be hugely helpful to many people even if they aren't using my app.

> This is very helpful feedback, thank you. Sure about that? I feel like I'm a PITA for you guys sometimes (most times). Lol

> Then I could see the value here. And $2 seems like a pretty insignificant fee for the assurance you are asking about. I certainly can't speak for everyone. But, personally, hell yes. Currently this is what I have to do: 1) Get a temporary number and forward the clients lines to the temp number 2) Set 911 on the temp number 3) On each and every device, set the emergency CID to the temp number and outbound CID to the main number they are porting in. (So that their client's dont' get their temp number and 911 works right) 4) Submit Port. Wait until I get the porting email... 5) Request numbers to be put into the account. Wait... 6) Once support pre-populates the number, go into SmartPBX/AdvCall and put the pre-populated number into the callflow. So that calls will completed when porting completes. 7) Wait for port completion. 8) Setup 911 on the real number once port completes. 9) Go remove the device settings I put in in step 3. 10) Remove temp number from call flows/delete it. So with the combination of your $2/number service & immediately getting numbers when the port is submitted. This is my new setup procedure: 1) Submit a porting doc and immediatly get my pre-populated numbers. 2) Configure everything right from the start. 911/callflows/everything 3) Stick a temporary number in SmartPbx/AdvCall to get inbound calling working 4) Remove the temporary number at my leasure after porting completes. EDIT: I mean, Maybe even charge $5 for the option to pre-provision 911. That way those of us who find value in it, can pay for the convenience and those that are in a position of needing to watch ever nickel and dime can. An you guys only need 1/2 of us to pick the option. EDIT2: and honestly, I'd like to pretend like I'm a perfect robot executing my current procedure. But I know I miss stuff. It's just too much to keep track of. I've forgotten to apply the numbers to smartpbx once support pre-populated them and cause my client an outage when port completed. And I know there plenty of numbers that were temporary at one point. But I can't remember for sure if they were temporary or not now. Just two or three of those forgotten temp numbers would pay for it

I mean I could I guess. But why not just ride the port completion notification event and "push the button" for us? Hell I'll let you use my aws Lambda instance.:) I mean cover your ass by saying we need to test and verify it with 933. But help us do right by our customer and make sure they have 911 setup and it's not something we have to remember to come back and do later.

Ok, I'll ask the stupid question I guess. Why not allow us to provision e911 on (in dash). Then just resend the 911 provisioning API call to dash again upon port completion?

Thanks Darren! That makes sense. One sec though... We get billed for internal customer to customer calls? Maybe I read that wrong? 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?

So I'm playing with some webhooks and I noticed that there's two variables billing seconds and duration seconds. Can someone explain why these aren't always the same? Is 2600hz not billing for some portion of calls?

So, a thought... What if you extended the porting app to become aware of a temporary number. So, for instance when I put a port in for 480-123-4567 and 480-234-5678, the porting app offered me a temporary number of say 480-345-6789 or whatever was available from a 2600hz carrier and asked me to configure 911. Prior to port completion, you know to re-route 911 calls from 480-123-4567 or 480-234-5678 to the 480-345-6789 number. After port completion, you can copy 911 settings from 480-345-6789 to 480-123-4567 and 480-234-5678. Then, remove the number. Sweet huh? :) I could almost do this myself. But, that 911 redirection thing would have to be internal...

Yea, I've done that, but it's just more and more steps to keep track of. With the old ticket based system, I'd just send me client a form and when they went it back to me, it was ready to send to 2600, old bill and all right there in the zip file. Now I've got to transcribe all that info into the app and upload the PDFs separately. (more steps) and I have to make a separate request after the port starts to get the numbers available. This is on top of keeping track of the temporary number and setting up the 911 after poring completes. I was just really hoping that as a trade off for having to transcribe the info all myself, I'd at least get instant access to the numbers for config... Oh well.

So, I've been submitting my ports via the porting app. And I'm not loving that the numbers aren't available for assignment until after the port completes. Optimally, I'd like for the numbers to be available as soon as I request the port. Or, at the very least once we have a scheduled date for the port. This way, I can very efficiently setup a client in one shot. As it stands right now, the numbers only become available once the port completes. Maybe I'm missing something, but doing it this way forces the client to have a full system outage... Yikes...

Yea, I was trying to make sense of Darren's comment about "we should charge for call recordings". Charging just for the ability to do call recording's doesn't make any sense. So I'm guessing he's talking about reselling the AWS storage at a small markup. I mean I'd be down with that personally.

Yea, I get the "we have free storage already" thought. But, wouldn't you pay say a 10-20% markup on AWS fees to have it all done securely, transparently and on AWS's highly scale able infrastructure? AND get the ability for clients to then use a built in app to play those files of AWS. Hell, I would in a heart beat. We all need to make money, 2600hz included and that's a lot of value in my mind... Again, not trying to speak for everyone. :)

Well, yea. In the base fee senario, I'm still paying the $500 a month, but it's not really getting me anything. It's just turning the app on. In the minimum scenario, my costs are at least going to pay for the queues. So, at 30 agents, I'm still paying $500/month. As opposed to $590 for base fee + per agent costs. Even if you had a solution with a lower base rate with the agent cost + queue cost, I'd still rather pay a minumum on a straight up per agent cost. Then I know that I have a clear pathway to be profitable on it. The per agent+per queue+the flat rate thing... the only pathway I see to profit is to code out a replacement using pivot and real time call control eventually.