south dakota board of regents

South Dakota Board of Regents

_________________________________

Emergency Alert System Request for Proposals

December 11, 2007

EAS RFP

Table of Contents1.

1. 1. General Information and Background ........................................................ 3

2. 2. Overview of Requirements ......................................................................... 5

3. 3. Questions ................................................................................................... 7

4. 4. Schedule & Submittal Instructions ............................................................. 8

5. 5. Proposal Response and Presentation ..................................................... 11

6. 6. Scope of Work & System Requirements .................................................. 15

7. 7. Implementation Plan ................................................................................. 26

8. 8. Pricing ....................................................................................................... 27

9. 9. Proposal Evaluation and Award ............................................................... 29

10.10. Conditions .............................................................................................. 30

11.11. Customer References ........................................................................... 37

<Insert Name/Organization Here> of 37

EAS RFP

1. General Information and Background 1.0 General PurposeThe Purpose of this Request for Proposals (RFP) is to solicit sealed proposals to establish a contract through competitive negotiation with a qualified vendor to provide emergency notification services to the South Dakota Board of Regents community.

1.1 InstitutionsThe South Dakota Board of Regents System (SDBOR) is comprised of six four-year public universities, two special K-12 schools, three higher education centers, and the Executive Director’s Office. The universities are Black Hills State University in Spearfish, Dakota State University in Madison, Northern State University in Aberdeen, South Dakota School of Mines and Technology in Rapid City, South Dakota State University in Brookings, and the University of South Dakota in Vermillion. The two special K-12 institutions are South Dakota School for the Deaf in Sioux Falls and South Dakota School for the Blind and Visually Impaired in Aberdeen. The centers are University Center in Sioux Falls, Capital University Center in Pierre, and the West River Center in Rapid City. The Executive Director’s Office has operations in Pierre, Vermillion and Spearfish. These institutions will hereinafter be referred collectively as SDBOR (South Dakota Board of Regents).

1.2 Board of RegentsThe South Dakota Board of Regents has constitutional authority to govern the system of public higher education in the State of South Dakota. The nine member governing board is appointed by the Governor and confirmed by the Senate and serve six year terms. The Board is supported by an Executive Director and staff, the Board provides leadership and sets policies for the programs and services delivered through its six universities, two special schools and three higher education centers. The Office of the Executive Director is located at 306 East Capitol Ave. Suite 200, Pierre, SD 57501-2545, (605) 773-3455 ([email protected]). The Executive Director is Dr. Robert T. Tad Perry.

1.3 System SizeThe SDBOR serves approximately 24,000 full-time student equivalents annually in credit-based courses and produces about 5,000 graduates a year. The total student unduplicated headcount population is 29,457 with a total operating budget of $574,170,007. The following is a link to the South Dakota Board of Regents website, which links to each school’s website: http://www.sdbor.edu/.

The system employs approximately 5,500 full-time equivalent employees annually. Excluding students, and including part-time employees, the number of staff approximates 6,754 any given month.

1.4 Institution SizeThe student headcount by institution and their staffing headcount (excluding students) follows:

Institution Student Headcount Staffing Headcount*BHSU 3,638 611DSU 1,784 312


http://www.sdbor.edu/

mailto:[email protected]

EAS RFP

NSU 2,384 466SDSM&T 1,869 397SDSU 11,057 2,546USD 8,725 2,193UC Counted in Other U’s Counted in Other U’sCUC Counted in Other U’s Counted in Other U’sWRC Counted in Other U’s Counted in Other U’sSDSD 48 63SDSBVI 29 72Executive Director 0 94 Total 29,534 6,754* Excluding students

For purposes of this RFP, the SDBOR would have a total of approximately 37,000 end users that would be registered for the emergency alert system, including all part-time and full-time students and staff.


EAS RFP

2. Overview of Requirements 2.0 GeneralSDBOR is accepting proposals from qualified firms to provide a robust, interactive, high speed emergency notification system to be used for crisis and emergency communications. The system will be an integral part of the emergency communication strategy at the SDBOR institutions (described in Section 2.1) It must be capable of efficiently sending notifications to thousands of students/faculty/administration/parents prior to, during and after a crisis or emergency. The system must be available to initiate and deliver notifications 24 hours a day, 7 days a week and 365 days a year.

It must be delivered via an Application Service Provider model to ensure that no hardware or software must be purchased or maintained by SDBOR and so that the solution is still secure and easily scalable on-demand. The solution must be customizable through configuration options.

SDBOR intends to use the system in the following ways.

2. Notifications of identified, eminent or pending threats or disasters, including human initiated and natural events.

3. For each type of notification:

1. The notification could include students, faculty members, administration, parents and first responders.

2. The number of contacts would vary for SDBOR depending on the site and could even include multiple sites.

3. Most notices will not require a response but could include confirmation.

4. The expectation is that the vendor has the capability to notify any given population at a SDBOR site within 10 minutes or faster.

5. The system should be capable of sending responses to TTY systems.

4. The contacts will be able to maintain their own contact data and/or it can be uploaded and downloaded from our current Student and Finance Systems.

2.1 System Contract with Institutional ApplicationThe contract will be with the SDBOR but implementation and application of the solution will be at the institutional level.

2.2 Related SystemsIt may be necessary to import information from our ERP systems for students and employees into the selected notification system. Datatel Colleague and SCT Banner are the vendors and software respectively for those systems.


EAS RFP

2.3 Rights Reserved by SDBOR

Not withstanding anything to the contrary, the SDBOR reserves its right to:• Reject any and all proposals or parts of proposals received in response to this RFP;• Select, for contract negotiation, a proposal other than the one with the lowest cost;• Waive or modify any informalities, irregularities, or inconsistencies in proposals received

and/or accept a written modification requested by the SDBOR if the proposal itself was submitted on time and if the modified proposal is more favorable to the SDBOR;

• Negotiate any aspect of the proposal with any vendor;• Terminate negotiations and select the next most responsive Respondent, prepare, and

release a new RFP, or take such action as deemed appropriate if negotiations fail to result in an agreement; and

• Modify or clarify this RFP issuing one or more addenda to this RFP. Addenda will become part of this RFP. All addenda to this RFP will be posted on the EAS RFP web site with their effective date and time of posting reflected therein. Vendors are advised that they must reflect in their paper proposals that they have seen and reviewed all such addenda.


EAS RFP

3. Questions 3.0 Questions

All questions about this Request for Proposal must be submitted in writing and delivered electronically to [email protected] on or before the required due date according to the calendar in Section 4. Written answers along with the original questions and vendor identification will be provided to all Respondents of the RFP in accordance with the schedule of events. Questions received after the deadline for submitting questions will not be answered.

3.1 EAS RFP Web Site

The EAS RFP web page will have responses to Respondents’ questions about the RFP or the RFP process. Additionally, all formal addenda to this RFP as to the deadline for submission of proposals or any other matters will be posted on the EAS RFP web site: http://www.sdbor.edu/administration/finance_administration/EmergencyAlertSystemRFP.htm.

All substantive responses to vendor queries will be made available to all Respondents and prospective Respondents by posting on the RFP web site with the name of the party submitting the question. The name of questioner, question and answer will be posted on the RFP web site. Questions must include the name of the questioner, the vendor name as well as a phone number and e-mail address for confirmation.

For this RFP, the web site will be the venue for written notification to all Respondents and prospective Respondents. Respondents are expected to check this web site on a regular basis and to review all material posted on this site before submitting any proposal. Any problems accessing this web page or receiving a response to any query should be reported immediately to Monte Kramer, [email protected].



http://www.sdbor.edu/administration/finance_administration/EmergencyAlertSystemRFP.htm



EAS RFP

4. Schedule & Submittal Instructions 4.0 General This document, including attachments, constitutes a formal Request for Proposal (RFP) and is a competitive procurement. Therefore, the Respondent must carefully follow the instructions herein in order to be considered fully responsive to the RFP. The South Dakota Board of Regents (SDBOR) reserves the right to reject a proposal that is determined to be incomplete or which does not follow the required structure and format. However, when such statements are innocent or inadvertent in the opinion of the SDBOR, the SDBOR further reserves the right to waive them as informalities.

4.1 Calendar of Events

Listed below are specific and estimated dates (est.) and times of actions related to this RFP. The actions with specific dates must be completed as indicated unless otherwise changed by the SDBOR. In the event that the SDBOR finds it necessary to change any of the specific dates and times in the calendar of events listed below, it will do so by issuing a supplement to this RFP on the Emergency Alert System website: http://www.sdbor.edu/administration/finance_administration/EmergencyAlertSystemRFP.htm.There may or may not be a formal notification issued for changes in the estimated dates and times.

• December 11, 2007 (est): RFP released.• December 19, 2007 by 12:01 p.m., CST: Deadline for vendors to inform by email of

intent to submit proposal to SDBOR EAS Facilitator, Monte Kramer, [email protected].

• December 28, 2007 by 12:01 p.m., CST: Last day for submitting written inquiries to be sent electronically to URL. All inquiries indicating name of inquirer/vendor with written responses by SDBOR will be posted in a Q&A on the SDBOR RFP website.

• January 11, 2008 by 12:01 p.m., CST: RFP response deadline.• January 18, 2008 (est.): Decision-making by Emergency Alert System Task Force to

reduce vendors to 3 - 4 finalists. • January 23, 2008 (est): Vendors informed of finalist status both by e-mail and phone

message to vendor or indicated recipient.• February 4 – February 22, 2008 (est.): Vendor demonstrations in person at designated

site(s).• February 23 – February 29, 2008 (est.): Evaluations compiled.• March 7, 2008 (est.): Recommended vendor selected.• March 10 – March 14, 2008 (est.): Contract negotiated.• March 17 – April 17, 2008 (est.): Vendor provides technical support staff training,

administrator training, and provides access to system for students and staff to provide necessary emergency contact information. Vendor completes install and testing of new system per agreed upon testing criteria and requirements.

• April 18, 2008 (est.): New system fully functional for emergency use.





EAS RFP

4.2 Key Vendor Dates

Task Date

Deadline for submission of intent to submit proposal (12:01 p.m. CST)

December 19, 2007

Deadline for submission of questions (12:01 p.m. CST) December 28, 2007

Deadline for submission of proposals (12:01 p.m. CST) January 11, 2008

System Fully Functional (estimated) April 18, 2008

4.3 Submittal Instructions

4.3.14.3.1 COST TO PREPARE AND SUBMIT RESPONSES

All costs incurred in the preparation and submission of responses to the RFP shall be the responsibility of the Respondent.

4.3.2 LATE PROPOSALS

Proposals received after the due date and time will not be considered and will be returned unopened to the sender. Regardless of the method used for delivery, Respondents shall be wholly responsible for the timely delivery of submitted proposals.

4.3.3 PREPARATION

Proposals should be prepared in such a way as to provide a straightforward, concise delineation of capacities to satisfy the requirements of the RFP. Proposals should be typed and submitted on 8.5 by 11-inch paper. To facilitate the efficient, objective and uniform review of proposals, all copies of proposals must be submitted bound in a three-ring type or other binder. Expensive bindings, color displays, promotional materials, etc., are not necessary or desired. Emphasis should concentrate on conformance to the RFP instructions, responsiveness to RFP requirements, and on completeness and clarity of content. All proposals and accompanying documents become the property of SDBOR.

4.3.4 PROPRIETARY INFORMATION

SDBOR will take appropriate care to protect proprietary information received from the vendor and will only share the information with individuals within the SDBOR organization. Copies of materials marked “proprietary” will retain such labels. The entire proposals cannot be marked proprietary.

4.3.54.3.5 PROPOSAL D DELIVERYELIVERY I INSTRUCTIONSNSTRUCTIONS

Responses to this Request for Proposal (RFP) must be sent to and received at the following address no later than 12:01 p.m. CST on January 11, 2008. Please send by USPS or FedEx.

Please submit to:


EAS RFP

Monte R. KramerSystem VP of Administration South Dakota Board of Regents306 East Capitol Ave, Suite 200Pierre, SD 57501-2545(605) [email protected]

Proposals must be received in the above office by the specified time stated above. Receipt of a proposal by any other SDBOR office than the one stipulated does not constitute receipt of a proposal by the South Dakota Board of Regents office, for purposes of this RFP. Late proposals will not be considered. Responses received after the proposal deadline will be returned COD to the Respondent unopened. Fax and e-mail responses will not be considered.

To ensure confidentiality of the documents, all proposals must be packaged, sealed and show the following information on the outside of the package:

• Respondent’s name and address• Request for proposal title: SDBOR EAS RFP• Proposal deadline date and time: January 11, 2008, by 12:01 p.m., CST

4.3.6 Confirmation of Submission

Immediately after sending proposal, Respondents must send an email message to the SDBOR EASTF RFP Facilitator Monte Kramer, [email protected], indicating that the proposal has been sent. Upon receipt of the proposal an e-mail confirmation will be sent.




EAS RFP

5. Proposal Response and Presentation 5.0 Format of Proposal

Label and include the following sections in the proposal. Number each page individually and provide a table of contents:

1. Company History, Experience and Personnel

a. Identify and provide contact information for the prime Respondent and the name of the corporation or other legal entity submitting a proposal.

b. A description of the Respondent’s company, including the organization’s experience and history with providing services to similar organizations.

c. South Dakota Tax Identification Number and Federal Employer I.D. Number is required if Respondent does business with the State of South Dakota. This information may be used in the enforcement of federal and state tax laws. Supplying these numbers could result in action to require Respondent to file state tax returns and pay delinquent state tax liabilities.

South Dakota Tax I.D. Number_____________________________Federal Tax I.D. Number _____________________________

2. Customer References – Provide five customer references by completing the Customer Reference form in Section 11 of this RFP. Include references for at least two educational institutions for which emergency alert systems have been implemented.

3. Contractor and Subcontractor Listing

a. If applicable, submit the names, addresses, phone numbers and applicable licenses of all firms that will provide services in conjunction with the performance of this agreement. Identify all subcontractors. The Respondent will assume sole and exclusive responsibility for all of the services indicated in the RFP.

b. Describe any relationships with other software providers that are relevant to this proposal. (If none, answer “None.”)

c. Provide a list and description of any contracts that currently exist with any SDBOR institutions for the product(s) offered in this proposal. (If none, answer “None.”)

d. Describe any strategic partnerships or alliances with other technology or educational entities. How might these benefit the SDBOR project? (If none, answer “None.”)

4. Scope of Work & System Requirements

a. Include a clear and concise summary of the proposed approach conforming to specifications outlined in this RFP.

b. Describe the capabilities and planned roles of any subcontractor(s).c. Describe the major benefits offered by this proposal.d. Describe the approach to be taken including, but not limited to, how the project will

be organized and number and types of staff involved. Complete the matrix and answer all questions in Section 6 of this RFP and include them in section 5.4 of your response.

e. Describe any professional or consulting services provided. Identify which services are optional and which are required for proposed product installation and the


EAS RFP

development of any interfaces. Include all consulting costs in the Pricing response.

f. Describe training services provided. Is customer site-based training available? Include all details on the kind of training included in this proposal (specify if training is video, self-paced, off-site, on-site, on-line, workshops, etc.). Include evidence of assessment of training and evidence that training provided is successful. Training is a vital part of any proposal, and the SDBOR must be able to compare and evaluate the training component of each proposal effectively. Include all costs of training in the Pricing response.

5. Implementation Schedule

a. Provide a schedule of events that clearly indicates the time sequence for tasks that are required to perform major components of the implementation. See Section 7 of this RFP for more detailed instructions.

b. Identify personnel to conduct the project with details on training and work experience. Provide resumes describing the educational and work experiences for each of the key staff that would be assigned to the project. No change in personnel assigned to the project will be permitted without the approval of the system project director/manager.

6. Pricing

a. Provide pricing information. See Section 8 of this RFP for more detailed instructions.

b. A SDBOR contract with the terms and conditions required by the State of South Dakota is required. For reference for the SDBOR, include a sample copy of a typical license agreement and service level agreement used to formalize the Vendor’s legal relationship with an institution of higher education or other public entity. Variances between this sample and conditions required by the SDBOR do not constitute notification that the Vendor is taking exception to a term or condition. Vendor must clearly list any exceptions taken in the proposal submitted. The SDBOR reserves the right to reject a proposal on these grounds.

7. Litigation - The Vendor must identify any current or pending litigation in which the Vendor is involved in, that has a significant effect on its ability to provide products and services that could result from any contract resulting from this solicitation. Vendor will be required to supplement this information if additional litigation arises during the term of the contract. The Vendor must answer each of the following questions. If the answer to any question is in the affirmative, all relevant circumstances must be explained in detail including the current status and ultimate disposition of each matter:

a. Has the Vendor been declared in default of any contract?b. Has the Vendor forfeited any payment of a performance bond issued by a surety

company on any contract?c. Has an incomplete contract been assigned by the Vendor’s surety company on

any payment or performance bond issued to the Vendor arising from its failure to fully discharge all contractual obligations there under?

d. Within the past three (3) years, has the Vendor filed for reorganization, protection from creditors, or dissolution under the bankruptcy statutes?

e. Is the Vendor now the subject of any litigation in which an adverse decision might result in a material change in the company's financial position or future viability?


EAS RFP

8. Additional Information

a. Describe any official (Vendor sponsored) user groups that are in existence and the nature of the relationship with the Vendor. What mechanisms exist for proposing and prioritizing enhancements? Is there an electronic discussion group? List all relevant official user group forums, including group name, contacts, addresses, and phone numbers or URLs. Include a description of the process used to prioritize requests for added functionality and enhancements specific to the higher education market.

b. Describe the Respondent’s plan for further development of its software/services during the next three years.

c. Respondent(s) may provide additional information that is relevant to this proposal for consideration. Additional information must be limited to ten pages or less.

5.1 Product Demonstration

To illustrate the performance and features of proposed software, Respondents are requested to provide reasonably brief demonstration software, product materials or videos, or other concrete evidence of product performance. In addition, for the same purpose, Respondents may refer SDBOR to sites on the world wide web to review relevant data and information regarding the proposed software. However, the SDBOR reserves the right to evaluate proposals on the basis of the written proposal alone with or without the use of any additional materials by any or all evaluators. Respondents may refer to web sites to provide additional product or company information but are cautioned that they should not do so in place of fully providing information required in this RFP.

5.2 Customized Add-on Features

All features detailed in a proposal shall function without any custom changes. However, Respondents must include information on the availability of customized add-on features and specific costing information (in the Pricing Response) for extended capabilities or additional modules not covered in this proposal, including any constraints of the SDBOR development of Application Programming Interfaces (APIs) to allow interface with other applications.

5.3 Oral Presentations and Site VisitsFinalists may be invited to participate in interviews and/or site visits to support and clarify their proposals if they are to be further considered. Failure of a Vendor to interview or permit a site visit on the date scheduled may result in rejection of the Vendor’s proposal.

5.4 Product and Service Testing

Finalists may be required to demonstrate proposed product(s) and/or service(s) at a SDBOR site. The SDBOR will furnish detailed specifications concerning the demonstration site(s). Failure of a Respondent to furnish the product(s) and/or service(s) it has proposed for demonstration within the time constraints required may result in rejection of that proposal. Failure of any product(s) and/or service(s) to meet SDBOR’s specified requirements before or during the demonstration may result in rejection of the Vendor’s proposal.

Any product(s) and/or service(s) furnished by the Vendor for the purposes of this demonstration must be identical in every respect to those that will be furnished if a contract results. The


EAS RFP

successful demonstration of the Respondent's product(s) and/or service(s) does not constitute acceptance by the SDBOR.

5.5 Proposal Submittal Format

Submit an original and ten (10) hard copies and one (1) electronic copy document in Adobe PDF format only on a CD. Any supplemental software should be included on CD-ROM or available to SDBOR staff via download. An authorized member of the company must sign the original copy of the General Proposal in blue ink. Proof of authority of the person signing shall be furnished upon request.

5.6 Exceptions to the Terms and Conditions

Any exceptions to the terms and conditions detailed in this RFP must be clearly stated and detailed as a part of the Vendor’s response. If possible, alternative terms and conditions should be proposed. The SDBOR is under no obligation to accept such alternative terms and conditions and may reject the proposal based on the exceptions taken.


EAS RFP

6. Scope of Work & System Requirements 6.1 Service Requirements Complete the following matrix and answer all questions and include them in section 5.4 of your response.

Using the Response Codes below please indicate if your system meets the system requirements listed in the table in this section. The vendor is requested to provide a comment or explanation if warranted. If the vendor chooses to use any attachments for the support of any item, the vendor should refer to attachments and label them with corresponding numbers.

Response Code Definition

1: Meet Requirement The requirement will be met by the core functionality of the system proposed. This functionality is already operational at other sites.

2: Under Development

Requirement will be met by software that is currently under development, in Beta test, or not yet released. Provide target release date.

3: Minor Modification Requirement will be met with minor modifications to existing software. All work will be performed by the vendor and pricing must be included. This work must be noted in the project plan and schedule.

4: Major Customization

Requirement will be met by major modifications to existing software or by new custom software development. All work will be performed by the vendor and any additional costs must be noted.

5: Third-Party Requirement can be provided through a third party solution partner. When responding, the vendors must describe how the functionality will be achieved, which vendors are involved and whether any set-up work will be done by the vendor or customer.

6: Other Tools Requirement will be met by the use of proposed software tools such as a report writer, query language or spreadsheet. When responding, the vendor must describe how the requirement would be met and whether the set-up work will be done by the vendor or customer.

7: Not Available Vendor cannot meet requirement.

ReqNo.

RequirementResponse Code

Comments / Explanation

6.1. General Requirements

6.1.1. The solution must be designed specifically for mass notification using ASP Hosted (Application Service Provider) model so that:

1. Set up is fast and easy2. Database capacity and phone ports are

not purchased by the customer and usage and performance are managed by the vendor.

3. The vendor maintains all aspects of the system.

4. There are no limits to the number of


EAS RFP

ReqNo.



administrators who simultaneously access the system.

6.1.2. Provide time required to initiate/deliver 12,000 phone calls via 30 second phone message and provide time required to initiate/deliver 12,000 SMS text messages.

NA

6.1.3. The solution must have the ability to send multiple notifications at the same time to the same or different recipients.

6.1.4. The solution must be flexible to accommodate additional recipients’ contact information on-demand and on-the-fly.

6.1.5. The solution must be able to intelligently cycle through sending the same message to voice devices (e.g. cell phone) and text devices e.g. email and SMS)

6.1.6. The solution must NOT send messages simultaneously to all devices. Describe how your system cycles through sequential contact paths and immediately terminates delivery attempts once a user has confirmed receipt.

6.1.7. The solution must have the ability to initiate and deliver notifications 24x7x365 with AT LEAST 99.99% availability. Describe how your solution is configured for 24x7x365 availability.

6.1.8. The solution must have the ability for the notification to be delivered to the first intended contact device within two minutes of the request to do so.

6.1.9. The solution must have the ability to prioritize emergency notifications over standard notifications in the message delivery queue.

6.1.10. To ensure delivery of messages to the visually impaired, solution must have the ability to send both audible (voice or text-to-speech) and visual (text) notifications.

6.1.11. The solution must have the ability to provide login audit tracking.

6.1.12. Multiple instances of the application must run in geographically disperse locations in “active-active” mode so that if the application fails in one location, the application seamlessly directs users to a different active site.


EAS RFP

ReqNo.



Provide a list of locations and the type of services provided at each.

6.1.13. If the system does not support an “active-active” configuration, please provide information about the system failover process:

• What is the recovery process after a site failure?

• If your system uses a failover configuration or standby, is there any network or telephone capacity loss and what is it?

• If the system fails over, what steps are required on the customer side to continue operations?

• If the system fails over, what is the guaranteed maximum number of minutes before 100% of system services and capabilities are restored to a fail over site, in number of minutes.

• Please describe the ‘fail-back’ process from the backup site to the main site.

6.1.14. All system components must reside in multiple data centers including:

• Application database• Application servers• Web servers• Telephony servers

6.1.15. Data centers must be co-located at the telecommunications point of presence.

6.1.16. The system must have undergone an application usability test within the last 2 years. Provide the results of the test.

6.1.17. Service Level Agreements are provided, including SLA’s for response time and message delivery. Provide a copy of your standard SLA.

6.1.18. The system must run on most currently used PC configurations (e.g., Windows 2000, XP, Vista) and with currently used browsers). Describe the minimum requirements for existing PC workstations to access the notification system.

6.2. Recipient & Contact Information Management

6.2.1. The solution must have the ability to add or edit recipient and contact information directly within the solution. There must be an opt-in/opt-out feature.

6.2.2. The solution must have the ability to import all or some employee contact information from an existing database through a regularly scheduled process (e.g., PeopleSoft/Oracle HR, BCP Software, Colleague, Banner).


EAS RFP

ReqNo.



6.2.3. The solution must have the ability to add or change all or some contact data through an imported file in .csv, txt, or xls formats.

6.2.4. The solution must have the ability to send a notification to a list of recipients from a spreadsheet or database output file “on-the-fly” without storing the recipient’s contact information in the database.

6.2.5. The solution must have the ability to upload group and escalation information along with contact information.

6.2.6. The solution must have the ability to export existing recipient and contact information to Excel or a csv file.

6.2.7. The solution must have the ability to maintain privacy of all contact information through access control where only administrators with appropriate rights can view or update recipient and contact information.

6.2.8. The solution must have the ability to permit or restrict selected users from maintaining their own contact information.

6.2.9. Integrate with SDBOR Intranet portal, internet and learning systems.

6.3. Contact Devices

6.3.1. The solution must have the ability to notify recipients via:

1. Phone (land-line, mobile, satellite)2. BlackBerry3. PDA4. Text message5. Instant message6. Email7. Fax 8. 1-way and 2-way SMS 9. Web10. TTY

Please note any exceptions to the above.

6.3.2. The solution must have the ability to send native SMS text-messages, utilizing both SMS over SMPP and SMS over SMTP.

6.3.3. If the vendor’s software utilizes a third party aggregator(s) to collect SMS messages from the users and the aggregator then forwards them to the various cellular phone providers then the vendor must have a service agreement/contract.

6.3.4. Vendor must specify whether they have “white


EAS RFP

ReqNo.



listing” agreements with the various cell phone providers.

6.3.5. The solution must have the ability to receive confirmations on ALL of the contact devices listed above in 1.3.1 so as to not congest the local PSTN and Internet infrastructure after recipients have already received and confirmed message receipt.

6.3.6. The solution must have the ability to store and use at least 4 different contact numbers/addresses for each recipient.

6.3.7. The solution must have the ability to sequence the contact devices/paths so that a recipient’s devices are attempted in a prescribed order.

6.3.8. The solution must have the ability to provide two different sequences of contact devices depending on whether an emergency notification or a non-emergency notification is sent.

6.3.9. The solution must have the ability for an administrator to set the default order of devices used to contact recipients, but also allow users override the order if they have appropriate rights to do so.

6.3.10. When recipients are allowed to enter their own data, they should have the ability to mark their contact information private so that it cannot be viewed by anyone, including system administrators.

6.3.11. The solution must have the ability to customize the telephone number display (caller ID) for voice messages and the email addresses for text messages

6.3.12. The solution must have the ability to override call-blocking.

6.3.13. The solution must have the ability to customize a recorded voice greeting that precedes a message delivered by voice.

6.4. Group/Team/Organization Administration

6.4.1. The solution must have the ability to create groupings of recipients; for example by team, department, or division

6.4.2. The solution must have the ability to create hierarchical groupings so that groups include up to 5 levels of sub-groups in order to appropriately reflect an organization’s structure.

6.4.3. The solution must have the ability for a message recipient to be a member of any number of groups.


EAS RFP

ReqNo.



6.4.4. The solution must have the ability to assign multiple administrators complete access to all functions and user data.

6.4.5. In addition to having the ability to create groups within an organization, the ability to set up an organizational hierarchy where the administrators of the primary organization can view and send notifications to all secondary organizations and their groups and members.

6.5. Creating Notifications

Selecting Recipients for a Notification

6.5.1. The solution must have the ability to send a single notification to combinations of individuals and pre-defined groups of people where each individual within the group has their own contact information.

Creating Messages

6.5.2. The solution must have the ability to record a message directly from a message- creation-webpage using a telephone

6.5.3. The solution must have the ability to send both a recorded message and a text message in a single notification to all recipients for delivery to appropriate devices.

6.5.4. The solution must have the ability to select a file containing a recorded message for inclusion in a notification.

6.5.5. The solution must have the ability to enter a message in text and to have it converted to speech (i.e., “text-to-speech” conversion)

6.5.6. The solution must have the ability to create and save pre-recorded voice and text messages for later use

Notification Delivery Features

6.5.7. The solution must have the ability to request as many redial attempts as required and varying by notification.

6.5.8. The solution must have the ability to require a confirmation (or not).

6.5.9. The solution must have the ability to set up recurring notifications.

6.5.10. The solution must have the ability to escalate messages to other people when the intended recipient has not confirmed receipt of a message (with at three levels of person-to-person escalation)

6.5.11. The solution must have the ability to stop a broadcast at any point in time after initiation

6.5.12. The solution must have the ability to re-send a <Insert Name/Organization Here> of 37

EAS RFP

ReqNo.



notification to only those who did not respond to the original notification.

6.5.13. The solution must have the ability to select a subset of the available device types for delivery of a particular notification.

6.5.14. The solution must have the ability to pre-determine the duration of the broadcast (i.e., the length of time for which deliveries will be attempted)

6.5.15. The solution must have the ability to select the number of delivery attempts through all contact paths.

6.6. Reporting

6.6.1. The system must provide a dashboard for each active broadcast allowing users to perform functions by simply clicking on links and buttons to:

• See status of broadcast results without manually refreshing the page

• See confirmations and responses in real-time

6.6.2. The solution must have the ability to view history of notification results.

6.6.3. Notification/broadcast results reports must contain the following information:

1. Summary statistics including total contacts, total confirming receipt/not confirming receipt, %confirming/not confirming receipt.

2. Detailed calling information including call-result of each ATTEMPT within the broadcast including the addresses and associated phone numbers attempted, the attempt number (if multiple attempts/re-dials are requested) and the result:

• Confirmed (with date & time)

• Busy

• No Answer

• Voicemail Please note any exceptions the above.

6.6.4. The solution must have the ability to view broadcast results by either confirmed or non-confirmed responses or both.

6.6.5. The solution must have the ability to export all report data in CSV, HTML, or PDF format.

6.6.6. The solution must be able to save ad hoc reports into templates for later use.


EAS RFP

ReqNo.



6.6.7. The solution must store a copy of the notification (text and .wav file) for at least 18 months.

6.7. Customer Implementation, Training and Support

6.7.1. The contractor should present an implementation plan with a timeline from contract signature through user training with clearly identified roles and responsibilities for both Vendor and client. The plan must be able to be completed within 30 days of the date the contract is signed.

NA

6.7.2. Vendor should include initial training for all administrators, re-training, and new user training as part of the cost.

NA

6.7.3. Initial training should be provided onsite, or via a live meeting environment if requested by the client, and must offer the option to train all administrators on-site.

6.7.4. Vendor should offer printed training manuals as well as suggestions for use and best practices as part of the training process.

6.7.5. Vendor should offer unlimited 24/7/365 support for all users through a toll-free phone number at no additional cost.

6.7.6. Vendor’s support time should be ½ hour or less for all emergency issues, at all times of day or night.

6.7.7. Vendor should offer and explain in detail their ongoing customer support beyond initial training.

6.7.8. Vendor’s customer support personnel should be full-time, company-employed customer service professionals. These professionals must be dedicated to specific accounts for relationship building and trained specifically to support the needs of their respective vertical. Indicate whether a background check is performed on all support personnel before hiring.

6.7.9. Vendor should provide assurance that support will never be outsourced without notification.

6.7.10. Vendor should include technical support as part of the 24/7/365 included customer support.

6.7.11. Vendor should describe the redundancies in place to ensure support personnel are readily available.

6.7.12. Vendor should have no limitations on the number of times data transfers can be performed from the institution’s SIS and HR


EAS RFP

ReqNo.



system.

6.7.13. Vendor should provide the option of an online collection form to augment and update existing student contact data.

6.7.14. Vendor should be able to articulate specific examples of assistance provided throughout the year to meet the needs of faculty and staff.

6.7.15. Vendor should document how their support staff is hired, educated, and trained to support the specific needs of Higher Education Institutions.

6.8. Security

6.8.1. All network and application servers are “locked down” with no extraneous services running on them. Describe your network security.

6.8.2. The solution must have security to prevent inappropriate use and to maintain privacy of contacts including login/password authentication on the telephone and on the web.

6.8.3. SSL must be used to transmit data across the Internet. Describe your transmission security.

6.8.4. Key data must be encrypted in the database. Describe your database security and encryption practices and techniques.

6.8.5. Vendor staff has undergone Personnel security training. Describe the training.

6.8.6. The application must undergo a security audit and/or test at least once every two years. Provide the most recent security audit/test report.

6.8.7. Vendor must warrant that they provide background checks on all employees, and that only employees who have undergone said background checks will have access to client data.

6.8.8. Vendor should demonstrate state-of-the art system security, including, but not limited to, a description of company policies and procedures to ensure secure client data.

6.8.9. Vendor should provide a comprehensive privacy and security statement which outlines its contractual obligations to ensure secure client data.

6.8.10. Vendor should demonstrate regular, third party monitoring and review of all security procedures.

6.8.11. Vendor should demonstrate an adequate


EAS RFP

ReqNo.



business continuity plan and should discuss the methods used to ensure redundancy

6.8.12. Vendor should describe its data back-up and recovery policies.

6.8.13. Vendor should describe their ongoing maintenance and system testing procedures. Include in this response information relative to how new features are addressed.

6.9. System Capacity and Reliability

6.9.1. Vendor should certify capacity through contracted Service Level Agreements (SLAs) with multiple providers and state what those SLAs allow the Vendor to initiate on behalf of all of its clients. The Vendor must state what percentage of that capacity is utilized daily.

6.9.2. Vendor should provide an independently certified accounting of the highest volume of voice messages delivered to unique phone numbers exclusively though its ASP application (do not include the number of calls that clients send through auto-dialers) on behalf of its clients within a concurrent 24 hour period.

6.9.3. Vendor should state what percentage of its contracted capacity is used on a daily basis and provide information about how the service scales as clients’ needs grow.

6.9.4. Vendor should demonstrate sufficient understanding of “last mile” issues, i.e. congestion at the local level, when delivering calls so as to ensure call delivery.

6.9.5. Vendor should discuss its delivery strategy to maximize successful deliveries and indicate the average expected call delivery rate for successful and unsuccessful sends.

6.9.6. Vendor should explain what redundancies maximize assurance that calls are delivered.

6.9.7. Vendor should provide an example of an experience of successful call delivery during a time of highly impacted capacity.

6.10.Company Information

6.10.1. Vendor must demonstrate a minimum of 3 years experience in call-delivery operating as a fully-hosted Application Service Provider (ASP).

6.10.2. Vendor should demonstrate extensive experience in delivery of time-sensitive


EAS RFP

notifications, not just mass notifications. The system must be used regularly to deliver time-sensitive voice messages. Vendors should provide proof of delivery and volume counts per month and per year relative to the number of time-sensitive voice messages sent (excluding notifications sent as campaign calls or debt collection calls).

6.10.3. Vendors should demonstrate extensive experience in delivery of time-sensitive notifications within small, targeted geographic regions and have proven experience delivering a large number of calls within a small geographic zone. Vendors should indicate what percentage of time-sensitive notifications are sent within small geographic zones versus across the country (as is typical of calls sent on behalf of large corporations).

6.10.4. Vendor should demonstrate that they have developed unique ASP systems exclusively for post-secondary schools. The vendor may use feature sets to explain how they have tailored the system for specific vertical users.

6.10.5. Vendor should demonstrate proof of company financial stability.

6.10.6. Vendor should demonstrate efficient, reliable, ongoing management for internal cost-controls.

6.10.7. Vendor should give evidence of the long-term viability of the mass notification service. Address staffing, system architecture, and ability to ensure ongoing research and development.


EAS RFP

7. Implementation Plan 7.0 Project Schedule

Provide a project schedule that corresponds to the implementation approach. The project schedule should include:

1. Major tasks, subtasks, and task owner;

2. Task durations;

3. Task dependencies;

4. Deliverable dates (which can be in the form of milestones);

5. Other milestones

Express tasks in daily durations; example: Contact list upload and verification (1.5) working days, etc.


EAS RFP

8. Pricing 8.1 Pricing Information

The proposal must include all cost information relative to service fees, licensing, support, training, maintenance, interfaces, and other potential costs. All costs that would be incurred by customer should be provided. All costs related to obtaining, training and supporting the product are to be described in the cost proposal. Failure to include significant costs may result in rejection of the Respondent’s proposal.

Each proposal should address the following cost issues or options:

Costs Response1. Setup cost for each of the

SDBOR sites

2. Cost per notification event or per member

3. Initial setup using batch data feed from SDBOR systems

4. Fixed cost for unlimited usage on a yearly basis

5. Any ongoing cost for service/maintenance

6. Cost per notification for multiple devices

7. Multi-year contract discounts

8. Cost of phone number data loaded from 3rd party vendor

9. Provide costs for technical support and help desks, including options

10. Any upgrades costs

8.2 Discounts

Describe all discount structures, educational discounts, volume discounts, beta-site arrangements, special offers, etc. Clearly delineate thresholds and volumes necessary if discounts are scaled.

8.3 Consulting

Note the hourly rates for consulting services and any appropriate categories.

8.4 Maintenance & Upgrades

State the length of the initial warranty period and note what is included in the warranty. Then note the maintenance costs for each year after the warranty period.


EAS RFP

8.5 Add-Ons and Customizations

Indicate in the pricing information which deliverables recommended in the response require separate service agreements and any additional cost. All features detailed in a proposal shall function without any custom changes. However, Respondents must include information on the availability of customized add-on features and specific costing information for extended capabilities or additional modules not covered in this proposal, including any constraints of the SDBOR development of Application Programming Interfaces (APIs) to allow interface with other applications.

8.6 Sample License Agreement

A SDBOR contract with the terms and conditions required by the State of South Dakota is required. For reference for the SDBOR, include a sample copy of a typical license agreement and service level agreement used to formalize the Vendor’s legal relationship with an institution of higher education or other public entity. Variances between this sample and conditions required by the SDBOR do not constitute notification that the Vendor is taking exception to a term or condition. Vendor must clearly list any exceptions taken in the proposal submitted. The SDBOR reserves the right to reject a proposal on these grounds.

8.7 Upgrades and Licensing

It is understood that upgrades may be necessary or desirable over the length of the contract, and Respondents are expected to clearly delineate anticipated/necessary upgrades and their cost in accordance with the RFP instructions in Section 7. However, once any version of given EAS software or upgrades to EAS software are purchased by the SDBOR, that version can be used by the SDBOR during the period of the contract and shall not be revoked or made inoperable by the Respondent.

8.8 Prices and Terms of the Proposal

Prices and terms of the proposal as stated must be valid for the length of any resulting contract.


EAS RFP

9. Proposal Evaluation and Award 9.0 Evaluation CriteriaThe SDBOR intention is to procure the most functionally complete, cost-effective Emergency Notification system available. Responses to this RFP will be evaluated by a team representing selected user groups from the SDBOR system. The following criteria will be used as part of the evaluation and may be weighted equally or given separate weighting factors (consistent for all proposals):

1. Ease of Use (Administrators and Users)2. Technical Solution3. Compliance to Specifications4. Price5. References 6. Higher Education References

9.1 ReferencesThe SDBOR reserves the right to contact any or all references as part of the proposal evaluation process to assess the quality of work performed and personnel assigned to the project. The results of any references will be provided to the evaluation committee and used in evaluating the proposal.


10. Conditions 10.1 Rights Reserved by SDBOR

Not withstanding anything to the contrary, the SDBOR reserves its right to:1. Reject any and all proposals or parts of proposals received in response to this RFP;2. Select, for contract negotiation, a proposal other than the one with the lowest cost;3. Waive or modify any informalities, irregularities, or inconsistencies in proposals

received and/or accept a written modification requested by the SDBOR if the proposal itself was submitted on time and if the modified proposal is more favorable to the SDBOR;

4. Negotiate any aspect of the proposal with any Respondent;5. Terminate negotiations and select the next most responsive Respondent, prepare,

and release a new RFP, or take such action as deemed appropriate if negotiations fail to result in an agreement; and

6. Modify or clarify this RFP issuing one or more addenda to this RFP. Addenda will become part of this RFP. All addenda to this RFP will be posted on the EAS RFP web site with their effective date and time of posting reflected therein. Respondents are advised that they must reflect in their paper proposals that they have seen and reviewed all such addenda.

10.2 Right to Reject Proposals and Negotiate Contract Terms

The SDBOR reserves the right to reject any and all proposals. The SDBOR may negotiate the terms of the contract, including the award amount, with the awarded Respondent prior to entering into a contract. If contract negotiations cannot be concluded successfully with the top finalist, the SDBOR may negotiate a contract with another finalist. The SDBOR reserves the right to reject any and all proposals and to not award any contract. Multiple contract awards may be made, if in the best interest of the SDBOR.

10.3 Proposed Product Availability

The product detailed in this proposal must be available according to the following time-frame: core features are available for delivery no later than 35 calendar days after a contract is signed; interface features, if necessary, are available for installation no later than 60 calendar days after the master contract is signed.

10.4 Award and Final Offers

The award will be granted in one of two ways. The award may be granted to the highest ranked responsive and responsible Respondent. Alternatively, the highest ranked Respondent or Respondents may be requested to submit final and best offers. If final and best offers are requested by the SDBOR and submitted by the Respondent, they will be evaluated against the stated criteria by the evaluation committee. The award then will be granted to the highest ranked Respondent. However, a Respondent should not expect that the SDBOR will request a final and best offer.

10.5 Notification

All Respondents who respond to this RFP will be notified in writing of the SDBOR intent to award the contract as a result of this RFP by posting this information on the SDBOR EAS RFP web site.

10.6 Executed Contract to Constitute Entire Agreement

In the event of contract award, the contents of this RFP, all attachments, RFP addenda and revisions, the proposal of the successful Respondent, as well as any additional terms agreed to in writing shall become part of the contract. Failure of the successful Respondent to accept these as a contractual agreement may result in a cancellation of award.

10.7 Termination of Contract

The SDBOR may terminate the contract at any time at its sole discretion by delivering ninety (90) calendar days written notice to the Respondent. Upon termination, the SDBOR’s liability will be limited to the pro rata cost of the services performed as of the date of termination plus expenses incurred with the prior written approval of the SDBOR. In the event that the Respondent terminates the contract, for any reason whatsoever, it will refund to the SDBOR within ten (10) days of said termination, all payments made hereunder by the SDBOR to the Respondent for work not completed or not accepted by the SDBOR. Such termination will require written notice to that effect to be delivered by the Respondent to the SDBOR not less than one hundred eighty (180) calendar days prior to said termination.

10.8 Liquidated Damages

The Respondent acknowledges that the SDBOR could incur damages in the event there is significant downtime experienced. The SDBOR shall pass on the actual costs of damages incurred to the Respondent, not to exceed the total dollar value of the contract, for significant downtime experienced during the term of the contract, when the cause of the downtime is caused by failure of the product to perform as proposed. The Respondent agrees that the SDBOR shall have the right to liquidate such damages, through deduction from the Respondent's invoices, in the amount equal to the damages incurred, or by direct billing to the Respondent.

10.9 Disposition of Responses

All materials submitted in response to this RFP will become property of the SDBOR and except for proprietary information will become public record after the evaluation process is completed and an award decision made. Responses to this RFP will not be open for public review until the SDBOR decides to pursue a contract and that contract is awarded.

10.10 Product and Infrastructure Limitations

For any proposal, if the SDBOR determines that any product's ability to work with existing infrastructure will be prohibitively limited or difficult to manage, the proposal may be rejected.

10.11 Payment Requirements and Acceptance

The payment schedule and associated testing and acceptance schedule will be negotiated at the time of award.

10.12 Contract Terms

In preparing a response, Respondent must be aware of the following required SDBOR contract terms and conditions.

• Compensation will be for ALL services performed, unless a specific payment schedule is mutually agreed upon. The SDBOR DOES NOT make regular

payments based on the passage of time and pays only for services performed or work delivered AFTER it is accomplished in a satisfactory way.

• Payment is made only after the submission of an authorized invoice.• Reimbursement for travel and subsistence expenses actually incurred in

performance of a contract is limited. The SDBOR shall reimburse Contractor/Respondent for actual and reasonable travel expenses, in compliance with the State of South Dakota’s reimbursement policy. Generally, meals have a dollar limitation and reasonable and necessary travel and lodging is paid for at state rates. Payment shall be made within 30 days of receipt of a monthly or quarterly billing statement, including itemization and verification of travel expenses.

• Payment for services and product provided will not be made until features and functionality delineated in the Respondent contract are fully operational.

10.13 State Audit

The books, records, documents, and accounting practices and procedures of Respondents relevant to this contract shall be subject to examination by the SDBOR or State Auditor as appropriate.

10.14 Non-Appropriation

The SDBOR may terminate this Agreement immediately upon written notice if the South Dakota legislature fails to appropriate sufficient funds to make the required payments or if appropriations are reduced or its authority to spend appropriations is reduced or limited by law or by reductions in federal or grant funds to a level that the SDBOR determines is insufficient to make the payments.

10.15 Access Standards

To the extent required by applicable law, the electronic and information technology (EIT) to be delivered under this contract is capable of providing comparable access to individuals with disabilities consistent with the applicable provisions of the Architectural and Transportation Barriers Compliance Board (“Compliance Board”) set forth in 36 C.F.R. Part 1194.

To the extent the State is required by ruling, determination or order of a court, administrative law judge, or administrative agency of competent jurisdiction, to modify or replace the EIT to be delivered under this contract, or to obtain other software or hardware to operate in conjunction with the EIT, in order to provide reasonable accommodation to persons with handicapping conditions or to otherwise achieve compliance with any applicable requirements of the Americans With Disabilities Act or access standards issued by the Compliance Board under Section 508 of the Rehabilitation Act, Respondent agrees to cooperate with the State in good faith and with all due diligence to provide such modification and remediation services as may be necessary, or, if that is not possible, otherwise to assist the State in identifying such appropriate software, hardware, and associated services as may be available from other sources. In addition, Respondent agrees that it will engage in diligent, good faith efforts to improve accessibility of its software through planned modifications and enhancements to its user interfaces.

10.16 Liability

All Respondents in contracts with the SDBOR resulting from this RFP shall hold the State of South Dakota , its agents, and employees, harmless from any and all claims or causes of action of any kind or nature, including but not limited to claims by third parties that the Respondent has in any manner infringed upon the rights of such third parties in the use of any copyrighted or uncopyrighted composition, secret process, patented or unpatented invention, article or appliance furnished or used in the performance of this contract by the Respondent or Respondent’s agents or employees. This clause shall not be construed to bar any legal remedies the Respondent may have for the State’s failure to fulfill its obligations pursuant to this RFP.

10.17 Laws and Regulations

Any and all services, articles or equipment furnished shall comply fully with all state and federal laws and regulations.

10.18 Antitrust

Respondent shall assign to the State of South Dakota any and all claims for overcharges as to goods and/or services provided in connection with this contract resulting from antitrust violations which arise under the antitrust laws of the United States and the antitrust laws of the State of South Dakota.

10.19 Confidentiality and Compliance with Public Records Laws

RESPONDENT agrees not to use or disclose any information it receives from the SDBOR under this contract which the SDBOR has previously identified as confidential or exempt from mandatory public disclosure except as necessary to carry out the purposes of this contract or as authorized in advance by the SDBOR. The SDBOR agrees not to disclose any information it receives from RESPONDENT which the RESPONDENT has previously identified as confidential and which the SDBOR determines in its sole discretion is protected from mandatory public disclosure under a specific exception to the South Dakota open records law, South Dakota Codified Laws § 13-49-31. The duty of SDBOR and RESPONDENT to maintain confidentiality of information under this section continues beyond the term of this contract, including any extensions or renewals. RESPONDENT understands that, except for disclosures prohibited in this section, the SDBOR must disclose to the public upon request any records it receives from RESPONDENT under this contract. RESPONDENT further understands that any records which are obtained or generated by the RESPONDENT under this contract, except for records that are confidential under Section 17, may be open to the public upon request under the South Dakota open records law. RESPONDENT agrees to contact the SDBOR immediately upon receiving a request for information under the open records law and to comply with the SDBOR instructions on how to respond to the request.

10.20 Intellectual Property Indemnification

The Respondent warrants that any materials or products provided or produced or utilized in the performance of this order will not infringe or violate any patent, copyright, trade secret, trade names, service marks or names, or any other proprietary right of any third party. In the event of any such claim by any third party against the State, the State shall promptly notify the

Respondent and, the Respondent at the Respondent’s expense shall indemnify and defend the State against any losses, cost, expense, or liability (including reasonable attorney’s fees) arising out of such a claim, whether or not such claim is successful against the State.

10.21 Work Product, Equipment, and Materials

All work product, equipment or materials created or purchased under this contract belong to the SDBOR and must be delivered to the SDBOR upon request upon termination of this contract. RESPONDENT agrees that all materials prepared under this contract are "works for hire" within the meaning of the copyright laws of the United States and assigns to the SDBOR all rights and interests RESPONDENT may have in the materials it prepares under this contract, including any right to derivative use of the material. RESPONDENT shall execute all necessary documents to enable the SDBOR to protect its rights under this section.

10.22 Subcontractors

The SDBOR reserves the right to approve or reject any subcontractor used by a Respondent. The SDBOR must approve subcontractors before any work commences.

10.23 Completion of Services

The Respondent has sole and complete responsibility for the completion of all services provided under any contract, except for those items specifically defined as SDBOR responsibilities.

10.24 Insurance Requirements

a. Required Coverages. RESPONDENT will be required to secure and keep in force during the term of this contract and furnish satisfactory evidence of insurance from companies authorized to do business in South Dakota, the following insurance coverages covering the RESPONDENT for any and all claims of any nature which may in any manner arising out of or resulting from this contract:

1) Commercial general liability, including contractual coverage, and products or completed operations coverage (if applicable), with minimum liability limits of $250,000 per person and $1,000,000 per occurrence.

2) Automobile liability, with minimum liability limits of $250,000 per person and $1,000,000 per occurrence.

3) Workers compensation coverage meeting all South Dakota statutory requirements, including a) an “all states endorsement” to cover claims occurring outside the State of South Dakota if any of the services provided under this contract involve work outside the State of South Dakota; and b) employer’s liability or “stop gap” insurance of not less than $1,000,000 as an endorsement on the workers compensation or commercial general liability insurance if RESPONDENT is domiciled outside the State of South Dakota.

b. General Insurance Requirements. The insurance coverages listed above must meet the following additional requirements:

1) Any deductible or self insured retention or self-insured amount or other similar obligation under the policies shall be the sole responsibility of the RESPONDENT. The amount of any deductible or self-retention is subject to approval by the SDBOR.

2) This insurance may be in policy or policies of insurance, primary and excess, including the so-called umbrella or catastrophe form and must be placed and maintained for the term of this contract and any extensions with insurers rated “A” or better by A.M. Best Company, Inc., provided any excess policy follows form for coverage. The policies shall be in form and terms approved by the SDBOR. “Follows form” means the excess policy must be written with the same terms and conditions as the policy to which it is excess.

3) SOUTH DAKOTA will be defended, indemnified, saved and held harmless to the full extent of any coverage actually secured by the RESPONDENT in excess of the minimum requirements set forth above. The duty to indemnify SOUTH DAKOTA shall not be limited by the insurance required in this section.

4) SOUTH DAKOTA shall be endorsed on the commercial general liability policy, including any excess policies (to the extent applicable), automobile policy, and excess policies (to the extent applicable) as additional insureds. SOUTH DAKOTA shall have all the rights and coverages as RESPONDENT under said policies. The additional insured endorsement for the commercial general liability policy shall be written on a form equivalent to the ISO 1985 CG 20 10 form, or such other form as approved by the SDBOR, and the endorsement shall not limit or delete SOUTH DAKOTA’s coverage in any way based upon SOUTH DAKOTA’s acts or omissions.

5) The insurance required in this section, through a policy or endorsement, shall include:

a. A “Waiver of Subrogation” waiving any right of recovery the insurance company may have against SOUTH DAKOTA;

b. A provision that the policy and/or endorsements may not be canceled or modified without thirty (30) days’ prior written notice to the undersigned SDBOR representative;

c. A provision that any attorney who represents SOUTH DAKOTA under this policy must first qualify as and be appointed by the South Dakota Attorney General as a Special Assistant Attorney General as required under N.D.C.C. §54-12-08;

d. A provision that RESPONDENT’s insurance coverage shall be primary (i.e., pay first) as respects any insurance, self-insurance or self retention maintained by SOUTH DAKOTA and that any insurance, self-insurance or self retention maintained by SOUTH DAKOTA shall be excess of the RESPONDENT’s insurance and shall not contribute with it;

e. Cross liability/severability of interest coverage for all policies and endorsements.

6) The legal defense provided to SOUTH DAKOTA under the policy and any endorsements must be free of any conflicts of interest, even if retention of separate legal counsel for SOUTH DAKOTA is necessary.

7) RESPONDENT shall furnish a certificate of insurance, the additional insured endorsement adding SOUTH DAKOTA as an additional insured, and, if requested, a copy of the insurance policy and all its endorsements, to the undersigned SDBOR representative prior to commencement of this contract.

8) Failure to provide insurance as required in this section is a material breach of contract entitling SDBOR to terminate this contract at any time effective upon delivery of notice to RESPONDENT.

10.25 Alternative Dispute Resolution

The SDBOR does not agree to any form of binding arbitration, mediation, or other forms of mandatory alternative dispute resolution. The parties have the right to legal action to enforce available remedies.

10.26 Nondiscrimination and Compliance with Laws

RESPONDENT agrees to comply with all applicable laws, rules, regulations and policies, including but not limited to those relating to nondiscrimination, accessibility and civil rights. RESPONDENT agrees to timely file all required reports, make required payroll deductions, and timely pay all taxes and premiums owed, including but not limited to sales and use taxes and unemployment compensation and workers’ compensation. RESPONDENT shall have and keep current at all times during the term of this contract all licenses and permits required by law.

10.27 Prepayment

The SDBOR will not make any advance payments before performance by the RESPONDENT under this contract.

11. Customer References

COLLEGE OR UNIVERSITY:

Contact person:

Address:

Phone:

Fax #:

E-mail address:

Description of service provided:


Contact person:

Address:

Phone:

Fax #:

E-mail address:



Contact person:

Address:

Phone:

Fax #:

E-mail address:



Contact person:

Address:

Phone:

Fax #:

E-mail address:


south dakota board of regents

News & Politics