Hi, this is Eftakhairul Islam. I have been selected in Google Summer of Code (GSOC) 2014 for CIVICRM Phone Integration.
As a part of my project, I am going to implement a Voice Broadcasting feature for CiviCRM. The main goal of this project is to implement an extension for this functionality. It will be designed to integrate differents VOIP services such as Plivo, Twilio and Cisco via plugins, with a Plivo plugin developed for the first version. The first peice of functionality will allow suitably permissioned users to record or upload a voice mesage to the system and then schedule its broadcast to a group of people. Users are also able to check broadcast logs.
I came up with several mockups below which illustrate each each step in the sending wizard. I tried to keep the interface consistent with the existing civimail feature. (Another option was for me to implement an interface similar to the spec for Mail Blast UI using AngularJS. However, to keep the scope limited and focussed on Phone Integration we have decided to leave that to a later phase. Instead, I will refactor the existing CiviMail codebase so it supports Phone Integration too.)
Please review the mockups below focussing mostly on functionality. I would welcome feedback on this plan.
1. Recipents Selection:
User will select deifferents group and assign a name for the voice broadcast.
2. Tracking:
User will select the type of log information that s/he wants to see.
3. Record or upload voice message
User will record or will upload a voice message
4. Testing:
User can test his/her recored or uplaoded voice message by sending a test message.
5. Schedule or Send:
User will insert a date and time in order to schedule the voice message.
The extension will also expose some forms and pages for server configuration and log information. I will post those later. Your feedback is very much appreciated.
Comments
Are the tracking options mutually exclusive as is indicated by use of a radio button widget on that form? I would think folks might want to track more than one type of information.
Agreed. These should be checkboxes.
How are you going to store the tracked calls? if activity (and it would make sense), you will be able to track the duration and status directly.
for the cost, I'm not sure the trouble of storing a per call record in civiaccount is worthwhile but as part of the comment (or subject?), might be more managable to get a per campaign record only.
UI wise, it probably simplify as simply tracking or not tracking. And I'm not even sure it's a good idea to leave the option not to track the call: if you are rude enough to robot call me, the least you can do is to record you did ;)
And following the work of the improved UI for civimail: I have been quite vocal about my dislike of wizards, it applies to our case as well, and given how few fields you have, one big form is IMO way better than spreading 6 fields and a half in 5 steps.
X+
X+
slightly off topic perhaps but "track duration directly" might be (wrongly) interpreted as civi somehow has the ability to measure the time involved. not suggesting this should not be done but in case this piques anyone's interest we got this working in webform so the 'time taken' from opening a new submission to entering it was recorded in a webform field and then passed in to the Activity 'duration' field
It is standard to track how long people listen to a voice message since it is usually highly relevant to determining effectiveness of the message, and it suggests where the script can be improved.
IIRC correctly, a huge chunk normally hangup as soon as they realize it is a recorded message, with other significant chunks lost when caller is identified, then topic provided. After that there is a gradual loss through remainder of call, with a good chunk listening right to the end of a good appeal. Monitoring how different messages are received by the same group (eg how many listen to end, average call duration for same script but different caller personality, etc) will obviously lead to insight into what works and what doesn't.
I don't know about the significance or common metrics on time to fill out forms, but I imagine someone has been doing it if it turns out to be useful knowledge.
We had been thinking of storing per call info in a single custom table in place of the many civicrm_mailing_event tables. But a custom activity type with the table as custom activity fields is probably a better idea. I would just like to keep bulk sms mail and voice quite similar for everything.
I like the idea of creating a CiviAccounts entry for cost of campaign. I thought cost per call is returned from their UI so would be stored on per call basis in activity.
With respect to the UI, I just want voice broadcast to look like CiviMail-whatever that looks like- for consistency of UI. I reached out to Kurund re mail blast UI but haven't heard back. I will check if they have put out a non-wizard design, but will not be weighing in heavily. I agree existing UX is terrible, and this is one of those cases where we should look at how others have successfully hidden complexity that is only rarely needed. But voice broadcast should be following lead of CiviMail, it seems to me, not the other way around.
I was hoping to avoid a full dependency of this GSoC project on that one for obvious reasons, but thought it might be possible for some early refactoring by that one to perhaps make later integration easier. We probably need to scale back some dreams I had of making a great deal of the voice functionality shared code between D8 and CiviCRM, in part as it was affecting the UI implementation design.
I thought you were still going to have people sitting at phones speaking to the people phoned through the interface (more like a more automated survey/phone banking) but after seeing the comments this seems to be entirely about automated voice recordings calling people - is that correct?