-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Routing Extensions to custom volunteer groups #584
Comments
Hawaii Region would also love this feature |
I have an idea of how I want to do this. My hope is to implement it sometime in the future. |
Hopefully that means the near future because some of us are older 8^) |
For this first pass, this is what I'm thinking.
|
However it works best on your end, I surrender to - but here was how I originally envisioned it. Could you instead allow for an extension to be linked to a volunteer group - possibly through config, and later add ui so you do not having to do that through config? Then you only need to set up an extensions parameter that loads out of config and has a volunteer group name associated with it. The extensions parameter might need to be an array that includes extension, volunteer group name, text for the voice to read for that extension (if not running a mp3), call routing type. Call comes in; when config is loaded, so are extension parameters; play mp3 or voice the text; parse the tone; if there's an extension matched, go directly to routing to the specific volunteer group. |
The way I got around not having this feature in Yap was We got a 2nd Twilio number that acted like a Phonelines and routed the calls.
The setup was very easy from with twilio.
We needed a second number anyway now so it seems to have solved our issue for the moment.
ILS
Eddie
… On Aug 23, 2022, at 3:13 PM, Danny Gershman ***@***.***> wrote:
For this first pass, this is what I'm thinking.
Server admins will have the ability to insert a database record into a new table called committee The user interface will be added in the future.
Only Yap admin users will be able to "see" this. BMLT users use the BMLT to determine permissions for "seeing" service bodies. This could be expanded in the future if need be.
—
Reply to this email directly, view it on GitHub <#584 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMCCZRGD76AZA3WF2BJUEG3V2VZJ5ANCNFSM5RAOPPIA>.
You are receiving this because you commented.
|
The UI for adding volunteers, configuration, voicemail, reports will all work the same. The only part that isn't managed through the UI is the adding of the committee. |
Is it better on your end to manually create a service body in the database to access the routing than to link to a volunteer group defined within the relevant service body? As I said before, however it makes most sense on your end to do, I am good with. It just is something I have seen requested and been asked about more than a few times - to be able to press 4 and go to a group of committee members, usually PR. Now part of my reasoning for the approach I was taking with this is in manually creating service bodies, it may limit the scaling of the extensions. Some areas have extensions for more than public relations - they may have it for their convention, or for some other purpose. Having service bodies able to create volunteer groups that are specifically purposed to an extension allows flexibility in having multiple extensions - or even layered extensions later (i.e. extensions that appear after giving location so you can press 4 for the local public relations committee as a sub-option of talk to a volunteer --- without knowing the area name) --- just thinking down the road with that one. That was a bit more jumbled than I like - but I trust you get the gist and look forward to how you set about solving this. |
You make good points. Going to think about this. |
So here is the typical default flow. Press 1 to find someone to talk to. You press 1, then it asks for location info, which determines the service body. At that point you could determine if there were committees, but now you have another menu to add, because you need to clarify "what you want to talk to". |
The other way is to make it the top menu, however, at that point, you don't know the service body because you haven't collected the information yet. Which means you don't know if there is actually a committee to route to. |
here is the "as a service body" implementation 7f13361 |
So to sort out the order of operations might take some reorganizing of the call flow - not sure if you want to go there but it may work out better in the long run.
In that scenario, only service bodies that have a defined extension get more than options 1 or 2. That allows scaling to whatever committees an area may find the need for. You can likewise utilize shared volunteer groups as fallbacks if areas want to use a regional committee or a shared resource. Most of the work for this just ends up in the call flow reorganization - which could improve things overall anyways. |
Not going to reorganize the call flow for this feature or at all. There are too many other dependencies.
From: spiritualtheory ***@***.***>
Date: Tuesday, August 23, 2022 at 11:52 PM
To: bmlt-enabled/yap ***@***.***>
Cc: Danny Gershman ***@***.***>, Assign ***@***.***>
Subject: Re: [bmlt-enabled/yap] Routing Extensions to custom volunteer groups (Issue #584)
So to sort out the order of operations might take some reorganizing of the call flow - not sure if you want to go there but it may work out better in the long run.
1. Call comes in, play mp3 or voice of welcome.
2a. If JFT is enabled : Press 1 to speak to an addict or find a meeting, Press 2 for JFT
2b. If no JFT, or if there is JFT and option 1 is selected, state "To help you find a meeting or an addict to speak with, press 1 to search by city/state or press 2 to search by zip
2. Now that you have the local info, go through options of press 1 to search for a meeting, press 2 to speak to a volunteer, press 3 to speak to a member of our Public Relations, etc.
In that scenario, only service bodies that have a defined extension get more than options 1 or 2. That allows scaling to whatever committees an area may find the need for. You can likewise utilize shared volunteer groups as fallbacks if areas want to use a regional committee or a shared resource.
Most of the work for this just ends up in the call flow reorganization - which could improve things overall anyways.
—
Reply to this email directly, view it on GitHub<#584 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAOD3O7LB3J4ZSXDJVS24RTV2WMBBANCNFSM5RAOPPIA>.
You are receiving this because you were assigned.Message ID: ***@***.***>
|
Is the call flow that entangled that it can't be reorganized? Just curious. Without doing that, I don't see being able to scale this easily to the area level for the reasons that you stated - which was the primary need. I mean, you could do as you mentioned and add an additional prompt behind the location search of talking to an addict - and that would solve for the issue, I just hate adding distance from the initial call to an addict connecting with a volunteer if that's the caller --- and reorganizing the flow, especially where no JFT is enabled, didn't really add distance (length of time to connect). With all that said, it could be worked out to be regional PR based on your implementation - just lacks simple location based scalability from what I can tell. So a partial solution - but still a solution. All good. |
There are other options that don’t use location that inspired this design and ultimately will not force my hand to make such a refactor for this feature.
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: spiritualtheory ***@***.***>
Sent: Wednesday, August 24, 2022 12:22:32 AM
To: bmlt-enabled/yap ***@***.***>
Cc: Danny Gershman ***@***.***>; Assign ***@***.***>
Subject: Re: [bmlt-enabled/yap] Routing Extensions to custom volunteer groups (Issue #584)
Is the call flow that entangled that it can't be reorganized? Just curious. Without doing that, I don't see being able to scale this easily to the area level for the reasons that you stated - which was the primary need. I mean, you could do as you mentioned and add an additional prompt behind the location search of talking to an addict - and that would solve for the issue, I just hate adding distance from the initial call to an addict connecting with a volunteer if that's the caller --- and reorganizing the flow, especially where no JFT is enabled, didn't really add distance (length of time to connect).
With all that said, it could be worked out to be regional PR based on your implementation - just lacks simple location based scalability from what I can tell. So a partial solution - but still a solution. All good.
—
Reply to this email directly, view it on GitHub<#584 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAOD3O6LVECRU3DZZND5ZRDV2WPQRANCNFSM5RAOPPIA>.
You are receiving this because you were assigned.Message ID: ***@***.***>
|
A request for a feature like this has come up again. On our old Helpline system we had an option for people looking for PI to hit a menu number and the next question would be to ask for their area code to get a general location. Obviously that is outmoded, but we would be ok having a menu item for PI that just goes to a voicemail box or routes to a special group of volunteers independent of location (each of the PI volunteers can handle the whole state of NJ). |
Currently extensions can be assigned to a single phone number
Looking for the ability to set up volunteer groups for extensions
For example : Press 4 to speak to someone in public relations
And it routes to a user defined volunteer group "Public Relations" that follows all the same setup and scheduling rules any other volunteer group does - and in this case route to members of a public relations committee, not just phone line volunteers. Not all phone line volunteers are equally equipped to answer questions that the PR committees would be able to handle.
Technically you can do this via setting up a second phone service that is routed to as the single number on extensions now - but that is an additional complication that most service bodies do not want to deal with, especially if they are looking to onboard YAP as a simpler solution.
The text was updated successfully, but these errors were encountered: