Bridging two or more Kazoo/ Monster accounts

[FASTDEVICE]

I have several clients asking we bridge their offices together.

My preference is to keep their offices on separate accounts as to offer them independently the flexibility they need without complicated combined callflows.

The though is to have a way to dial directly to another account without assigning a DID. Preferably a device that can be configured with: <account>/<extension>.

Any thoughts on how this can be done?  

[Rick Guyton]

I've been wanting this forever too. It'd be amazing if accounts could see eachother's BLFs and easily transfer to eachother. It would also resolve my bigges frustration with SmartPBX, that it doesn't support multi-location. We could just create separate accounts for all of them, then bridge them. 

I don't know about you all, but I'm willing to put my money where my mouth is on this one. I wonder how much it'd take to get 2600hz to develop this...

[Darren Schreiber]

This is such a HUGE can of worms, I don't even know where to begin. Allowing people to cross-subscribe BLFs and transfer to each other, how do we now make sure the account really applies to you, the reseller? This would mean adding additional code and database load to make sure on every single action the system does we don't just authenticate the account but we check to make sure everyone is under the same reseller. Huge challenge.

Plus, let's say account A wants to call an extension in Account B. So Account A dials a number. We check all numbers in Account A, no match, so then we check Account B, no match, then we bounce back to Account A to process the no_match rules?

What if both accounts have pre-flows set? Which one do we run? Both? What if they conflict?

And worst of all, how do we teach all the administrators all of the above edge cases (and the countless other ones that exist)?

How do you manage credit across two independent accounts for a company that wants to be treated as one?

I could go on.


I think a bigger solution is simply to allow multiple receptionists on the same account. Which you can already do via advanced callflows anyway. Then perhaps we add a field called "location" to each device or user and record that with CDRs, so you can report on how much each customer spent based on location, in case a location wants to be billed independently.

But splitting the accounts and then allowing features between them is a huge nightmare - security, complexity, training, the whole nine yards.

[Rick Guyton]

Hi Darren, I'd imagine that you wouldn't try to make sure both accounts are under the same re-seller at all. I'd think you would setup a "secret key", maybe use the existing API key value of an account. Then, when you "link" accounts the account exchange secret keys and have access to each other. At that point, they obviously have an affiliation so what does it matter if one is a CleaRing client and the other is a Slable client? As for call flows, I see that issue. I'd imaging you'd have a "feature code" for accessing another account. Like Account A would subscribe to AccountB#100 for a BLF to see BLF for ext 100 in account B.

Of course, I say this as someone who's never even looked at your code and has a basic understanding of the architecture. And I get that.

I see two separate use cases here. First is for a single company with multi-locations. For them, really it'd be mostly about using Smart PBX. Man oh man it's hard to convert someone from using Smart PBX to ADV callflows just because they add a location. They hate it. Second though is separate companies that want to be affiliated for some reason. For instance, I had three clients that shared adjoining suites. They relied on each other heavily and wanted to be able to page/intercom/ect so I put them into one account. Well, then they eventually split up and went their separate ways. Man that was rough. I've also had a virtual receptionist company approach me wanting a way to see status of their clients.It was really hard to see a multi-hundred handset account walk because I had no solution for that. But, oh well...

[Darren Schreiber]

Hi Rick,
    While I get your points, the key exchange thing doesn't even solve half of what I listed, while adding another training/complexity point just in teaching the user (Forget the code part). Ugh. Yeah, MESS.

     This is very much NON-TRIVIAL.

      I think we will probably end up supporting this scenario:
"First is for a single company with multi-locations. For them, really it'd be mostly about using Smart PBX. Man oh man it's hard to convert someone from using Smart PBX to ADV callflows just because they add a location. They hate it." 

I agree with that use case. The value of SmartPBX is being able to stay within it, and the use case is common.


This one:
"Second though is separate companies that want to be affiliated for some reason. For instance, I had three clients that shared adjoining suites. They relied on each other heavily and wanted to be able to page/intercom/ect so I put them into one account. Well, then they eventually split up and went their separate ways. "
Honestly, this one is where, as a reseller, you gain a backbone and you say to them, either re-setup your account, or we bill you for having to manually do this. Do not sell them anything that entitles them to break up later, that's absurd. I know of no company who puts up with this scenario as somehow included or expected to be a feature of the system. And this instance is so rare.


This one:
"I've also had a virtual receptionist company approach me wanting a way to see status of their clients.It was really hard to see a multi-hundred handset account walk because I had no solution for that."
I agree this would be nice, but then it'd require tackling all the technical complexities I listed. I agree we should do it someday, but the multi-office company is far more of a common occurrence then this particular type of client, and this is just one of their requests. Once you can say you do this, they want 82 other things (like custom reports on a per-customer-we-service basis, etc.) so this is just the tip of the iceberg if you want to support receptionist companies who handle multiple clients. I'd argue that you should do more homework here on ALL of the things they are going to require (not just this) because there's a LOT of them, and you're only mentioning one.

[FASTDEVICE]

Darren, with all due respect, I think you are over-complicating the request. Consider the feature to be a widget in advanced call flow or a device. This would limit the re-seller to only their accounts, from a drop down selection, and perhaps the end-point is not entering into the other account's call flow, but a user.  

[Darren Schreiber]

And how would said widget work?

[FASTDEVICE]

The widget would be part of the initiating call flow. The widget would list available accounts under the re-seller. Once selected, the widget would then list all call flows and users under that account. Essentially is would be no different than assigning an extension to another call flow or user. 

[Darren Schreiber]

How would such a widget work? I'm less concerned with the GUI and more concerned with how it would work on the back-end.

Decisions such as:
* Security
* Caller ID
* Which accounts can see which other accounts
* Performance on having to scan multiple accounts per BLF query
* Performance on having to scan multiple accounts per call
* Teaching/training the user on how to perform the above security and possibly introduce a key to identify which accounts can access which others, that's configurable
* Handling of errors/issues where both callflows on accounts have the same number configured
* CDRs (What if both accounts have the same Caller IDs or user names? This could get really confusing)
* Billing/rating
* Limits/restrictions across accounts (we have features that limit simultaneously calls, including internal extensions, within an account - how will these work between accounts?)
* Webhooks and other items that don't currently include an Account-ID field, these would now presumably all need to be found and enhanced to have an Account-ID, otherwise you'll get an Owner-ID and/or device ID but no account ID and won't know where it came from?

There's probably more.

[Darren Schreiber]

This only covers the GUI and is too simplistic to be secure. That said, pretend we did do that. Your design indicates that for each device/callflow in account A you would create a corresponding callflow in Account B which points to the callflow in account A?

This would imply that:
* A security key or otherwise would need to be introduced that indicates Account A is allowed to view the things in Account B
* Callflows now must pull their dropdowns, every time requested, from two sources
* When the calls are actually processed we still need to make sure the Account ID is allowed to call other said Account ID, so we must pull the security list and then pull the info in the second account
* The built-in / nested "Edit" buttons - how will those work? Will those just break / not be allowed if you try to edit a device/user on a different account?

There's probably more I'm not even thinking of, that's with 5 minutes of thought.

I assure you, if it was as easy as you're stating, someone would have already done this...

[FASTDEVICE]

Yes, exactly. Office A would have extensions in the 100 range and office B would have extensions in the 200 range, etc. etc.

[Darren Schreiber]

OK, and are you paying attention to how you can't just do that? :-) See all my comments above about all the things that must be considered, both front-end and back-end, to achieve what you just over-simplified...

[FASTDEVICE]

I guess I'm going off the premise that I can accomplish the same using DIDs. However, BLFs are a different matter, but not something I need out of the gate.

[Darren Schreiber]

If it's just to call extensions between accounts, perhaps that's simpler, but it's going to open a pandora's box including all the items I mentioned above (and again, that's just what I can think of now). We could start down the path but I still feel supporting multiple offices in the same account will be more useful and lucrative for everyone from the start. The other use cases are edge cases.

[FASTDEVICE]

Darren, I'm thinking it's not an edge case for me. A number of prospects and current clients have multiple businesses under one roof with a central admin answering calls and routing. I'd like to keep the businesses separate and in this case don't need extensions calling one another, but need the admin to route the calls to their extensions. And, I need the system to grow with this "rental" business model beyond the capacity of a multi-account SIP phone. However, I have multi-locations as the dominate request.

[Darren Schreiber]

OK, so what is this worth then? It may fit your use case and a few others here, but I doubt everyone will use this. Thus, we'd be spending probably 200-500 hours building this at let's say $75/hour. So it's a $15k-$38k project probably. If I divide that over, let's say, 500 endpoints x 12 months = that's a fee of $6.25 per endpoint to have this feature? Would that be worth it to you?

I'd say if we could get a commit collectively from everyone for 500 endpoints @ 12 months then we could build this.

[FASTDEVICE]

If you want stakeholder input on prioritizing the backlog (now that you brought up money), the most requested feature, from my client base, is call queues. I'm sure that's a different thread.

[Darren Schreiber]

That one is already in the works. Yes, a diff thread for this one if you wanna go there! And I think that one is thousands of devices, not hundreds, so financially speaking a much better bet!