I feel bad for bringing this topic up again. But I’m looking for some assistance,
System is currently running FreePBX Distro 10.13.66.22.
Phones in use are Grandstream GXP-2140’s (mostly, with a few 2160’s)
Core module is running 13.0.120.25
EPM module is running 13.0.113
There are about 120 users, about 30 of which move from around, and would like their phone extension to be available at the phone on the desk they are using. I have read several threads about using the hot desking feature on the Sangoma phones, but we use the Grandstream, and don’t really want to mix them as that creates a learning curve issue.
Years ago I used Device and User mode, so in this case that was my goto. However, the Endpoint Manager options show on the “user” rather than the device. After a bit of looking I find that the Device and User config is no longer an option (I understand it is still there, . . . . it’s just not practical as it’s not supported and it breaks EPM)
All that said, I’m looking for suggestions on ways to implement this type of functionality while using the Grandstream phones,
I’ve been thinking about ways to simulate this for an office I work with.
I haven’t got all of the details worked out completely yet, but instead of setting up extensions, could one set up queues? A single queue (their “extension”) for each user. When they log into it, the phone rings. If they aren’t available. but logged in, they get queued, and if they aren’t there at all, the call drops to voicemail.
Right now, it’s a lot of extra work to set that up, but there could be an automated way to configure that so that they can “hot desk” and, as a side benefit, they get a queue for their account. Since you’re working with queues, you have a lot of different options that could be used (immediately send to voicemail, on busy, MOH while waiting, Advertising on hold, etc.)
I don’t know, but voicemail through *97 instead of “per extension” voicemail would be part of the solution. CID should be for the business, so that should work out OK as is. Placing local calls to the queues would work, so I’m thinking most of this will fall into the category of “the price you pay for flexibility”.
… or not. It depends on what the people that implement it want.
If I know you are sitting at extension 1001 today and I want to call you, I’ll call your “mobile extension 972”. If you call me back, your extension could say something like “Hot Desk Ext” and I’ll just have to pick up the phone to see who’s there…
In the US, Caller ID only has to be accurate on external calls, and even then, no one is enforcing that law. It doesn’t need to be perfect every time, and if it does, there are ways (through PHP scripting) to actually go the extra mile and make that work.
Hot desking isn’t supported in FreePBX except on Sangoma phones, so there are going to have to workarounds. Shooting holes in the suggestion isn’t getting us closer to solving the problems.
If you want to go really crazy with scripting on solving the local CID issue, then i was thinking of the following:
Queue 1001 represents ext 101. Ya?
Now when you log in from phone 972 to 1001 have a script that pulls the ext (972) number and adds a SIP alias to 972 of 101.
Says easy, but i believe hard work…
I wanted to play a bit with device and user mode, just didn’t have the time yet to create a new VM to set this up.
Anyhow, D&U wouldn’t work for me currently, since we use EPM on every machine we have in production, and D&U isn’t supported for use with EPM.
(I still hope it’ll work together one day )
So i guess that clients where we’ll have to deploy hot-desking we’ll need to use supported phones only.
No, the queue goes with the agent. So, as soon as the agent “logs in” on the queue, his extension’s Caller ID could be set to (“His Name” <972>) using a script called in the [queue-login-custom] (for example) context. The CID is stored in the ASTDB, so changing it on the fly is actually alarmingly simple. The actual extension would be in “the pool”, so having a generic CID could be enough. It depends entirely on what you can sell the people you are supporting.
Most of my customers have a core of employees that need phones with CID and numbers that make sense. The rest of the people (the ones on the floor) don’t get personalized phone information. In fact, the CID for these people is deliberately empty, since there’s no way of know where they are going to plug in.
I contend that it just isn’t that important. Associating his extension with his queue login is straight forward in post-processing, so with the exception of the caller ID issue (which is only critical in station-to-station calls), there’s really no reason to spend any time at all.
So, what I’m gathering is that unless you are using the Sangoma phones there is no reasonably straightforward hot desking solution. Any solution will be a bit of a hack. If those observations are correct, then it seems that the unsupported Device & User solution is the best solution. Does anyone know of a list of things that are broken if you use Device & User mode?
The gist is commercial modules are “unsupported” and may not work. I am not sure there is a definitive list. EPM will not work. If you were doing anything commercial I would recommend operating under the assumption that all commercial modules will not work.
There’s no need in this regard. Since the agents are queue members, you just let them log into the queue from whatever phone they sit down at.
Note that I regard queues separate from extensions. If you are pointing things to a specific person, you point it at the extension (or pseudo extension, in this discussion) but member of a queue are just members of a queue. Their identification isn’t critical to success - the performance of the queue is. The place to track their metrics isn’t in the call, it’s in the work products the inbound calls produce…
I have two call center agents: agent 1 (1001) and agent 2 (1002)
I have two extensions that they could hot desk at: desk1 (9001) and desk 2 (9002)
I have one customer service queue (8001) that needs traditional queue services (like queuing) I need both agents to be able to answer.
In your (brilliant) idea, you are saying to create 1001 and 1002 as queues. That will allow agent 1 and agent two to sit at either location (9001 or 9002) and receive calls normally. Makes perfect sense.
How do I layer in the customer service queue (8001) in this scenario, so that it queues callers and rings both agents (if unpaused) regardless of where they are sitting?
It depends on what level of fidelity you need from the members queueing in. We are talking about performance tracking for specific CSRs.
For my clients, the proof of performance is in the Customer Interaction Application we run to gather the data that gets generated by the calls. We tack the extension number to the call record, so we know what station was doing the call, and we review the recording (if needed) to listen to it. All of this data is still tracked by extension. The CSR logs into the CI App (using their CSR ID) and then the rest of the system handles the linkage.
In other words, our CSR performance metrics are based on the data gathered, not the calls that get generated. In our scenario, we don’t care who sits down where and who logs into the phones.
If your tracking is by extension (which, remember, is what you are really looking at if you are not using device and user mode), then the information is harder to gather. In spite of that, even a manual tracking system (CSRs use ‘*65’ to get their extension) will give you the linkage you need into the queue performance.
)