RFP Auction Fundraising Platform - 837233.docx

REQUEST FOR PROPOSAL

PROJECT TITLE: Auction Fundraising Platform Ref # 837233

The University of Washington is soliciting proposals from potential vendors to provide the above referenced services. Vendors interested in providing the required services must submit proposals per the requirements detailed in this RFP.

This solicitation is open to those vendors that satisfy the minimum qualifications stated herein and that are available for work in Washington State.

Contents of this Solicitation

I. General Instructions

II. Requirements

III. Evaluation and Contract Award

VI. Attachments

Section I General Instructions

1.1 PURPOSE

The University of Washington is seeking an auction event registration and management services.

The University of Washington is one of the premier public institutions in the country. The UW currently enrolls approximately 45,000 undergraduate, graduate and professional students, and is the third-largest employer in the region. The UW ranks first nationally among public universities in receipt of federal funding for research and training.

Any contract(s) resulting from this RFP shall be made available to the entire UW Campus (Seattle, Tacoma and Bothell). For the purpose of providing potential auction volume to the proponents of this RFP, UW has identified two departments with an interest and continuing need for a centrally supported auction event software, as follows:

University Advancement Gift Services

The University Advancement Gift Services office processes all private support for the institution. Currently, the processing of in-kind donations and items purchased at virtual, or in-person auctions is handled manually, or via in-house legacy systems.

Office of Merchant Services

The Office of Merchant Services oversees PCI compliance of all UW credit card merchants and the institution. This includes oversight of purchased goods or services at virtual or in-person auctions. Currently, the oversight of goods or services purchased through virtual or live, in-person auctions is overseen at the business unit level by unit departments.

1.2 RFP COORDINATOR

The RFP Coordinator is the sole point of contact in the University for this Procurement. All communication between the Contractor and the University upon release of this RFP shall be with the RFP Coordinator, in writing, as follows:

Silvia Andersen, Contract Manager Procurement Services silvif@uw.edu

1.3 Definition of Terms

“Supplier”, “Proposer”

“Request for Proposal”

-A written solicitation document which identifies the UW’s needs, and consultants are invited to submit proposals which outline their solution to the need, their qualifications and experience to provide the services, and their costs or fees.

1.4 tIMETABLE

1.5 PROPOSAL SUBMISSION

Vendors shall submit a proposal in PDF OR Word format, via the University’s Workday Strategic Sourcing website. Proposals must be submitted on or before the time specified in 1.4 Timetable. Any proposal received after that date and time may not be considered. All proposals shall remain valid for a minimum of 180 days following the RFP closing date.

Workday This solicitation is being conducted in Workday. Vendors can register for the sourcing event by visiting https://university-of-washington.public-portal.us.workdayspend.com/

Search using reference # 837233

Option 1 – Select Bid > Register

Option 2 – Select the title of the RFP and select Start Bid > Register

1.6 INQUIRIES

All questions must be submitted in writing via the Workday Strategic Sourcing website citing the particular RFP section and paragraph number, and utilizing the attached template/Attachment E. Depending upon the nature of the inquiry and the response, copies of the question and response may be distributed to all other potential vendors. The closing date for asking of questions is given in Paragraph 1.4. The University may exercise its option not to reply to Vendor inquiries; therefore, Vendors should be prepared to submit a proposal based on the information included in the RFP.

1.7 COMPLAINTS

A. Contractors may submit a complaint to the RFP Coordinator based on any of the following:

· The solicitation unnecessarily restricts competition;

· The solicitation evaluation or scoring process is unfair or flawed; or

· The solicitation requirements are inadequate or insufficient to prepare a response.

B. Contractors may submit complaints up to 5 business days prior to the proposal due date. Complaints must meet the following requirements:

· Must be in writing.

· Must be sent to the procurement coordinator, or designee.

· Should clearly articulate the basis for the complaint.

· Should include a proposed remedy.

The RFP coordinator or designee will respond to complaints in writing; the response to complaints including any changes to the solicitation will be posted as an amendment on WEBS, https://fortress.wa.gov/ga/webs/ and in Workday. The complaint may not be raised again during the protest period. The complaint process does not include an appeal process.

1.8 Interpretation of the RFP

Should any discrepancies be found in or omissions from the specifications, or doubt as to their meaning, the Contractor shall at once notify the Coordinator, in writing. The Coordinator will send written instructions or addenda as required to all interested parties. All addenda issued shall be incorporated into the contract. The Purchaser shall not be responsible for or bound by oral interpretations. Only questions answered by written addenda are binding. Questions received less than five (5) working days before the proposed due date for submission of proposals cannot be answered.

1.9 REVISIONS TO THE RFP

The University reserves the right to change the acquisition schedule or cancel the RFP at any time. The University reserves the right to make corrections or amendments due to errors identified in the RFP by the University or a Contractor. Any changes will be dated and attached to, and made a part of, the RFP. All changes must be coordinated in writing with, authorized by, and made by the RFP Coordinator.

All RFP corrections and amendments will be posted to https://fortress.wa.gov/ga/webs/ and also to the Workday sourcing module. Contractors are responsible for checking the website for this information.

1.10 Signature

Each proposal must be signed by the Contractor and dated. The name and title shall be typed or printed below each signature.

A. Proposals submitted by a proprietorship must be signed by the Owner.

B. Proposals submitted by a partnership must be signed with the partnership name by one of the partners, followed by the signature and designation of the partner signing.

C. Proposals by a corporation must be signed with the legal name of the corporation, followed by the name of an authorized officer.

1.11 Cost of Proposals

Costs incurred in preparing and presenting the proposals or incurred in any other manner by the Contractor in responding to this solicitation are not reimbursable and may not be charged to the University.

1.12 Withdrawal or Modifications of Proposals

Any Contractor may withdraw their proposal upon written request at any time prior to the scheduled due date for submission of proposals.

1.13 Public Disclosure

The University is subject to RCW 42.56 (Public Records Act). All Contractor Responses and any subsequent Contract will be “public records” as defined in RCW 42.56.010

The Contractor must clearly specify any specific information that it claims is confidential or proprietary. Marking of the entire Response or entire sections as proprietary will not be honored. The University may not accept Responses where pricing is marked as proprietary.

All Responses received will remain confidential until the Contract, if any, resulting from this RFP is signed by the University and the Apparent Successful Contractor; thereafter, the Responses will be deemed public records.

To the extent consistent with RCW 42.56, the University will maintain the confidentiality of all information marked confidential or proprietary. If a request is made to view the Contractor’s information, the University will notify the Contractor of the request and the date that such records will be released unless the Contractor obtains a court order enjoining that disclosure. The Contractor will have five (5) business days from receipt of notice to obtain the court order. If the Contractor fails to obtain the court order enjoining disclosure, the University will release the requested information on the date specified.

1.14 ACCEPTANCE PERIOD

Contractor’s proposal must provide 120 business days for acceptance by University from the due date for receipt of Proposals.

1.15 RESPONSIVENESS

All Proposals will be reviewed by the RFP Coordinator to determine compliance with administrative requirements and instructions specified in this RFP. The Contractor is specifically notified that failure to comply with any part of the RFP may result in rejection of the Proposal as non-responsive.

1.16 Selection of Proposals

In determining the “apparent successful Contractor”, in addition to cost, the Contractor’s compliance with the requirements of this solicitation, and the items listed below, shall be given consideration.

A. The ability, capacity, and skills of the Contractor to perform the contract or provide the service required.

B. The character, integrity, reputation, judgment, experience, and efficiency of the Contractor.

C. The quality of performance of previous contracts or service.

D. The previous and existing compliance by the Contractor with the laws relating to contract and services.

E. Such other information as may be secured having a bearing on the decision to award the contract.

1.17 No Obligation to Contract

This solicitation does not obligate the University of Washington to contract for the solicited services specified herein.

1.18 Contract in Best Interest

The University reserves the right to accept or reject proposals on each item separately or as a whole, to reject any or all proposals without penalty, to waive informalities or irregularities, and to contract in the best interests of the University.

1.19 PUBLICITY

Advertising, including use of the University marks and logos, press releases, or any other general public announcement by a Contractor, stating the availability of its products or services to University employees is strictly prohibited unless the Contractor has obtained prior written authorization from the UW Procurement Services Department.

1.20 NON-ENDORSEMENT

The successful Contractor agrees to make no reference to the University in any literature, promotional material, brochures, sales presentation or the like without express written consent of the University.

1.21 FUNDING

Any contract awarded as a result of this procurement is contingent upon the continued availability of state or federal agency funding.

1.22 Contract and Terms & Conditions

The attached University General Terms and Conditions, Exhibit B, and other riders will automatically be incorporated into any contract award as a result of this solicitation. Any exceptions taken must be noted and alternative language submitted with the Certification and Assurances. In no event, is a Vendor to submit its own standard terms and conditions in response to this solicitation. The University will review requested exceptions and accept or reject the same at its sole discretion.

1.23 Data-Security

If, during the course of the performance, administration, or maintenance of this contract, or any extension or renewal thereof, CONTRACTOR acquires, uses, or otherwise obtains access to ‘University Data’ as those terms are defined in the UW Data Processing Agreement, incorporated herein, then the UW and CONTRACTOR agree that all of the terms and conditions of the UW’s Data Processing Agreement and/or IT Data Security Addendum(s) shall apply.

1.24 IN-STATE RECIPROCITY

The Department of Enterprise Services has established a schedule of states (Schedule) which grant a preference to their own in-state businesses for goods and services. Detailed information regarding the various States’ reciprocity policies is contained in the following URL. Bids submitted by Consultants with addresses in any of the states as described in the Schedules shall be evaluated in accordance with the instructions stated in the Schedule.

https://www.naspo.org/research-and-innovation/state-preference-repository/

1.25 GRATUITIES

In accordance with RCW 42-52-150 and 160, Ethics in Public Service, no gifts, gratuities or any item of economic value may be accepted by University Employees. Contractors agree to offer no such items to any University employee.

1.26 Minority and Women Business Enterprise Participation

In accordance with chapter 39.19 RCW, the University of Washington encourages participation in all of its contracts by firms certified by the Office of Minority and Women’s Business Enterprises (OMWBE). Participation may be either on a direct basis in response to this solicitation or on a we think there might be subcontractors on the RFP basis. However, no preference will be included in the evaluation of proposals, no minimum level of MWBE participation shall be required as a condition for receiving an award and proposals will not be rejected or considered non-responsive on that basis. Any affirmative action requirements set forth in federal regulation or statutes included or referenced in the contract documents will apply.

The established annual procurement participation goals for this solicitation are MBE 6% and WBE 4%. For information on certified firms, Contractors may contact OMWBE at 360/753-9693or http://www.omwbe.wa.gov.”

1.27 U.S. Small Business Participation

Participation in contracts for goods and services is encouraged by firms which qualify under definitions by the U.S. Small Business Administration as small business (SB), or small disadvantaged business (SDB), or small women owned business (WOB).

The percentage listed below is voluntary. No preference will be included in the evaluation of bids/proposals. Participation in University contracts may be either direct as the Contractor in response to this solicitation, or as a subcontractor to a Contractor.

Voluntary U.S. Small Business goals for this solicitation are 15% SB/SDB/WOB

1.28 Subcontractor Participation Monitoring and Reporting

Once a contract is awarded through the solicitation or proposal process, the awarded Service Provider is obligated to complete the vendor registration in Access Equity. Access Equity is a secure online vendor management system (B2GNow). Confidential information (Tax ID, etc.) will not be published. The Awarded Service Provider that have previously registered with B2Gnow for any public entity, must verify the system has updated information.

Service Providers can access the system at https://omwbe.diversitycompliance.com/or through a direct link on the Office of Minority and Women’s Business Enterprises (OMWBE) website at: https://omwbe.wa.gov/.

Each month during the contract, the Service Provider will report payments to all Subcontractors through the Access Equity system. This monthly reporting information includes total payment in dollars made to the Subcontractor, payment dates, and any additional information required to verify payment to Subcontractors. The Service Provider will enter this payment information into the Access Equity system, and the Subcontractors will verify this payment information in the system. Online training is available through the Access Equity/B2Gnow system. This requirement applies to both Service Providers and Subcontractors.

1.29 Federal Small, Small Disadvantaged or Small Woman Owned Business Certification:

In accordance with Public Law 95-507, Federal Contracts that contain Federal Acquisition Regulations (FAR) clause 52.219-8 (Utilization of Small Business Concerns and Small Disadvantaged Business Concerns) impose requirements regarding subcontracting with small businesses and small business subcontracting plans. Refer to FAR 19.001 for guideline definitions.

With regards to certification, the Small Business Administration (SBA) classifies small businesses on an industry-by-industry basis, utilizing a Standard Industrial Classification (SIC) code as described in the Code of Federal Regulations (CFR) Title 13, Part 121.The offeror certifies that the information is true and understands that whoever, for the purpose of securing a contract or subcontract is accountable under Public Law 99-661 and the CFR Title 13, Part 124 & 125.

If a firm misrepresents the status of any concern or person as a small business owned and controlled by a minority or woman owned business, they shall (1) be punished by imposition of a fine, imprisonment, or both; (2) be subject to administrative remedies including suspension and disbarment; and (3) be ineligible for participation in programs conducted under the authority of the Small Business Act.

If you need assistance in determining whether your business is considered to be small, contact the Seattle branch of the U.S. Small Business Administration at (206) 553-7310, or the University’s Representative at (206) 543.4156.

SECTION II

REQUIREMENTS

2.1 Period of Service

The period of performance of any contract resulting from this RFP is for an initial term of one (1) year. It is tentatively scheduled to begin on or about July 1, 2025 and to end on or about June 30, 2026 depending on timing of award after demonstrations of software. This contract may be extended for three (3) additional three (3) year renewals.

The UW retains, at its sole discretion, the right to exercise the renewal option(s). Any contract renewal shall be contingent upon the contractor’s satisfactory performance as solely determined by the UW. All terms and conditions of the original contract shall remain in effect during the contract renewal period(s).

2.2 Proposal Requirements and Instructions

Background and History: Describe the company, organization, officers or partners, number of employees and operating policies which would affect this Contract. State the number of years the organization has been continuously engaged in business.

Financial Stability: Describe the financial status of the company. Attach a copy of the most recent annual financial statement or another similar document.

Technical Approach and Methodology: Describe Bidder’s technical approach and methodology for accomplishing the described Scope of Work. The proposed approach and methodology should include a detailed work plan and schedule. All information to be provided by participating Hospital(s) as part of this plan must be specified including content, format, and frequency.

Project Team and Management Structure: Identify proposed project team and management structure for completing the Scope of Work. This should identify roles and responsibilities, including Bidder expectations of participating UW Medicine Hospital(s) staff resources. Provide resumes of key professional staff to be assigned to the project and their level of commitment to this engagement.

Proposed Fees: Provide a cost proposal to accomplish the Scope of Work or provide the requested product.

Firm Experience and Credentials: Provide evidence of Bidder’s experience in projects or providing products as described within this RFP.

References: List three (3) relevant references, including a description of the engagement, professional fees, duration, and date of completion, contact person, title, mailing address, telephone number and e-mail address.

Contract Management Information: Provide primary Contract Manager Contact name, title, mailing address, telephone number and email address.

2.3 SCOPE OF WORK

Management of auction events at the University of Washington is generally a labor intensive, manual process. In a typical process, a variety of auction platforms are used to collect information for in-kind donations, credit card information to purchase auction items is collected and charged out (or invoices sent), auction attendee data is housed in a separate system, and communications with the successful bidders are handled manually. Upon conclusion of the auction, winning bidder transaction details are manually recorded for gift credit and tax receipting.

The University of Washington intends to select via this RFP process a contractor of choice to provide a web-based auction event management system including these services:

· Provide a customizable interface using University, department, or event branding information to create an event-specific online site

· Allow interested participants to register for the auction event in a self-service environment

· Collect participant information as necessary for the auction event

· Allow for payment for winning bids, per item

· Forward collected fees to the event organizer

· Collect item-specific information for in-kind donations, per auction event

· Collect bidder-specific information, per auction event

· Provide reporting services to the event organizer, such as donated item reports, winning bidder reports or accounting receipt reports

· Send acknowledgements or other event communications to event participants as appropriate.

The objective of this RFP is to automate this previously manual process to the extent practical to allow for greater efficiencies in auction event management and to explore additional service options as they become available during the Term of the agreement.

In addition to the above mentioned services, University may utilize any new service options or technology resources from Contractor during the Term of the resultant agreement as they become available in the future.

2.4 Technical and Performance Requirements

Respondents to this RFP shall provide information to address the technical and service requirements specified in this section. Response to this section shall include 1) Respondent’s acknowledgement of their ability to meet (or inability to meet) the specific requirements, and 2) additional information on how the requirement will be met based on respondent’s existing service capacity and technical resources.

Responses to this section must be standalone to facilitate evaluation and scoring. Reference section and heading before each response.

Note that Sections 2.4A -2.4Hh are marked as “MS” or “mandatory scored.”

Note that Sections 2.4Ii -2.4Mm are marked as “DS” or “desirable scored.”

2.4A

MS

Multiple Departments or Institutions

The system may be used by multiple departments or institutions, each of which will need a unique website, and will have separate accounting practices. As an example, the registrations from UW Educational Outreach and UW Genome Sciences would need to be kept separate, with each department designating an appropriate account for depositing incoming registrations. Describe your methodology for maintaining separate accounts, web presence, or accounting.

2.4B

MS

Auction event staff person sets up registration form using internet connection and browser; simple interface - designed for non-technical user. Describe a typical auction event setup and lifecycle as typically used by your proposed system.

2.4C

MS

Data Structure

Does the PROPOSER’s system include a CRM? What is the linkage between PROPOSER’s tables storing auction item and registrant data and PROPOSER’s CRM?

[Desirable] Recognize that, at least for UW-affiliated auction event donor or guests, the PROPOSER’s system will NOT be serving as the master CRM. There needs to be a way for AGENCY to add our CRM system’s unique identifier to records in the PROPOSER’s shadow CRM, if desired. Also, after a guest has registered for an event, if done anonymously, there needs to be a way for an administrator to link the registrant record with the PROPOSER’s shadow CRM record, if a match can be made. Also, there needs to be a way for an administrator to manually insert the AGENCY’s CRM record identifier into an “anonymous” registration record, if an offline match can be made

2.4D

MS

User Accounts

If the PROPOSER's system allows event registrants to create a user account, describe the security infrastructure that protects the account data (user authentication and authorization services).

Auction event managers, when setting up a new event, should be able to specify whether an event requires registrants to create a user account. If a user account is not required to register for an event, the system should allow "anonymous" registrations - anonymous in the sense that no user account is required. This would not affect any other requirements for data the event may impose on the registrant, such as contact information, billing and payment information, etc.

2.4E

MS

Non-Technical Internet-Based Administration

Auction event staff person sets up donation form(s), registration form(s), pages and workflows using internet connection and browser; simple interface - designed for non-technical user. Describe a typical auction event setup and lifecycle as implemented by your proposed system. Describe a typical auction event setup and lifecycle as implemented by your proposed system.

2.4F

MS

Hosted Solution

On-line donation and attendee registration hosted on vendor secure site.

2.4G

MS

Simple vs. complex events

2.4H

MS

Testing

Managers can test registration forms, pages, workflows, responses and reporting and can shift auction event sites to live status when ready.

2.4I

MS

Post-launch edits

Managers can make edits directly to forms, pages, workflows, responses and reporting whenever necessary, even after auction event has launched.

2.4J

MS

Promotional pricing

Registration system allows auction event managers to define special pricing levels accessible to registrants with valid promotional codes.

2.4K

MS

Conditional Logic

Registration system accommodates conditional logic. For example, administrator can specify registration rules (i.e. if you register for “A,” you must also register for “B;” or - you must register for at least x number of sub-events; or - if you register for “A,” you can’t register for “B”)

2.4L

MS

RSVP lists

Allow attendees to opt into appearing on a public (or private) RSVP list. Allow administrator to specify (separately from event public/private setting) whether RSVP list will be visible to public or only to registrants after they have registered.

2.4M

MS

Attendees vs. Registrant

The system does not assume the site user (registrant) will be attending the auction event. User may register/RSVP on behalf of someone(s) else. In reporting, system differentiates between event attendees and event registrants.

The system streamlines registering multiple persons from the same organization for one auction event, whether this is being done by a system administrator, or by an end-user registrant.

2.4N

MS

Waitlists

If an auction event reaches capacity, a “wait list” can be opened. Administrators can specify whether wait list should be public or internal-only. If public, registrants can see that the event is at capacity but can choose to add themselves and/or guests to the wait list. Administrators can add registrants/guests to public or internal-only wait lists.

2.4O

MS

Real-time updates

Registration data is completed and submitted by user; registration database is updated in real time with the exact data submitted by the user.

2.4P

MS

Abandoned attempts

Details about registration attempts that are not completed are available to the auction event manager. Person may be contacted if appropriate.

2.4Q

MS

Credit-card payments

Credit card payments are authorized in real time. Authorization must be successful for the registration transaction to complete. The transaction will not be completed if the card number is typed incorrectly or if the credit card is declined. Rather, the user will have the option to retype the card number or to use a different card. Properly authorized transactions are automatically batched for capture and settlement on a daily basis. Captured/settled funds are deposited via AGENCY’s merchant accounts on a daily basis, within 24 hours of initial authorization.

It is not acceptable for funds to be retained by PROPOSER for any length of time beyond authorization/capture/settlement cycle.

2.4R

MS

Merchant Accounts / Payment Gateways / Payment Processor System should allow auction events to be configured for payment processing via AGENCY's merchant accounts or serve as merchant of record. Auction event managers, depending on their user role in the system, should be able to select from a list of multiple, pre-configured AGENCY merchant accounts the one that will be used to process all revenue associated with the particular auction event. Please describe the process AGENCY system administrators would use to add, edit or delete allowable merchant accounts from the system.

System must allow AGENCY's merchant accounts to be configured to work with AGENCY payment gateways (Authorize.net, TouchNet, etc.).

System should go through the AGENCY's merchant accounts to be configured to work with AGENCY payment processor (FiServ) or serve as merchant of record.

System should go through a certified Point to Point encrypted terminal for in-person payments.

2.4S

MS

Purchase order/invoice payments

Should the payment option of "purchase order" or "invoice" be allowed by the auction event manager, the online instructions can indicate that registration is not complete until payment is actually received. The user completes and submits their online registration and an invoice (may be considered a "pro forma invoice") is automatically and immediately created by the system. The reply screen and confirmation email both point to an online, printable copy of the invoice with complete instructions for mailing payment.

2.4T

MS

Administrator registrations and payments

An auction event manager (administrator) can register on behalf of phone-in, mail-in, fax-in, walk-up attendees. The administrator can add registrants and guests post-event (i.e. day-of-event walk-ups).

An administrator can pay by credit card, cash, check, or can “comp” registrations. The form of payment is tracked for reporting.

An administrator can apply multiple transactions and multiple methods of payment to one registration balance-due. (This is not public-facing. End-user registrants with balance due must pay in full at time of registration.)

2.4U

MS

E-mail

Marketing to external audiences: System should allow for upload of excel or data file with names and addresses of non-UW-affiliated members or persons to be notified of an auction event. System allows for staff person to customize an email message to be sent to the invitees. The system will broadcast the message and recipients may then elect to respond, register, add to calendar, tell a friend, or opt-out of future communications. System should track communications with invitees.

Integration with UW broadcast e-mail system: For marketing of events or auction events with UW-affiliated audiences (faculty, staff, students, alumni, donors), system should allow URLs for auction event landing pages to be added to broadcast e-mails sent using other systems.

Transactional e-mails:

· Registration confirmation and receipt e-mails can be customized for each event.

· [Desirable] Registrant can request to be reminded by e-mail of event, and optionally can specify timing of reminder e-mail (day-of, 2 days before, etc.)

· Reminder e-mail can be customized similarly to confirmation e-mail.

· Administrator can configure a “regret” e-mail, to be triggered if the registrant RSVPs “no” to an invitation, which includes a link to a “regret” survey.

2.4V

Reports

A variety of standard “real-time” reports should be available for easy download. Standard reports should Include:

· List of donated items: full list of all items in the auction event including item title, item description, item market value, item donor name, item donor contact information, item expiration date or validity restrictions;

· Attendee lists: a full list of registrants including all personal data, payment status, registration category, optional event selections;

· Bidding cards for each attendee

· Silent auction bid cards for each auction item

· Name badge reports: system allows customization of name badge sizes and formats; system allows downloading of data for use in creating of line nametags; administrator can access an individual auction event registration record and generate one-off name badges;

· Transaction report: all auction items including winning bid amount, winning bid number, winning bidder contact information, winning bid transaction details.

Auction event manager should be able to build queries to create and save custom reports.

All reports can be filtered and sorted by date and time, in real time, to allow day-of-event reporting on last minute registrants.

2.4W

MS

Refunds and registration record updates

Auction event managers can specify the refund policy for an auction event. If allowed by the manager, individuals seeking to cancel/change their registration may take advantage of a self-serve process and may log into their own registration record online to make the update or request a refund. If the change results in a new balance due, the registrant can pay by credit card. If the change results in a refund, this can either be then processed automatically or can be put in a queue pending approval by the coordinator.

2.4X

MS

On-site availability

Live system availability on-site at auction event: if questions arise, the staff person can log into the auction system and review the individual's registration or item details.

2.4Y

MS

On-site Walk-Ups

New, day-of-event registrants complete the on-line registration form and securely submit payment through the established gateway. On-site auction staff can see that the registration is submitted and paid in real time. The registrant will have access to their receipt, etc. electronically.

2.4Z

MS

Registration Availability

On-line registration can remain open 24/7 right up to the time that the event begins. Persons can continue to submit late registrations.

2.4Aa

MS

On-site Real Time

On-site registrations are processed in real time allowing for up to the minute registration counts, counts of extra ticket sales (ie banquets) and real-time financial reports often requested by the client.

2.4Bb

MS

System User Roles

Multiple system users can be configured, each with individual authentication credentials (no shared passwords). Roles and permissions can be assigned to users controlling rights to create, edit, delete or manage events.

Auction event managers can create “client” users and can configure permissions to access specific event reports. Clients may access reports via Web browser.

2.4Cc

System availability / Technical support

Proposer must submit a Service Level Agreement (SLA) as part of the RFP response.

During the period of performance, project consultant and technical support must be readily available from the Proposer.

2.4Dd

MS

Custom Meta-Data

Auction event managers can define and assign to each event custom meta-data such as institutional “activity” codes or accounting codes. Event reports can be configured to include the meta-data.

2.4Ee

MS

Custom Questions

Auction event managers can define custom questions to be asked of registrants. Questions can be asked per guest or per event. Event reporting includes answers to custom questions (including by-event questions) parsed out by guest.

2.4Ff

MS

Registration date-stamp

A date-stamp, such as “time_last_modified,” is applied to each registration and can be included in all reports and downloads. Date stamp should include at least year, month, day, hour and minute.

2.4Gg

MS

Fiduciary Security

University requires that any and all funds collected by the Contractor shall be retain and disburse in a secure and efficient manner. Please described the process you propose for this agreement for fund collection, retention and disbursement.

2.4Hh

MS

Data Security

At a minimum, the proposed system must be PCI-DSS (Payment Card Industry Data Security Standards)level 1 compliant.

Proposer to this RFP acknowledge that they have read and understood the requirements as stated in the attached Data Security Agreement (Exhibit B) Please provide adequate detail on how Contractor’s online security infrastructure protects University’s confidential data in accordance with University’s data security standards.

2.4Ii

DS

User Authentication

In addition to any PROPOSER-based user authentication system, explore offering UW-affiliated customers the option of logging on with UW’s SSO credential, the UW NetID, using either PubCookie or Shibboleth systems.

2.4Jj

DS

Payment Method Accepted by the Contractor

In the event that University is directly responsible for the cost of the service provided by the Contractor, please indicate which method of payment will be acceptable.

2.4Kk

DS

Sustainability

Please describe your current organizational policy on sustainability and environmental stewardship in your business practices.

2.4Ll

DS

Diversity

Please describe your current organizational policy on business diversity.

2.4Mm

DS

Additional Functionality

Please provide any descriptive information regarding any additional functionality that may differentiate your product from those offered by your competitors

SECTION III

EVALUATION AND CONTRACT AWARD

1.1 Evaluation of Proposals

The University reserves the right to make Vendor selections based solely on the proposal submitted. Responsive proposals will be evaluated strictly in accordance with the requirements stated in this solicitation and any addenda issued. The evaluation of proposals shall be accomplished by an evaluation team to be designated by the UW, which will determine the ranking of the proposals. The RFP Coordinator may contact the Vendor for clarification of any portion of a Vendor’s proposal.

1.2 Interview / Presentation

At its sole discretion, the University may require Vendors to participate in an interview or provide a presentation to the evaluation committee. If so, the score from the interview and/or the presentation may be combined with the score of the proposal to identify the apparent successful Vendor. The University will contact the Vendor directly to schedule the interview/presentation.

1.3 Evaluation Criteria & Scoring

The following weighting and points will be assigned to the proposal for evaluation purposes:

Qualitative overall system measures include:

User experience 25 points

· Intuitiveness: How intuitive is the user interface? (5 points)

· Responsiveness: How quickly does the system respond to user inputs? (5 points)

· Accessibility: Is the system accessible to users with disabilities? (5 points)

· User Feedback: Satisfaction scores from user testing or surveys. (5 points)

· Support Resources: Availability and quality of support resources like tutorials and help desks. (5 points)

Account Structure 10 points

· Customization: How easily can the account structure be customized to meet specific needs? (3 points)

· Management: How effective is the account management system? (3 points)

· Security: Measures in place to protect account information. (2 points)

· Integration: Ability to integrate with existing account systems. (2 points)

Technical Requirements 50 points

· Compliance: Adherence to technical standards and regulations. (10 points)

· Performance: System performance under various loads and conditions. (10 points)

· Compatibility: Compatibility with existing hardware and software. (10 points)

· Security: Robustness of security measures and protocols. (10 points)

· Maintenance: Ease and efficiency of system maintenance and updates. (5 points)

· Documentation: Quality and comprehensiveness of technical documentation. (5 points)

Data Structure 15 points

· Organization: How well-organized and logical is the data structure? (4 points)

· Scalability: Ability to handle increasing volumes of data. (4 points)

· Integrity: Accuracy and consistency of the data. (4 points)

· Accessibility: Ease of data access for users. (3 points)

Total – 100 points

1.4 Notification to Proposers

Once the final evaluation phase has been completed, the solicitation Coordinator will issue a written announcement to all participants in Workday and WEBS, citing the name(s) of the apparent successful vendors.

3.5 Protest Procedure

The protest process occurs after the bids are submitted and evaluated. This allows bidders to focus on the evaluation process to ensure its integrity and fairness. Protests can raise issues related to the evaluation process as set out in the solicitation or how the process was executed. This allows for evaluation process errors and problems to be corrected before a contract is executed.

The protest process will meet the following requirements:

1) After the announcement of the apparent successful bidder (ASB), bidders will be offered a debriefing upon written request.

2) Bidders will be given 3 business days after the ASB is announced to request a debriefing.

3) Bidders are required to participate in a debriefing as a prerequisite for submitting a protest.

4) Bidders will be given 5 business days after their debriefing to file a written protest.

5) The protest process will allow bidders an opportunity to submit a protest based only on the following:

A matter of bias, discrimination, or conflict of interest on the part of an evaluator;

Errors in computing the scores; or Non-compliance with procedures described in the procurement document or UW protest process.

6) Protests are to be submitted to the UW’s Director of Procurement Services (Director) and the procurement coordinator.

7) The Director will issue a written response within 10 business days from receipt of the protest unless additional time is needed. The protesting bidder shall be notified if additional time is needed.

8) The Director’s protest decision is final. If a protesting bidder does not accept the protest response, the bidder may try to seek relief from superior court.

9) At the time that the protest response is issued, the Director of the Department Enterprise Services will be provided a copy of the original protest and the UW’s response.

Section IV Attachments

1. Attachment A. Data Processing Agreement

4. Attachment D. University of Washington General Terms and Conditions

5. Attachment E. Question Template

6. Attachment F. IT Accessibility Rider

7. Attachment G. IT Security Terms

8. Attachment H. Policy 7.1.3 Federal Terms and Conditions

9. Attachment I. Federal Solicitation Requirements image1.emf

C-to-P-DPA.docx

UNIVERSITY OF WASHINGTON

CONTROLLER TO PROCESSOR

DATA PROCESSING AGREEMENT

Introduction, Parties, AND Effective Date

This Data Processing Agreement (the “DPA”) is hereby incorporated into and amends the [insert name of Underlying Agreement] (the “Agreement”) between the University of Washington, an agency of the State of Washington, with its main campus located in Seattle, Washington (the “University”) and [insert entity name], a [insert name of jurisdiction within which entity was formed (ex. Delaware)] [insert type of entity type (ex. corporation)], with a principal place of business at [insert entity’s address] as of the Effective Date below. With respect to Data Processing performed under the Agreement and this DPA, the University is the Controller and the [insert non-UW entity] is the Processor. The parties agree as follows:

Definitions

1. “Controller” refers to the person or entity that determines the purpose and means for Data Processing.

2. “Data Breach” means any technical or physical incident or set of circumstances that leads to the unauthorized, accidental or unlawful access to, or destruction, loss, alteration, or disclosure of, University Personal Data undergoing Data Processing by the Processor.

3. “Data Processing” means any operation(s) performed on University Personal Data, whether or not by automated means, such as collection, recording, organization, storage, adaptation, alteration, retrieval, consultation, access, use, disclosure by transmission, dissemination, combination, restriction or destruction.

4. "Data Request” means a request to exercise rights available under any applicable law with respect to University Personal Data.

5. “Processor” refers to the person or entity that performs Data Processing on behalf of the Controller.

6. “Sub-processor” means any person or entity appointed by or on behalf of the Processor to carry out any portion of the Work.

7. “University Personal Data” or “UPD” means any records or information relating to an identified or identifiable natural person, such as name, identification number, location data, online identifiers, or factor(s) specific to physical, physiological, genetic, mental, economic, cultural, or social identity or characteristics, or is identified as personally identifiable data (or a similar term) by any applicable law, that:

a. Is created, received, or maintained by the University and transmitted to, accessed by, or otherwise made available to the Processor in connection with the Processor’s performance of the Work;

b. Is created or compiled by the Processor in performing the Work; or

c. Is appended to, aggregated with, or associated with any University Personal Data originating from the University that was transmitted to or accessed by the Processor in connection with the Processor’s performance of the Work.

Notwithstanding the foregoing, UPD does not include personal data relating to the Processor’s or Sub- processor’s personnel or personal data that is acquired from non-UW sources and is processed by the Processor not in association with the Work.

8. “Processor” as used in this DPA includes both the Processor identified above, and any third party and/or entity that owns or controls, is owned or controlled by, or is under common ownership or control with the Processor, where control is defined as the possession, directly or indirectly, of the power to direct or cause the direction of the management and policies of an entity, whether through ownership of voting security, by contract, or otherwise.

9. “Work” refers to any and all activities carried out by the Processor or a Sub-processor in providing services, work product or deliverables under the Agreement, or in fulfilling any other obligations set forth in the Agreement.

standard of care

1. The Processor represents and warrants that any Data Processing shall be by personnel who (a) are obligated to maintain confidentiality under applicable law or job expectations, and (b) are sufficiently trained and experienced to use reasonable care commensurate with state-of-the-art professional practices to comply with the obligations in this DPA.

2. The Processor shall ensure that there are appropriate personnel-vetting processes, and appropriate policies and/or controls over activities as necessary to safeguard UPD per this DPA and applicable law.

3. Prior to the disclosure of UPD to, or the commencement of Data Processing by any Sub-processor, the Processor shall cause each Sub-processor to execute an agreement with the Processor that includes terms and conditions which establish at least the same level of protection for UPD as those set out in this DPA and applicable law. If a Sub-processor fails to fulfill its data protection obligations under this DPA or applicable law, the Processor shall remain fully liable to the University for the performance of that Sub-processor’s obligations.

purpose And LIMITS OF DATA PROCESSING

1. The Description of Data Processing Exhibit to this DPA sets forth certain information relating to the Data Processing by the Processor for the purpose of carrying out the Work. The Processor may only engage in Data Processing for the limited purpose described in the Description of Data Processing Exhibit (the “Purpose”). The Processor shall limit its Data Processing to include only the minimum UPD needed to fulfill the Purpose. The Processor’s Data Processing will not involve any secondary uses of UPD beyond the Purpose. Without limiting the generality of the foregoing, the Processor shall not use any UPD to market or sell goods or services to persons named or otherwise identified in UPD.

2. When the University reasonably deems necessary to meet its own requirements and/or applicable laws, the University may make reasonable changes to the Data Processing by amending the Description of Data Processing Exhibit or providing the Processor with an additional exhibit in the same form as the Description of Data Processing Exhibit. Any material change to the Description of Data Processing Exhibit that increases the cost of the Work shall be subject to the mutual agreement of the parties.

3. The University shall have sole control over determinations related to (a) the lawfulness of the Data Processing, and (b) the necessity of any privacy notice to and/or solicitation of consent from individuals whose personal data will undergo Data Processing in relation to the Work.

Non-Disclosure AND DATA REQUESTS

1. UPD shall not be disclosed by the Processor (or any Sub-processor) to a third party, unless the University grants permission in writing to the Processor to disclose, or unless such disclosure is required by applicable law.

2. If the Processor receives any subpoena, discovery request, court order, or…