SOURCES SOUGHT
70 -- Request for Information
- Notice Date
- 10/7/2014
- Notice Type
- Sources Sought
- Contracting Office
- Social Security AdministrationOffice of Acquisition and Grants1540 Robert M. Ball Building6401 Security BlvdBaltimoreMD21235
- ZIP Code
- 21235
- Solicitation Number
- SSA-RFI-15-0007
- Response Due
- 10/17/2014
- Archive Date
- 10/24/2014
- Point of Contact
- SEAN M. GAHAGAN
- E-Mail Address
-
Sean.gahagan@ssa.gov
(SEAN.GAHAGAN@SSA.GOV)
- Small Business Set-Aside
- N/A
- Description
- REQUEST FOR INFORMATION Social Security Administration (SSA) Office of the Deputy Commissioner for Systems (ODCS) Office of Electronic Services (OSES) Request for Information (RFI) DATE: Oct. 06, 2014 SUBJECT: Request for Information (RFI) for Software to facilitate and manage ongoing communications between the Social Security Administration and the public about Social Security Administration (SSA) Programs and Services. PURPOSE: The purpose of this RFI is to solicit information from Information Technology software providers about: ?Products and services that will enhance SSA?s capabilities to engage the public over multi-channels of communications and provide case management functionality; ?Infrastructure offering that can support the integration of third-party acquired Customer Engagement as well as in-house developed products. BACKGROUND: The Social Security Administration (SSA) has developed a robust authentication process that provides the public with electronic access to the mySocialSecurity web portal. SSA plans to implement a Customer Engagement Center (CEC). The goal of a CEC is to provide customer service and support on any and every channel. This CEC will be the integration point of all multi-communication channels and all of the applications and technologies that will serve to facilitate and manage all communications including self-service inquiry and communications between SSA?s Customer Service Representatives (CSR) and its mySocialSecurity customers. QUALIFICATIONS: SSA considers the criteria listed below to be important factors in the selection of software: Protection of personal identifiable information (PII). PII must be protected when sending or receiving information from the public. This pertains to both one-to-one communication with SSA agents and communication from SSA to a selected group of recipients. Integration with SSA?s existing eServices authentication system. Multi-channel communication with the public will be accessible through the existing mySocialSecurity portal. Integration with third-party system. The full solution may require acquisitions from multiple software providers. All acquisitions must be interpretable on communication queried or developed CEC infrastructure. Scalability. The number of registered mySocialSecurity users as of 9/01/14 is over 13 million and increasing rapidly. Communication software must be able to handle a vast number of communications in a timely and efficient manner. Integration with existing SSA systems. A software solution must leverage information in existing SSA systems and data stores through automated programming interfaces (APIs), recognizing that data housed at SSA will be the information of record. Section 508 compliant. Section 508 of the amended Rehabilitation Act of 1973 mandates that electronic and information technology developed, purchased, used, and maintained by the Federal government be accessible to people with disabilities. Software as a service offerings (SAAS). Any SAAS cloud based solution must be either Federal Risk and Authorization Management Program (FedRAMP) certified or a private cloud implementation. REQUEST FOR INFORMATION CATEGORIES: Responses to the RFI should include strategies to include one or more of the following functions as part of an integrated solution. 1.The system should: a.Encourage and facilitate the use of self-service communication channels to satisfy user inquiries including the Dynamic presentation of FAQs based on context (role, URL, topic). b.Provide i.Secure one-way and two-way messaging, ii.Attachments to messages, iii.Secure Click to Chat, iv.Secure Click to Talk, v.Secure Video Messaging, and vi.Secure Screen Sharing. c.Provide or integrate user ?inbox? within the mySocialSecurity portal. The user can initiate, receive, and respond to secure communications from SSA. d.Utilize the SSA knowledge base and business process rules to provide an automated response to an inquiry. e.Provide a unified view of all relevant mySocialSecurity customers? information from backend systems and provide guidance to agents to assist in servicing the customer. (This could be satisfied by integrating with our existing Customer Help and Information program, developed to support the agency?s 800 number teleservice centers, which contains decision support screens, knowledge bases and links to the relevant Policy Information). f.Maintain a complete history of the mySocialSecurity customer?s communications with SSA across all available communication channels and make this history available to the Customer Support Representative (CSR). g.Provide functionality to send targeted, marketing-type messaging based on mySocialSecurity customer preferences. h.Provide functionality to send alerts to targeted classes of mySocialSecurity customers. i.Support notifications via SMS text to mobile phones and email natively or through a third-party vendor. j.Provide functionality to manage all aspects of engagement that SSA has with its mySocialSecurity customers across all offered communication channels. The system must provide a holistic view of a customer?s interactions with SSA from the creation of a case based on the incoming inquiry to its completion, and a complete history of all the mySocialSecurity customer?s interactions with SSA. 2.The system should provide case management functionality to manage a case from its inception through the collecting and processing of relevant information until the case?s resolution. The case management functionality must present a holistic view that can include contact across multiple communication channels with multiple involved parties. 3.The system should be installed on-premises; a FedRAMP certified government or private cloud will also be considered. 4.A rich set of APIs should be available to interface with SSA systems. 5.All information generated in SSA processes, accessed from SSA systems, compiled as the knowledge base or collected by the system will be the property of SSA. 6.The system should supply detailed management information and customer analytics. 7.SSA personnel should have the capability to post informational messages to targeted groups of mySocialSecurity customers. These informational messages should be available for viewing by mySocialSecurity customers via their mySocialSecurity CEC inbox. The system should: a.Integrate with SSA processes. For example, when SSA back-end system generate a notice, the system support the processing of a batch file email addresses and fill-in information to send a personalized email or text to the targeted user informing that a notice is available for viewing from their mySocialSecurity CEC inbox. b.Send notifications to large targeted distribution lists based on the mySocialSecurity customers? enrollment for specific notification types, as well as on specific SSA information such as the mySocialSecurity customer?s servicing field office or status (i.e. collecting Social Security benefits). c.Construct messages using i.Standard pre-defined templates, ii.Ad-hoc notification compositions. d.Provide for the triggering of message distribution via i.A distribution schedule, ii.SSA personnel on-time initiation of a distribution, iii.An SSA application initiation of a distribution. 8.The system must provide Workload Management functionality that includes: a.Development of subject matter specific workload queues used in routing customer engagement work items to SSA personnel with specific subject matter expertise. SSA personnel accept work items from the specific work queues that they are assigned to work. b.Management of queuing functions including performance measures, creation of specific subject matter queues, creation of subject matter personnel pools, assignment of SSA personnel to appropriate subject matter pools, and the assignment of specific pools to work specific queues. 9.The entire system, including all user functionality used by the public and by SSA staff, must be fully Section 508 compliant. Responses to this criterion must include: a.Examples of 508 compliant solutions provided. b.The steps that are required to deliver a fully compliant solution. Please explain to what extent customization or custom code is required to deliver a 508 compliant solution. c.User functionality that cannot be made 508 compliant. REQUEST FOR INFORMATION RESPONSE GUIDELINES: Responses to this RFI must be submitted electronically to sean.gahagan@ssa.gov, no later than 5:00pm (EDT) on October, 17, 2014. Responses must be provided as attachments to an email. It is recommended that attachments with file sizes exceeding 25MB be compressed (i.e., zipped) to ensure message delivery. Only electronic responses will be accepted. Please identify your answers by responding to a specific category, if possible. Respondents may address as many categories as they wish. SSA will not respond to individual submissions or publish publicly a compendium of responses. A response to this RFI will not be viewed as a binding commitment to develop or pursue the project or ideas discussed.
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/spg/SSA/DCFIAM/OAG/SSA-RFI-15-0007/listing.html)
- Record
- SN03545088-W 20141009/141007234947-3f01c853d6ce8ac578428634c0911bb7 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |