Key System Emulation

[ShadowGrass]

I am having a huge problem converting my branch users over to VOIP. They have been using key systems for 20-30 years and want the Line 1, Line 2, Line 3..functionality. There is actually a good reason for this, our locations (17 of them) all have a central sales counter where usually about 5 people stand each with their own phone. Calls come in and ring to all sets on counter. Person 1 answers and tells the caller to hold as another call is coming in. He needs the Person 3 to "pickup line 1". Instead of Person 3 just pressing the Line 1 button, the call must be transferred or parked. As more and more calls come in, they get confused easily. I have been trying to work this out with Switchvox (Digium) and their answer was a flat out NO. I should have researched more. I am looking a 3CX to replace this system I just installed. Even though I created BLF keys for 5 parking lot spots, apparently this is still an issue. Can 3CX do it any better? Is there a way to assign one trunk to one button on each phone since I am using POTS? My main reason for moving in the VOIP direction is transfer calls between locations and the software functionality. I know that Shoretel, Allworx, and AdTran have the key system emulation, but they are expensive options. Thanks for any help.

 

[leejor]

First of all you require a gateway that allows each PSTN line to be accessed (datafilled) as an individual trunk (not as a trunk group) on 3CX. Each trunk (incoming) can be directed to a single extension. For outbound calls, you have to create a series of rules, unique for each of the extension, that send the outbound call on the PSTN trunk that is "paired" with it. Getting the keys on the phones to emulate a key system might be the tricky part depending on the sets you are going to use and the options that each offers.

 

[ShadowGrass]

Thanks for the info Leejor. Yes, I understand the gateway portion. Amazing how quickly you learn when you are thrown directly into the fire. One I lit myself no less.

Each trunk being assigned to one extension? Say I have 3 POTS lines setup in a hunt group with telco. Right now they go to one queue and ring all sets in the Sales Counter group.

Line1 Line2 Line3
|
[POTS Lines Group]
|
[Sales Counter Group] (Ring all)
|
[Sales1 Sales2 Sales3]

What you propose is this?

Line1
|
Trunk 1
|
Sales1


Line 2
|
Trunk2
|
Sales2
|
etc.

Would each individual trunk be able to ring all even though they are assigned to only one phone or would they only ring to the assigned phone? I can see that using BLF at this point may provide the visual aid needed to see which line is in use from other phones. So, if Sales1 takes a call on Trunk1 and places that user on hold, then Sales2 has Button1 configured with BLF to show status of Trunk1 on Sales1. I would assume it would blink green in Sales1 and blink red on Sales2. If Sales2 pressed Button1 on his phone (the blinking red showing a held line from Sales1) would this perform an intercom call to Sales1 or would it pick up the held line? This is where the problem usually lies for me I have found.

I hope my explanation isn't too confusing. Thanks again for your help.

 

[leejor]

To emulate a key set, you would assign (for example) extension 201 to the first key of all sets in the department. Extension 202 would be on key 2 of all sets, and so on. When line 1, from the PSTN (trunk 1) had an incoming call, all sets would ring on key one. this does not require a ring group as each trunk is only ringing one extension number, that is "forking" to appearances (sets). Because each phone will be a copy of each other (at least for the line keys) you will most likely have to provision the second and third manually.

The real "trick" to all of this is not the routing of the calls, it is getting the hold key(s) and status indicators to function as they would on a "real" key system. That may require some trial and error, or help from others that have already accomplished this. the BLF's should show the status of the other extensions with the same number, not the trunk status, but because key one will always use trunk one, then they are essentially one in the same.