1 | P a g e

Solicitation Information April 7, 2017

RFP# 7551537 TITLE: Constituent Relationship Management System - The University of Rhode Island Office of Admission Submission Deadline: Friday May 5, 2017 @ 10:00 AM EST PRE-BID/ PROPOSAL CONFERENCE: No Questions concerning this solicitation must be received by the Division of Purchases at doa.purquestions9@purchasing.ri.gov no later than Friday April 14, 2017 @ 5:00PM (EST). Questions should be submitted in a Microsoft Word attachment. Please reference the RFP# on all correspondence. Questions received, if any, will be posted on the Division of Purchases’ website as an addendum to this solicitation. It is the responsibility of all interested parties to download this information.

BID SURETY BOND REQUIRED: NO

PAYMENT AND PERFORMANCE BOND REQUIRED: No

Sharon Louro, Buyer I

Applicants must register on-line at the State Purchasing Website at www.purchasing.ri.gov

Note to Applicants:

Proposals received without the entire completed Rhode Island Vendor Information Program (“RIVIP”) generated Bidder Certification Cover Form attached may result in disqualification.

THIS PAGE IS NOT A BIDDER CERTIFICATION COVER FORM

2 | P a g e

Table of Contents SECTION 1. INTRODUCTION.................................................................................................. 3

Instructions and Notifications to Offerors ............................................................................................................. 3

SECTION 2. BACKGROUND .................................................................................................... 5

SECTION 3: SCOPE OF WORK AND REQUIREMENTS .......................................... 6 General Scope of Work ..................................................................................................................................... 6

SECTION 4: TECHNICAL PROPOSAL ........................................................................... 7

SECTION 5: COST PROPOSAL ........................................................................................ 19

SECTION6: EVALUATION AND SELECTION ........................................................... 19

SECTION 7. QUESTIONS AND PROPOSAL SUBMISSION .............................................. 20

SECTION 8. PROPOSAL CONTENTS ................................................................................... 21

SECTION 9. CONCLUDING STATEMENTS ....................................................................... 23

3 | P a g e

SECTION 1. INTRODUCTION The Rhode Island Department of Administration/Division of Purchases, on behalf of the University of Rhode Island Office of Admission is soliciting proposals from qualified firms to provide an admission and recruitment system/constituent relationship management system (CRM), in accordance with the terms of this Request for Proposals (“RFP”) and the State’s General Conditions of Purchase, which may be obtained at the Division of Purchases’ website at www.purchasing.ri.gov. The initial contract period approximate start date will be 7/1/2017 for one year with an option to renew for three (3) additional 12 month terms, based on vendor performance and the availability of funds.

This is a Request for Proposals, not a Request for Quotes. Responses will be evaluated on the basis of the relative merits of the proposal, in addition to cost; there will be no public opening and reading of responses received by the Division of Purchases pursuant to this Request, other than to name those offerors who have submitted proposals.

Instructions and Notifications to Offerors 1. Potential vendors are advised to review all sections of this RFP carefully and

to follow instructions completely, as failure to make a complete submission as described elsewhere herein may result in rejection of the proposal.

2. Alternative approaches and/or methodologies to accomplish the desired or intended results of this procurement are solicited. However, proposals which depart from or materially alter the terms, requirements, or scope of work defined by this RFP will be rejected as being non-responsive.

3. All costs associated with developing or submitting a proposal in response to this RFP, or to provide oral or written clarification of its content shall be borne by the vendor. The State assumes no responsibility for these costs.

4. Proposals are considered to be irrevocable for a period of not less than 120 days following the opening date, and may not be withdrawn, except with the express written permission of the State Purchasing Agent. The State can opt to extend this term at its discretion.

5. All pricing submitted will be considered to be firm and fixed unless otherwise indicated herein.

6. Proposals misdirected to other state locations, or which are otherwise not present in the Division of Purchases at the time of opening for any cause will be determined to be late and will not be considered. For the purposes of this

4 | P a g e

requirement, the official time and date shall be that of the time clock in the reception area of the Division of Purchases.

7. It is intended that an award pursuant to this RFP will be made to a prime vendor, or prime vendors in the various categories, who will assume responsibility for all aspects of the work. Joint venture and cooperative proposals will not be considered. Subcontracts are permitted, provided that their use is clearly indicated in the vendor’s proposal and the subcontractor(s) to be used is identified in the proposal.

8. All proposals should include the vendor’s FEIN or Social Security number as evidenced by a W9, downloadable from the Division of Purchases’ website at www.purchasing.ri.gov.

9. The purchase of services under an award made pursuant to this RFP will be contingent on the availability of funds.

10. Vendors are advised that all materials submitted to the State for consideration in response to this RFP may be considered to be public records as defined in R. I. Gen. Laws § 38-2-1, et seq. and may be released for inspection upon request once an award has been made. Any information submitted to the State through this RFP that a vendor believes is trade secrets or commercial or financial information which is of a privileged or confidential nature should be clearly marked as such. The vendor should provide a brief explanation as to why each portion of information that is marked should be withheld from public disclosure. Vendors are advised that the State may release records marked confidential by a vendor upon a public records request if the State determines the marked information does not fall within the category of trade secrets or commercial or financial information which is of a privileged or confidential nature.

11. Interested parties are instructed to peruse the Division of Purchases website on a regular basis, as additional information relating to this solicitation may be released in the form of an addendum to this RFP.

12. Equal Employment Opportunity (R. I. Gen. Laws § 28-5.1-1, et seq.) – § 28-5.1-1 Declaration of policy – (a) Equal opportunity and affirmative action toward its achievement is the policy of all units of Rhode Island state government, including all public and quasi-public agencies, commissions, boards and authorities, and in the classified, unclassified, and non-classified services of state employment. This policy applies to all areas where State dollars are spent, in employment, public services, grants and financial assistance, and in state licensing and regulation. For further information, contact the Rhode Island Equal Employment Opportunity Office, at 222-3090 or via e-mail at Krystal.Waters@doa.ri.gov .

5 | P a g e

13. In accordance with R. I. Gen. Laws § 7-1.2-1, et seq., no foreign corporation, a corporation without a Rhode Island business address, shall have the right to transact business in the State until it shall have procured a Certificate of Authority to do so from the Rhode Island Department of State (401-222-3040). This is a requirement only of the successful vendor(s).

14. The vendor should be aware of the State’s Minority Business Enterprise (MBE) requirements, which address the State’s goal of ten percent (10%) participation by MBE’s in all State procurements. For further information visit the website www.mbe.ri.gov

SECTION 2. BACKGROUND The University of Rhode Island is a public university with 14,560 undergraduate and 2,306 graduate students. The university strives each year to enroll a diverse undergraduate class of new freshman and transfer students from the state of Rhode Island as well as from other states and countries. The Office of Admission seeks to enroll students who are prepared to be successful at the University, who possess a variety of talents and strengths, who are committed to becoming contributing members of the community, and who will be stimulated and challenged by doing undergraduate work in an environment that includes scholarly research and graduate study.

Currently, the Office of Admission uses various methods for gathering, retaining, and retrieving information about, and communicating with, prospective students and their families for recruitment, school counselors for recruitment of prospective students, and alumni for assistance with recruitment initiatives. The Office of Admission uses different solutions for:

• Prospective Student Record Management

• Recruiter-to-Lead Communication

• Shared E-mail Inbox Management

• Chat

• Online Admission Application

• Large Scale mailing (e-mail and postal)

• Reporting

• Address Cleansing

• Duplicate Record Resolution

• Data Entry

• On-and off-campus events

6 | P a g e

• Application document management and workflow

• Application file review and admission decision rendering

Some of the vendors/partners in use for the above activities are:

• Hobsons Connect

• PeopleSoft (application communication, application status check, generation of decision letters)

• Hobsons Group Chat

• Common Application

• Nolij

• Microsoft Office

• GMAIL/Google Services

• SurveyMonkey

• PeerPoint

The goal of the CRM product will be to provide all of the above functionality in a single solution. Data conversion from some of these systems will be needed.

SECTION 3: SCOPE OF WORK General Scope of Work The successful bidder will provide the University of Rhode Island with a CRM that will allow consistent and comprehensive management of undergraduate prospecting, marketing/recruitment, event management, travel management, individual and mass communications (email and postal), reporting, analysis, and admission application review and document processing. Moreover, the solution will provide an intuitive and user-friendly tool that increases and enhances functional users’ efficiency, productivity, flexibility, capabilities, proactive and seamless interactions/initiatives, and successful enrollment management outcomes. The primary focus for this award and implementation will be to achieve comprehensive functionality that reduces data integrations and ongoing training requirements by centralizing admission activities in one system. The Office of Admission is responsible for the recruitment and admission for all undergraduate students at the University of Rhode Island, and works with approximately 40,000 prospective students, and 23,000 student applicants throughout an application cycle.

7 | P a g e

SECTION 4: TECHNICAL PROPOSAL 1. Technical Requirements

1.1. URI realizes there are often various hosting options. Please describe the solution’s

Software as a Service (SaaS), hosted, and onsite deployment environments. Detail the

hardware and/or software requirements of each environment and the implementation,

administration, and maintenance costs for each environment.

1.1.1. For hosted or SaaS environments, please outline uptime and downtime.

1.1.2. For hosted solutions, please explain if URI can directly query the underlying

database.

1.2. We require test and production instances of the CRM solution. Detail how these

instances would be provided.

1.3. We require a bidirectional data exchange between the CRM solution and our student

information system. Detail whether a PeopleSoft interface is available as part of the

CRM solution, whether it is standard or customized, and whether it is batch or real-

time.

1.3.1. Explain how the scheduling of routine data transfer is automated.

1.3.2. Explain by what means would we define the frequency of data exchange for two-

way exchanges.

1.3.3. What security protections are afforded by the solution?

1.4. Describe past successful deployments with your proposed solution with other

PeopleSoft Campus Solutions institutions.

1.4.1. Examples should represent clients currently using a CRM solution that is the

same, or very similar to, the solution being proposed for URI.

1.4.2. Describe your most difficult implementation.

1.4.2.1. Explain how you overcame specific challenges.

1.5. How does the product handle U.S. postal address validation?

1.6. How does the product handle out-of-country address validation?

1.7. Upgrades to system

1.7.1. How often is the software updated and releases made available?

1.7.2. Define the documentation and ongoing support provided for updates and/or

releases.

8 | P a g e

1.7.3. What release/version are you proposing for the University? When is the next

release or version rolling out?

1.7.4. Explain the impact on university IT staff. Please include information about the

expected roles and responsibilities for IT staff.

1.7.5. Explain how patches or updates released during implementation would be

handled.

1.8. Upgrades to PeopleSoft may impact the proposed solution.

1.8.1. Explain how upgrades to PeopleSoft could impact the CRM. There are many

types of updates, but in general, how is the interface/integration designed to

accommodate this situation?

1.9. The proposed solution will require no third-party vendors to carryout various

workflows.

1.9.1. Does the proposed solution require any third party vendors?

1.9.2. What security protections does a third party provide? Can they show evidence

that they have been audited, accredited, or reviewed by an independent auditor?

1.10. Who is responsible for installing patches, updates, and releases?

1.11. We require the ability to collect various types of payments (application fees,

enrollment deposits, etc.).

1.11.1. Describe payment functionality within the proposed solution.

1.12. Proposed solution must comply with ADA accessibility and responsive web design

standards.

1.12.1. Explain how the proposed solution modifies its behavior and/or interfaces based

on the capabilities of the user’s client computing device. List supported user-

computing devices detailing what portion of full functionality is available to users

of each device.

1.12.2. Describe all mobile platforms supported by the solution and how they interact

with the solution.

1.13. We require that the solution must have the capacity to easily, automatically, and

routinely export underlying raw data tables. Any adopted data tool's underlying

database structure must be documented and transparently available to University

personnel, i.e. not "proprietary" or otherwise unavailable for normal operational and

outcomes reporting. This is so that the data collected and extracted from the tool can

9 | P a g e

be understood and incorporated into the existing reporting mechanisms for the

University.

1.13.1. If hosted, what are the provisions for URI extracting data?

1.14. The new solution will need to be loaded with data from Hobsons Connect and from

PeopleSoft.

1.14.1. Explain past experiences with data conversion from an existing CRM application

to the new CRM. Are conversion scripts provided?

1.15. Currently, the University utilizes a campus-wide document imaging solution. We also

require a CRM system that supports document imaging for application records such

that all materials/documents are stored with the student record and are easily

viewable.

1.15.1. Describe the document imaging and document workflow capabilities including

interactions with third-party document imaging solutions. There will be a need to

migrate documents from within the proposed solution to another imaging system

for campus-wide use. Please list all document imaging systems that are

compatible.

1.15.2. Explain how the data exchange between the solution and a document imaging

system would occur.

1.16. We require the ability to manually and/or automatically purge and/or archive student

records based upon business rules and policies of the University.

1.16.1. Explain how records are archived or purged, including options for URI to

determine a schedule.

1.16.2. Are there storage capacity limits?

1.17. URI receives names and associated data from a variety of sources, which must be

loaded into the system.

1.17.1. Explain the prospective student name load process for both manual and

automated imports with approximate load times per 1,000 students, including all

list clean-up, load times, and duplicate record check.

1.17.2. List and describe any existing import solutions for third-party lead generation

services (ex: Cappex, Carnegie, YouVisit, Naviance, etc.)

1.17.3. Explain the system’s ability to incorporate test score loads from CollegeBoard

(PSAT, SAT, AP), ACT, TOEFL, and IELTS.

10 | P a g e

1.18. Access, Permissions, Security

1.18.1. Describe how user accounts are created and administered.

1.18.2. Explain how the solution authenticates users.

1.18.3. Are there capabilities to utilize the single sign-on model such as Shibboleth, CAS,

etc.?

1.18.4. Authorization should be handled within the system and provide different levels

of access for different jobs or roles within a department or the institution. System

functions must be able to be secured at various levels. How does this system

provide for different levels of role-based security?

1.18.5. Describe the audit trail capabilities, including reports.

2. Admission Application and Processing

2.1. We require a solution that follows a student throughout the entire admission cycle,

including inquiry creation, application and associated document storage, online

application portal, online decision communication, application checklist and “to do”

items accessible through portal, and support of a seamless transition of documents

post-matriculation.

2.1.1. Currently, the University is Common Application exclusive.

2.1.1.1. Does the proposed solution have a predefined layout with The Common

Application?

2.1.1.1.1. If yes, who manages the data feeds and documents from The Common

Application?

2.1.1.2. Does the student portal support the ability for students to check received

and missing application items?

2.1.1.2.1. Is the “checklist” auto-generated? What drives these items to be

placed on the checklist?

2.1.1.2.2. Can additional items be added to a student’s checklist by another

division (ex: financial aid)?

2.1.1.3. Is there the ability to create a portal view of targeted messaging to

applicants based on their status?

2.1.1.4. Does the portal support posting of an admission decision, a student’s reply

to the admission decision, and the ability to pay enrollment deposits?

2.1.2. Is an online letter of admission decision offered?

11 | P a g e

2.1.3. What specific tools or knowledge would the functional user editing the

application need to have?

2.1.4. What are the restrictions to the number of or types of documents that can be

attached to the student application?

2.1.5. Explain how duplicate identities are minimized.

2.1.6. Explain how application fee waivers are supported, including security,

administration, and tracking.

2.1.7. Does the proposed solution allow for the charging of different application fees

for a single application based on answers provided? (ex: domestic vs international)

2.1.8. Can a functional user using data in various fields create calculations within the

database?

2.1.9. Does the proposed solution support the import and storage of application data if

the system’s native application is not used?

2.1.10. Does the system provide its own application?

2.1.11. Does the application utilize “skip logic” to show specific questions based on how

previous questions are answered?

2.1.12. Is the application mobile friendly?

2.1.13. Does the application dynamically display instructions based on previous

answers?

2.1.14. Does the application validate data in real-time (address validation, date of birth

authentication, email etc.)

3. Communication and Marketing

3.1. The system must support the upload, tracking, and communication via various types of

channels for a variety of unique record types such as school counselors, prospects,

applicants, alumni volunteers, employers, parents/guardians of prospective students,

and others.

3.1.1. Please explain how this requirement is supported.

3.2. The system must provide an analysis of emails opened/viewed, links accessed, those

deleted without opening, unsubscribes/opt-outs, or deleted after reading within

individual campaigns, and aggregate reports from all active campaigns.

3.2.1. Please explain this functionality within the system.

12 | P a g e

3.3. The University uses Google for employee email. Is the software integrated or able to

use the Gmail interface? If the solution uses something different, please elaborate.

3.4. University departments each have separate email accounts (including several accounts

within the Office of Admission), which are used to identify the sending department to

the receiver.

3.4.1. Please explain how the system supports sending automated preplanned email

communication from a variety of mailboxes/aliases or provide another option that

achieves the same goal.

3.5. Please explain how the system supports the individual inbound and outbound message

management within shared email inboxes or provide another option that achieves the

same goal.

3.6. We require that functional users have the ability to create or modify campaigns.

3.6.1. Explain what types of campaigns cannot be created by a trained functional user.

3.6.2. Provide a detailed explanation of how functional users build, edit, test, query,

schedule (start and end dates/times) campaigns.

3.6.3. Can campaigns be scheduled automatically? The solution must allow us to send

to an unlimited number of recipients.

3.6.3.1. Does the solution satisfy this requirement?

3.6.4. Describe how the solution uses:

3.6.4.1. HTML E-mail

3.6.4.2. SMS Text

3.6.4.3. Mail merges for executing mailings in house (ex: letters)

3.7. We currently use both print and electronic communication strategies.

3.7.1. Explain how the system supports the preparation of postal mailing lists in

standard formats (ex: alpha order, zip order, etc.).

3.7.2. Explain how the system supports the batching of bulk mailings, meeting the

designated U.S. Postal Service requirements for bulk mail.

3.8. Does the software allow for inventory management of print materials?

3.9. Explain how the solution provides the ability to merge conditional content based on

constituent information into print and electronic communications.

3.10. We seek to have a high electronic communication deliverability rate.

3.10.1. Explain how the system allows functionality for simple A/B split testing.

13 | P a g e

3.10.2. Explain what tools/best practices are used to ensure that emails are not blocked

or blacklisted?

3.10.3. What automated quality/accuracy checks are executed before email campaigns

are launched?

3.10.4. Explain how email opt-outs and temporary and permanent bounce backs are

handled.

3.11. Describe how you would provide the following features and functionality for other

communication channels such as inbound and outbound calls, social media, and SMS

text messaging.

3.12. Does the system allow users to opt-in to receive regular notices about specific

offerings, general offerings, newsletters, text messages, or all available electronic or

mail materials? Are recipients able to select their preferred modes of interaction?

3.13. Can functional users easily develop workflows that assign tasks and populations of

prospects to various recruiters or staff?

3.14. Can functional users easily develop and export reports into a standard format?

3.15. Can functional users easily develop dashboards within the system for key performance

indicators?

3.16. Does the system prevent sending too many emails to a single recipient in a short time

frame?

3.16.1. If yes, does the solution determine order/priority of multiple emails?

3.17. Does the system support the ability to stop or shift communications to alternate

campaigns when certain criteria are met (ex: a student submits an application), while

eliminating duplicate communications?

3.18. Does the system allow for constituents to be targeted for communications based on

past actions or lack thereof, such as clicking a link, forwarding an email to a friend, or

not opening or clicking an email sent?

3.19. Does the system allow for personalization of the subject line and email content with

any constituent data captured in the system?

3.20. Does the system allow one constituent to have and communicate with multiple email

addresses (ex: personal email address and University of Rhode Island email address)?

3.21. Does the system allow for multiple constituents to share the same email address?

14 | P a g e

3.21.1. How does the solution manage multiple individuals sharing the same email

account?

3.22. Does the system allow for the creation of a plain text version of an HTML email?

3.23. Does the system allow for HTML email templates to be uploaded to the system?

3.24. Does the system automatically create a web-based version of the email hosted

through the CRM?

3.25. Does the system offer email client testing that provides a screenshot of how the email

rendered in the top email clients, including mobile devices (iPhone, iPad, Android,

Gmail, Yahoo! Mail, AppleMail, etc.)?

3.26. Does the system have reporting that displays email client usage devices (percentages

that use iPhone, iPad, Android, Gmail, Yahoo! Mail, AppleMail, etc.)?

3.27. Can the system provide Google Analytics integration (predefined campaign, source

and medium)?

15 | P a g e

4. Event Management

4.1. Provide a detailed explanation of the event management module provided by the

proposed system.

4.2. Does the system support password protection for events not open to the public?

4.3. Explain how functional users check-in registrants (ex: online from a mobile device or

offline with a report in a standard format).

4.4. Explain the options for electronically publishing events (ex: calendar vs. list format) and

functional users’ customization abilities.

4.5. Explain the ability to enter registrant information for people with no inquiry record (ex:

constituent’s family members; possibly a separate table in solution for parent/family

data).

4.6. Does the system have the ability to set attendance capacity limits?

4.7. Can the system support the creation of waiting lists for events that are at capacity?

4.7.1. If yes, do wait list registrants automatically move from the wait list to the

registration list as space becomes available?

4.8. Does the system support automated communication (confirmations, reminders, follow-

ups, satisfaction surveys, etc.)

4.9. Detail the integration of event registration and attendance with existing inquiry

records.

4.10. What is the mechanism for resolving duplicate submissions? Will the proposed system

automatically de-duplicate the registration list?

5. Travel Management

5.1. The system must provide a way to manage the Office of Admission’s travel activities

including planning, administering, executing, and reporting. Events (college fairs, high

school visits, interviews, etc.) should be accessible to various administrative and

professional staff.

16 | P a g e

5.2. Please detail the travel management module within the solution.

5.3. Explain how the system organizes and manages prospects’ data collected by travelers.

5.4. Explain how the system tracks event details (date, time, and location).

5.5. Explain how the system tracks required travel materials for events/activities.

5.6. Explain how the system allows for the assignment of recruitment travel events to

specified users based on various types of logic (ex: type of event, geographic location,

target audience of event, etc.)

5.7. Explain how the system allows for input of feedback following the event.

5.8. Explain how the system integrates with any GPS mapping services.

5.9. Is there functionality to plan travel using geographic data of students in specific areas?

5.10. Explain how the system displays multiple or recruiter specific events (ex: list vs.

calendar format).

5.11. Describe system integrations with calendars (ex: Outlook, Google Calendars,

iCalendar, etc.)

5.12. Explain how the system organizes and tracks expenses for travelers.

5.13. Explain how the system connects data points between recruitment travel events and

prospective student records.

5.14. Explain how the system allows us to capture contact information for multiple

individuals at high schools, community colleges, etc.

5.15. Does the system allow for the assignment of the student record to a specific staff

member based on geographic information?

5.15.1. Other than address, what other data points are used to determine a student’s

geographic territory? (ex: CollegeBoard EPS, county, zip code, etc.)

17 | P a g e

5.16. Does the solution allow for recruiters to have mobile-friendly access to view, edit, and

update event information?

5.17. Does the system come with built in searchable lists of high schools and colleges?

5.17.1. How are these lists maintained as new institutions are added?

6. Online Inquiry Form

6.1. Describe how the ability to pass values into visible and hidden form fields.

6.2. Describe search/match capabilities that prevent the creation of duplicate inquiry

records upon submission of form (duplicate checking process could be manual or

automated).

6.3. If CRM inquiry record exists, does the system modify inquiry record by adding to fields

that were previously blank?

6.4. Does the solution allow and track updates to pre-existing inquiry forms?

7. Reporting

7.1. We require a robust reporting tool, pre-delivered, and fully customizable reports that

showcase the full functionality of the proposed system.

7.1.1. Explain how functional users create reports.

7.1.2. What limitations exist for end-user reporting?

7.1.3. Detail the system’s reporting module.

7.1.4. Explain how the proposed system provides reporting of basic analytics reflecting

effectiveness and ROI of communication campaigns.

7.1.5. Describe any automation the system provides with delivering of reports.

7.1.6. Are there any reporting features that are exclusive to this product?

7.1.7. What integrations and/or partnerships are available to leverage data for

predictive modeling?

8. Implementation

8.1. Describe the implementation strategy and best practice options for implementing the

proposed solution.

8.2. Provide an overview of the tasks and timelines required for implementation.

8.3. What steps should be completed by URI prior to or during the initial stages

implementation?

18 | P a g e

8.4. Identify any third-party vendors involved in your implementation strategy and describe

these relationships. Indicate whether these relationships are required or optional for

implementation of the proposed solution. Be sure to detail associated costs and

requirements related to the third party vendor.

8.5. Provide a recommended training approach.

8.5.1. Detail the various types of users and include whether training is provided on-site,

off-site, or online.

Describe your post-implementation customer support model including any priority system to provide for urgent support, hours of operation, location of support services, methods of support (ticket, phone, chat, etc.…) and any planned changes to this including turnaround time. Complete a separate SIG Questionnaire: The Standards Information Gathering Questionnaire may be accessed electronically at https://security.uri.edu/forms/sig and will need to be completed by each vendor. The “SIG” is intended to simplify and speed up the process of gathering the information to assess the controls used by your organization to protect the University’s data, comply with the terms of the Agreement and to provide an operationally stable, protected and recoverable service. Your printed completed copy of the SIG, provided with your RFP response, will be reviewed and approved for compliance by the Associate Director of Information Security prior to the Technical Review. SIGs not approved by the URI Director of Information Security will not proceed to the Technical Review.

19 | P a g e

SECTION 5: COST PROPOSAL

A separate, signed and sealed, Cost Proposal reflecting the fee structure proposed for this scope of service.

Requested breakdown of cost and fees/rates

Annual contract fee

Description of cost structure

Description of cost structure for third-party vendor integrations

Description of cost structure for on-going maintenance/updates/upgrades

Description of cost structure for implementation

Description of cost structure for training

Description of cost structure for text messaging service(s)

SECTION6: EVALUATION AND SELECTION

Proposals will be reviewed by a Technical Review Committee comprised of staff from state agencies. To advance to the Cost Evaluation phase, the Technical Proposal must receive a minimum of 60 (85.7%) out of a maximum of 70 technical points. Any technical proposals scoring less than 60 points will not have the cost component opened and evaluated. The proposal will be dropped from further consideration. Proposals scoring 60 technical points or higher will be evaluated for cost and assigned up to a maximum of 30 points in cost category, bringing the potential maximum score to 100 points. The State reserves the right to select the individual(s) or firm (“vendor”) that it deems to be in the State’s best interest to accomplish the project as specified herein; and conversely, reserves the right to cancel the solicitation in its entirety.

20 | P a g e

Proposals will be reviewed and scored based upon the following criteria:

Criteria Possible Points

Technical Requirements 10 Admission Application and Processing 10 Communication and Marketing 10 Event Management 10 Travel Management 10 Online Inquiry Form SIG Questionnaire 5 Reporting 5 Implementation 10 Total Possible Technical Points 70 Cost calculated as lowest responsive cost proposal divided by (this cost proposal) times 30 points *

30 Points

Total Possible Points 100

*The Low Vendor will receive one hundred percent (100%) of the available points for cost. All other Vendors will be awarded cost points based upon the following formula: (low bid / vendors bid) * available points For example: If the low Vendor (Vendor A) bids $65,000 and Vendor B bids $100,000 for monthly cost and service fee and the total points available are Thirty (30), vendor B’s cost points are calculated as follows: $65,000 / $100,000 * 30= 19.5 Points will be assigned based on the offeror’s clear demonstration of his/her abilities to complete the work, apply appropriate methods to complete the work, create innovative solutions and quality of past performance in similar projects. Applicants may be required to submit additional written information or be asked to make an oral presentation before the technical review committee to clarify statements made in their proposal.

SECTION 7. QUESTIONS AND PROPOSAL SUBMISSION Questions concerning this solicitation must be e-mailed to the Division of Purchases at doa.purquestions9@purchasing.ri.gov no later than the date and time indicated on page one of this solicitation. No other contact with State parties is permitted. Please reference RFP #7551537 on all correspondence. Questions should be submitted in writing in a Microsoft Word attachment in a narrative format with no tables. Answers to questions received, if any, will be posted on the Division of Purchases’ website as an addendum to this solicitation. It is the

21 | P a g e

responsibility of all interested parties to monitor the Division of Purchases website for any procurement related postings such as addenda. If technical assistance is required, call the Help Desk at (401) 574-8100. Interested offerors must submit proposals to provide the services covered by this Request on or before the date and time listed on the cover page of this solicitation. Responses received after this date and time, as registered by the official time clock in the reception area of the Division of Purchases shall not be accepted.

Responses should be mailed or hand-delivered in a sealed envelope marked “RFP# 7551537” to:

RI Dept. of Administration Division of Purchases, 2nd floor

One Capitol Hill Providence, RI 02908-5855

NOTE: Proposals received after the above-referenced due date and time shall not be accepted. Proposals misdirected to other State locations or those not presented to the Division of Purchases by the scheduled due date and time shall be determined to be late and shall not be accepted. Proposals faxed, or emailed, to the Division of Purchases shall not be accepted. The official time clock is in the reception area of the Division of Purchases. SECTION 8. PROPOSAL CONTENTS A. Proposals shall include the following:

1. One completed and signed RIVIP generated Bidder Certification Cover Form (included in the original copy only) downloaded from the RI Division of website at www.purchasing.ri.gov. Do not include any copies in the Technical or Cost proposals.

2. One completed and signed Rhode Island W-9 (included in the original copy only)

downloaded from the RI Division of Purchases website at http://www.purchasing.ri.gov/rivip/publicdocuments/fw9.pdf . Do not include any copies in the Technical or Cost proposals.

3. A completed SIG Questionnaire https://security.uri.edu/forms/sig

4. A Separate Technical Proposal – Describing sections 1-8 in Section 4

a. One (1) Electronic copy on a CD-R, marked “Technical Proposal - Original”.

b. One (1) printed Paper copy, marked “Technical Proposal -Original” and signed.

c. Eight (8) printed Paper copies

5. A separate, signed and sealed Cost Proposal – A separate, signed and sealed Cost Proposal

22 | P a g e

as outlined in Section 5. a. One (1) Electronic copy on a CD-R, marked “Cost Proposal -Original”. b. One (1) printed Paper copy, marked “Cost Proposal -Original” and

signed. c. Four (4) printed Paper copies

B. Formatting of Proposal Response Contents shall consist of the following:

1. Formatting of CD-Rs – Separate CD-Rs are required for the Technical Proposal and Cost

Proposal. All CD-Rs submitted must be labeled with: a. Vendor’s name b. RFP # c. RFP Title d. Proposal Type (e.g., Technical Proposal or Cost Proposal) e. If file sizes require more than one CD-R, multiple CD-Rs are acceptable. Each

CD-R must include the above labeling and additional labeling of how many CD-Rs should be accounted for (e.g., 3 CD-Rs are submitted for a technical proposal and each CD-R should have additional label of ‘1 of 3’ on first CD-R, ‘2 of 3’ on second CD-R, ‘3 of 3’ on third CD-R).

Vendors are responsible for testing their CD-Rs before submission as the State’s inability to read your CD-Rs may be grounds for rejection of a Vendor’s proposal. All files should be readable and readily accessible on the CD-Rs submitted with no instructions to download files from any external resource(s). If a file is partial, corrupt or unreadable, the State may consider it “non-responsive”. USB Drives or any other electronic media shall not be accepted. Please note that CD-Rs submitted, shall not be returned.

2. Formatting of written documents and printed copies:

a. For clarity, the Technical Proposal shall be typed. These documents shall be single-spaced with 1” margins on white 8.5”x 11” paper using a font of 12 point Calibri or 12 point Times New Roman.

b. All pages on the Technical Proposal are to be sequentially numbered in the footer, starting with number 1 on the first page of the narrative (this does not include the cover page or table of contents) through to the end, including all forms and attachments. The Vendor’s name should appear on every page, including attachments. Each attachment should be referenced appropriately within the proposal section and the attachment title should reference the proposal section it is applicable to.

c. The Cost Proposal shall be typed addressing each element of the cost proposal breakdown as outlined in Section 5

d. Printed copies are to be only bound with removable binder clips.

23 | P a g e

SECTION 9. CONCLUDING STATEMENTS

Notwithstanding the above, the State reserves the right to award on the basis of cost alone, to accept or reject any or all proposals, and to award in its best interest.

Proposals found to be technically or substantially non-responsive at any point in the evaluation process will be rejected and not considered further.

The State may, at its sole option, elect to require presentation(s) by offerors clearly in consideration for award.

If a Vendor is selected for an award, no work is to commence until a Purchase Order is issued.

The State’s General Conditions of Purchase contain the specific contract terms, stipulations and affirmations to be utilized for the contract awarded to the RFP. The State’s General Conditions of Purchases/General Terms and Conditions can be found at the following URL: https://www.purchasing.ri.gov/RIVIP/publicdocuments/ATTA.pdf.