1. Team 05 SnApp Voice Communication System
Our project is to develop a Voice Communication System for a L.A. based startups, SnApp-Dev. SnApp-Dev builds custom apps for various clients (such as real estate agents currently) to help provide technological enablement for their services. They want to build a call handling and monitoring system for their sales team.

2. Team Client: Charles Zivko Team Members: Divij Durve - IIV & V
Harsh Mhatre - System/Software Architect
Khyati Thakur - Prototyper
Monica Varhale - Feasibility Analyst
Nikita Gupta - Project Manager
Shlok Naik - Operational Concept Manager
Shruti Gotmare - Life Cycle Planner
Sushmaja Bondili - Requirements Engineer

3. Current System
The current system requires the agent to log into and access multiple applications to achieve his objectives. He logs into Skype whenever his wishes to contact a specific lead. If he needs to randomly call potential lead, he logs into five9 and waits for it to connect him to a new lead from a pool of potential leads. To download call log details the agent or an admin has to log in to Skype and manually export a CSV file and upload it onto their server. Whenever a new employee is hired, Freedom Voice is used to allot him a new 800-number and set up a voic box for him.

4. Drawbacks in Current System
Scattered system
Inflexible
Time consuming
Manual, unformatted call logs
Five9 is expensive and clunky
Not user-friendly
Complex account set-up process
Extensive training
Context switching between multiple systems consumes more time and may confuse agents, causing a decrease in their efficiency and performance. A lot of these tasks require manual effort and detailed training on how to use these systems. This results in lower productivity levels and thus reduced profits.

5. Proposed System Callee
We plan to build a system that consolidates all the current applications into one application and provides more enhanced features such as real-time monitoring of calls and logging call details (with recordings of the conversation). With this system, an new user is automatically allocated a new number and voic box. A sales agent can either choose to call a specific lead or randomly auto-dial numerous leads. A manager can view the status of all agents under his supervision and listen in on his calls. He can also jump into calls if need be and can listen to old recordings or view call detail history. A system admin also has access to the logged information and recordings.

6. Project Description
Our project assumes that the current system is inefficient. It tries to address its problems and simplify the business workflow. The successful implementation of this system will benefit sales agents, sales managers and company executives. Having all features incorporated into one location will not only save effort but also training time and costs of using multiple services.

7. Risk Item Provide direct dialling Provide autodialing
Provide conferencing
Handle callbacks from customers
Log call details
Integration with the CRM
Log all necessary data in standard format for analytic engines
Due to the restricted constraints on the technical requirements of our project, our highest risk item becomes integrating all the different tools and technologies. Along with that, using an API that we are unfamiliar with, poses a risk that all the features that we desire may not be available through the given API and thus leading to the failure of the project. All features on the project are highly dependent on the features provided by the Twilio API and its coupling with the SnApp CRM.

8. Risk Mitigation Strategy
Buying Information
Prototyping
Twilio API satisfy requirements
CRM integrates with Twilio API
Risk Reduction
Incremental Development
Test in phases rather than at the end
To ensure that our project is not headed for disaster, we prototype to analyze the capability of Twilio and test its integration with the CRM.
Since the scope of our requirements is too wide for the short schedule, we take an incremental approach to the project instead of trying to develop all features from the beginning. We will be prioritizing features based on availability needs and penalty values, and build a system that can be easily expanded to incorporate the remaining features at a later stage.

9. Severity of Prototyped Risks
Using Twilio API from the CRM for call-handling
Potential magnitude (size) of risk: 8
Probability of risk: 6
=> Risk exposure: 48
Logging all required call detail data
Potential magnitude (size) of risk: 5
Probability of risk: 3
=> Risk exposure: 15
Due to the high dependency of the project on Twilio and its integration with CRM, it becomes the most severe risk item for our project. Without mitigating these risks, the project cannot progress.
Since the primary motivation behind the development of this project is to enable better business insights via data analytics, logging call details, although not very severe a risk, becomes an important one to prototype.

10. Results Twilio integrated with CRM and being used to make calls.
We managed to successfully build an interface integrating the CRM and the Twilio API. Via event handling (button clicks) we can make calls to the Twilio API requesting it to dial a specific lead’s number. When the lead receives his call, the call states a short message on SnApp while it connects the agent. After the call is completed, all details are stored on Twilio’s server.

11. Results Call logs being retrieved in the CRM via Twilio.
If a user wishes to view logs, he can click on the view logs menu. This pulls data from Twilio and displays it to the user in a tabular format. All the information required can be either directly retrieved or computed from Twilio’s database.

12. Thank You!