Telephony Services Provider

Market Research - Sources Sought Notice U.S. Army Integrated Logistics and Support Center Telephony Services Provider 1. Description of Intent: This is a Sources Sought Notice (SSN). Army Contracting Command - Warren (ACC-WRN) is conducting a Market Survey to determine the level of interest among contractors in providing Telephony Services. No contract will be awarded from this announcement. This is not a Request for Proposal (RFP) or an announcement of a forthcoming solicitation, nor is it a request seeking offerors to be placed on a solicitation mailing list. All portions of this market survey are merely for market research purposes, subject to change at any time, and are in no way binding on the Government. Response to this SSN is voluntary and no reimbursement will be made for any costs associated with providing information in response to this SSN or any follow-up information requests. No solicitation document exists at this time, and calls requesting a solicitation will not be answered. 2. General Information: The Government's explicit intent, in this SSN, is to not receive from respondents any proprietary data, trade secrets, business sensitive information, or information considered CONFIDENTIAL under 18 U.S.C. - 1905. The Government's constraint does not in any way relieve respondents from their responsibility to properly mark proprietary data when it is provided, in accordance with DFARS 252.227-7013, nor does it alleviate any requirement for the Government to protect marked data. The Government is not obligated to protect unmarked data. Respondents shall ensure that any material and data that is provided is marked appropriately to ensure proper handling of all information. Unless otherwise noted herein, anything submitted in response to this SSN will not be returned to the sender. Respondents will not be notified of the results of this SSN or results of information submitted, nor will the Government respond to telephone or email inquiries. NOTE: The Government is not asking you to develop or provide drawings or develop any technical data in response to this SSN. 3. Background: The scope of this effort is to procure a Telephony Services Provider that supports telephone dialing and sending SMS via an Application Programmer Interface (API) to telephone numbers worldwide. The scope of these technical requirements are to provide global automated telephone services and confirmation receipt, two way SMS text messaging, and an end-point API that meets the requirements outlined in the Functional Requirements Section. Providers will make available end-point API documentation to facilitate functional compatibility with the existing event software. 4. Scope of Capabilities Sought: 4.1 Throughput Requirements: 4.1.1 Provider must: Be capable of delivering a minimum of 50,000 1-minute telephone calls and 50,000 SMS within one single 8 minute time span. 4.1.2 Provider must: Be capable of delivering a minimum of 500,000 1-minute telephone calls and 500,000 SMS within one single 60 minute time span. 4.1.3 Provider must: Be capable of delivering a minimum of 1,000,000 1-minute telephone calls and 1,000,000 SMS within one single 120 minute time span. 4.2 API Requirements: Capabilities outlined below will be provided as part of a managed delivery point, deployed by the provider as a set of secured web API end-points. The end-points will be invokable from the existing SOAP or REST web API endpoints, with well-defined request/response message payloads specified as either XML or JSON. The APIs will specify a Web Service Definition Language (WSDL) document that defines SOAP verbs for the actions exposed by the API, with XML Schema Definition (XSD) documents that explicitly define the XML structures for the request/response payloads of each web API. Additional functional behaviors are to be configurable via controlled access to web addressable system configuration settings. 4.2.1 Provider must: Accept a web API packet that contains a list of phone number/client identifier pairs, along with the text of a phone message, and perform the automated dialing to call each number rendering the text-to-speech message. This XML request includes the phone numbers to call, the text of the message to play them, a duration (the total elapsed time that the provider should attempt contact), and number of attempts required. The provider must return a unique identifier for this event. This unique identifier is used in subsequent API calls to make changes to the active event, cancel it, or query for status about it. Thus, this unique identifier should be generated/assigned by the telephony provider. 4.2.2 Provider must: Accept a web API packet that contains a list of SMS number/client identifier pairs, along with the text of an SMS message, and perform the automated switching to send an SMS message to each number and deliver the text message. The provider must return a unique identifier for this event. 4.2.3 Provider must: Have an API that dynamically adjust to facilitate handling of multiple events running concurrently. 4.2.4 Provider must: Allow for call-throttling (limit the number of simultaneous calls placed) based on Country Code, Area Code and/or Telephone Prefix. As an example, the API will be configurable to accept a custom API call request, dial 100 phone numbers at a time under the prefix "(555)-222-XXXX". 4.2.5 Provider must: Have the ability to accept, record, and report on a complex telephone response from a recipient via a specified call flow (i.e. provide a list of possible response options, with nested actions based on those options). The provider will have the ability to accept this sort of "call flow" as part of the event creation message, and to record recipient's responses and report on them through the API. 4.2.6 Provider must: Accept a list of phone (or SMS) number/client unique identifier pairs to remove from an active event via an API web call, specified by the unique identifier returned from the initial creation of that event. 4.2.7 Provider must: Have the ability to cancel an active event when passed its unique identifier via an API web call. 4.2.8 Provider must: Have the ability to pause and resume an active event when passed its unique identifier via an API web call. 4.2.9 Provider must: Respond to an API web request for the status of an active event, by returning a detailed report of that event as of the time of the request. Listing which phone (or SMS) number/client identifier pairs has been contacted to date, including the results of the contact (no answer, busy signal, voice mail, actual acknowledgement key, etc.), complete with full timestamps for each event. 4.2.10 Provider must: Allow for the specification of custom vocabularies (custom pronunciations for specified words) to be used by the text-to-speech engine. Custom vocabularies should be assignable based on what "originator" (Person creating the event) is actually creating the new event. The provider should be able to assign different "accounts", and allow for customized behavior between these accounts through the API. 4.2.11 Provider must: Allow via the API for the specification of custom greetings, and custom greetings use as a prefix (or suffix) to the payload of the phone or SMS message. Custom greetings should be assignable to event "originators". 4.2.12 Provider must: Have an API that dynamically specifies an "originator" for each event in the originating API web call, and include that originator designation in the real-time statistics. 4.2.13 Provider must: Allow for the specification of an ANI (Caller-ID) number via the origination API web call, to provide to a recipient for identification of the desired origination phone number or SMS text originator. The telephony provider will use that number as the "from" phone number presented to recipients, so that a person receiving the phone call will be shown that number as the caller-ID originating phone number for that call. 4.3 Additional Capabilities: 4.3.1 Provider must: Allow for and note positive acknowledgements of receipt via a recipient's return SMS message containing a specified key after reading the text message. 4.3.2 Provider must: Accept a configurable # of times to attempt to contact each phone (or SMS) number/client identifier pair. This parameter to specify the # of attempts will be an optional parameter passed to the provider by the main creation message. 4.3.3 Provider must: Allow the ability to leave recipient a voicemail, with the text, a call back number, and a response code to record positive confirmation of a voicemail message. The provider will allow for configuration abilities to leave a callback phone number, along with a confirmation code, so that the actual recipient of the voicemail could dial that provided phone number and enter the provided confirmation code to log their positive confirmation with the provider. 4.3.4 Provider must: Allow for and note positive acknowledgements of receipt via a recipient's pressing of a specified key after hearing the phone message. The provider will also note the positive acknowledgement if a recipient uses the return phone number and confirmation code. 4.3.5 Provider must: Have the ability to allow for unique positive acknowledgements when a recipient has multiple active SMS events (i.e. respond to the first event with a 1; respond to the second event with a 2, etc.). 4.3.6 Provider must: Provide 99.98% availability of system and 24hr/7 days a week technical support for outages or trouble reports 5. Responses Due: Electronic responses to this SSN must be received by close of business 02 May 2017. 6. Instructions for Response: Please submit all responses and questions to: Matthew Fitzsimmons at matthew.t.fitzsimmons.civ@mail.mil. Submit any questions prior to submitting a full response. Request that electronic responses be provided in Microsoft Word 2013 or earlier, or compatible with Adobe Acrobat PDF Reader X PRO or earlier. Responses are limited to no more than 10 pages, text in Arial or Times New Roman, no less than 12 pitch, with one-inch margins. Only one response per company will be reviewed. Please format the subject line of the response email as follows: "[Organization Name] - Response to SSN - ILSC Telephony Services Provider. 7. Prospective Business Identification: Responses should be in the form of a Capability Statement and include the following elements: a. Company Name b. Address c. Telephone Number (Of POC) d. Fax Number (If available) e. Email Address (Of POC) f. Company Size: Number of employees and annual revenue g. Identify if the vendor is a Tribally-owned or Alaskan Native Corporation 8(a) small business or in any of the small business programs. h. Identify any Federal contracts or vehicles that your company has been awarded. i. Cage Code j. Is the firm registered in the System for Award Management (SAM) Appendix A Acronym List: 1. API - Application Programmer Interface 2. ANI - Automated Number Identification 3. JSON - Java Script Object Notation 4. Originator - Creator of an event and respective organization 5. SMS - Short Message Service 6. SOAP - Simple Object Access Protocol 7. XML - Extensible Markup Language 8. REST - Representational State Transfer 9. Web Service Call - Call to the API with list of identified phone and sms numbers 10. Web Service Request -Query of the API with a response acknowledgement for said query DISCLAIMER: THIS SSN IS ISSUED SOLELY FOR INFORMATIONAL AND PLANNING PURPOSES. IT DOES NOT CONSTITUTE A SOLICITATION (REQUEST FOR PROPOSAL OR REQUEST FOR QUOTATION) OR A PROMISE TO ISSUE A SOLICITATION IN THE FUTURE AND SHALL NOT BE CONSTRUED AS A COMMITMENT BY THE GOVERNMENT. RESPONSES IN ANY FORM ARE NOT OFFERS AND THE GOVERNMENT IS UNDER NO OBLIGATION TO AWARD A CONTRACT AS A RESULT OF THIS ANNOUNCEMENT. NO FUNDS ARE AVAILABLE TO PAY FOR PREPARATION OF RESPONSES TO THIS ANNOUNCEMENT. ANY INFORMATION SUBMITTED BY RESPONDENTS TO THIS TECHNICAL DESCRIPTION IS STRICTLY VOLUNTARY.