RFP Document.pdf

STATE OF SOUTH DAKOTA

DEPARTMENT OF SOCIAL SERVICES

700 GOVERNORS DRIVE

PIERRE, SD 57501

Check-In/Queueing and Client Information System

PROPOSALS ARE DUE NO LATER THAN APRIL 30, 2025 BY 5PM CST

RFP13685 State POC: Kirsten Blachford EMAIL: Kirsten.Blachford@state.sd.us

READ CAREFULLY

FIRM NAME: AUTHORIZED SIGNATURE:

(Digital signature allowed)

ADDRESS: TYPE OR PRINT NAME:

CITY/STATE: TELEPHONE NO:

ZIP (9 DIGIT): FAX NO:

E-MAIL:

PRIMARY CONTACT INFORMATION

CONTACT NAME: TELEPHONE NO:

FAX NO: E-MAIL:

1.0 GENERAL INFORMATION

1.1 PURPOSE OF REQUEST FOR PROPOSAL (RFP)

DSS is seeking a software solution that will aid our visitors in having a smoother, modern experience that reduces wait times, improves service, improves communication, improves availability, and through such measures, reduce stress during an already stressful time in their lives.

The South Dakota Department of Social Services (DSS) assists children, families, individuals, seniors, and people with disabilities through some of the most difficult times in their lives. DSS intends to pilot this software at our new One Stop location (opening in February 2025). This location will DSS services for all constituents of Sioux Falls and the surrounding areas from a single location and is expecting over 150 visitors per day. If successful, DSS will consider expanding the use of the proposed software solution to our presence in over 40 communities across South Dakota.

1.2 ISSUING OFFICE AND RFP REFERENCE NUMBER

The Office of the Secretary is the issuing office for this document and all subsequent addenda relating to it, on behalf of the State of South Dakota, Department of Social Services. The reference number for the transaction is RFP13685. This number must be referred to on all proposals, correspondence, and documentation relating to the RFP.

1.3 LETTER OF INTENT

All interested offerors are requested to submit a non-binding Letter of Intent to respond to this RFP. While preferred, a Letter of Intent is not mandatory to submit a proposal.

Be sure to reference the RFP number in your letter.

The Letter of Intent must be submitted to Kirsten Blachford via email at Kirsten.Blachford@state.sd.us no later than March 18, 2025. Please place the following in the subject line of your email: Letter of Intent for

RFP13685.

1.4 SCHEDULE OF ACTIVITIES (SUBJECT TO CHANGE)

RFP Publication 03/12/2025 Letter of Intent to Respond Due 03/18/2025 Offeror Questions Due Responses to Offeror Questions

04/01/2025 04/15/2025

Request for SFTP folder 04/29/2025 Proposal Submission 04/30/2025 Oral Presentations/discussions (if required) Week of May 12, 2025 Proposal Revisions (if required) TDB Technical Review Week of May 26, 2025 Anticipated Award Decision/Contract Negotiation 06/10/2025

1.5 SUBMITTING YOUR PROPOSAL

All proposals must be completed and received in the Department of Social Services by the date and time indicated in the Schedule of Activities.

Proposals received after the deadline will be late and ineligible for consideration.

Proposals must be submitted as PDFs via Secured File Transfer Protocol (SFTP). Offerors must request an SFTP folder no later than the date indicated in the Schedule of Activities by emailing Kirsten Blachford at Kirsten.Blachford@state.sd.us.

The subject line should read RFP13685 SFTP Request. The email should contain the name and the email of the person who will be responsible for uploading the document(s).

mailto:Kirsten.Blachford@state.sd.us

Please note, offeror will need to work with their own technical support staff to set up an SFTP compatible software on offeror’s end. While the State of South Dakota can answer questions, State of South Dakota is not responsible for the software required.

All proposals may be signed in ink or digitally by an officer of the offeror legally authorized to bind the offeror to the proposal and sealed in the form intended by the respondent. Proposals that are not properly signed may be rejected.

No proposal may be accepted from, or any contract or purchase order awarded to any person, firm or corporation that is in arrears upon any obligations to the State of South Dakota, or that otherwise may be deemed irresponsible or unreliable by the State of South Dakota.

1.6 CERTIFICATION REGARDING DEBARMENT, SUSPENSION, INELIGIBILITY AND VOLUNTARY

EXCLUSION – LOWER TIER COVERED TRANSACTIONS

By signing and submitting this proposal, the offeror certifies that neither it nor its principals is presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from participation, by any Federal department or agency, from transactions involving the use of Federal funds.

Where the offeror is unable to certify to any of the statements in this certification, the bidder shall attach an explanation to their offer.

1.7 NON-DISCRIMINATION STATEMENT

The State of South Dakota requires that all contractors, vendors, and suppliers doing business with any State agency, department, or institution, provide a statement of non-discrimination. By signing and submitting their proposal, the offeror certifies they do not discriminate in their employment practices with regard to race, color, creed, religion, age, sex, ancestry, national origin or disability.

1.8 CERTIFICATION RELATING TO PROHIBITED ENTITY

For contractors, vendors, suppliers, or subcontractors who enter into a contract with the State of South Dakota by submitting a response to this solicitation or agreeing to contract with the State, the bidder or offeror certifies and agrees that the following information is correct:

The bidder or offeror, in preparing its response or offer or in considering proposals submitted from qualified, potential vendors, suppliers, and subcontractors, or in the solicitation, selection, or commercial treatment of any vendor, supplier, or subcontractor, is not an entity, regardless of its principal place of business, that is ultimately owned or controlled, directly or indirectly, by a foreign national, a foreign parent entity, or foreign government from China, Iran, North Korea, Russia, Cuba, or Venezuela, as defined by SDCL 5-18A. It is understood and agreed that, if this certification is false, such false certification will constitute grounds for the State to reject the bid or response submitted by the bidder or offeror on this project and terminate any contract awarded based on the bid or response. The successful bidder or offeror further agrees to provide immediate written notice to the contracting executive branch agency if during the term of the contract it no longer complies with this certification and agrees such noncompliance may be grounds for contract termination.

1.9 RESTRICTION OF BOYCOTT OF ISRAEL

For contractors, vendors, suppliers, or subcontractors with five (5) or more employees who enter into a contract with the State of South Dakota that involves the expenditure of one hundred thousand dollars ($100,000) or more, by submitting a response to this solicitation or agreeing to contract with the State, the bidder or offeror certifies and agrees that the following information is correct:

The bidder or offeror, in preparing its response or offer or in considering proposals submitted from qualified, potential vendors, suppliers, and subcontractors, or in the solicitation, selection, or commercial treatment of any vendor, supplier, or subcontractor, has not refused to transact business activities, has not terminated business activities, and has not taken other similar actions intended to limit its commercial relations, related to the subject matter of the bid or offer, with a person or entity on the basis of Israeli national origin, or residence or incorporation in Israel or its territories, with the specific intent to accomplish a boycott or divestment of Israel in a discriminatory manner. It is understood and agreed that, if this certification is false, such false certification will constitute grounds for the State to reject the bid or response submitted by the bidder or offeror on this project and terminate any contract awarded based on the bid or response. The successful bidder or offeror further agrees to provide immediate written notice to the contracting executive branch agency if during the term of the contract it no longer complies with this certification and agrees such noncompliance may be grounds for contract termination.

1.10 CERTIFICATION OF NO STATE LEGISLATOR INTEREST

Offeror (i) understands neither a state legislator nor a business in which a state legislator has an ownership interest may be directly or indirectly interested in any contract with the State that was authorized by any law passed during the term for which that legislator was elected, or within one year thereafter, and (ii) has read South Dakota Constitution Article 3, Section 12 and has had the opportunity to seek independent legal advice on the applicability of that provision to any Agreement entered into as a result of this RFP. By signing an Agreement pursuant to this RFP, Offeror hereby certifies that the Agreement is not made in violation of the South Dakota Constitution Article 3, Section 12.

1.11 MODIFICATION OR WITHDRAWAL OF PROPOSALS

Proposals may be modified or withdrawn by the offeror prior to the established due date and time.

No oral, telephonic, telegraphic, or facsimile responses or modifications to informal, formal bids, or Request for Proposals will be considered.

1.12 OFFEROR INQUIRIES

Offerors may email inquiries concerning this RFP to obtain clarification of requirements. No inquiries will be accepted after the date and time indicated in the Schedule of Activities. Inquiries must be emailed to Kirsten Blachford at Kirsten.Blachford@state.sd.us with the subject line RFP13685 Inquiries.

The State will to respond to offeror’s inquiries (if required) via e-mail. In addition, all inquiries and the State’s responses will be posted on the state’s e-procurement system and the DSS website at http://dss.sd.gov/keyresources/rfp.aspx. Offerors may not rely on any other statements, either of a written or oral nature, that alter any specification or other term or condition of this RFP. Offerors will be notified in the same manner as indicated above regarding any modifications to this RFP.

1.13 PROPRIETARY INFORMATION

The proposal of the successful offeror(s) becomes public information. Proprietary information can be protected under limited circumstances such as client lists and non-public financial statements. An entire proposal may not be marked as proprietary. Offerors must clearly identify in the Executive Summary and mark in the body of the proposal any specific proprietary information they are requesting to be protected.

The Executive Summary must contain specific justification explaining why the information is to be protected. Proposals may be reviewed and evaluated by any person at the discretion of the State. All materials submitted become the property of the State of South Dakota and may be returned only at the State's option.

1.14 LENGTH OF CONTRACT

The contract resulting from this RFP will be issued for the period of approximately one (1) year ending May 31, 2026, with the option for renewal for up to three (3), one (1) year contracts at the discretion of the State based on performance and/or the continued availability of funds. Contracts will be negotiated on an annual basis.

1.15 GOVERNING LAW

Venue for any and all legal action regarding or arising out of the transaction covered herein shall be solely in the State of South Dakota. The laws of South Dakota shall govern this transaction.

1.16 DISCUSSIONS WITH OFFERORS (ORAL PRESENTATION/NEGOTIATIONS)

An oral presentation by an offeror to clarify a proposal may be required at the sole discretion of the State.

However, the State may award a contract based on the initial proposals received without discussion with http://dss.sd.gov/keyresources/rfp.aspx the Offeror. If oral presentations are required, they will be scheduled after the submission of proposals.

Oral presentations will be made at the offeror’s expense.

This process is a Request for Proposal/Competitive Negotiation process. Each Proposal shall be evaluated, and each respondent shall be available for negotiation meetings at the State’s request. The State reserves the right to negotiate on any and/or all components of every proposal submitted. From the time the proposals are submitted until the formal award of a contract, each proposal is considered a working document and as such, will be kept confidential. The negotiation discussions will also be held as confidential until such time as the award is completed.

2.0 STANDARD CONTRACT TERMS AND CONDITIONS

Any contract or agreement resulting from this RFP will include the State’s standard terms and conditions as listed below and as seen in Attachment A, the State’s standard Information Technology (“IT”) contract terms listed in Attachment B, along with any additional terms and conditions that may be necessary to the performance of the scope of work. The offeror must indicate in its response any issues it has with specific IT contract terms. If the offeror does not indicate that there is an issue with a specific IT contract term, then the offeror will be deemed to have accepted the IT contract terms as written.

2.1 The Contractor will perform those services described in the Scope of Work, attached hereto as Section

3.0 of the RFP and by this reference incorporated herein.

2.2 The Contractor’s services under this Agreement shall commence on and end on , unless sooner terminated pursuant to the terms hereof.

2.3 The Contractor will use State equipment, supplies or facilities. YES ( ) NO ( X )

2.4 The Contractor will provide the State with its Employer Identification Number, Federal Tax Identification

Number or Social Security Number upon execution of this Agreement.

2.5 The State will make payment for services upon satisfactory completion of the services. The TOTAL CONTRACT AMOUNT is an amount not to exceed $ . The State will not pay Contractor's expenses as a separate item. Payment will be made pursuant to itemized invoices submitted with a signed state voucher.

Payment will be made consistent with SDCL ch. 5-26.

2.6 The Contractor agrees to indemnify and hold the State of South Dakota, its officers, agents and employees, harmless from and against any and all actions, suits, damages, liability or other proceedings that may arise as the result of performing services hereunder. This section does not require the Contractor to be responsible for or defend against claims or damages arising solely from errors or omissions of the State, its officers, agents or employees.

2.7 The Contractor, at all times during the term of this Agreement, shall obtain and maintain in force insurance coverage of the types and with the limits as follows:

A. Commercial General Liability Insurance:

The Contractor shall maintain occurrence based commercial general liability insurance or equivalent form with a limit of not less than $1,000,000.00 for each occurrence. If such insurance contains a general aggregate limit it shall apply separately to this Agreement or be no less than two times the occurrence limit.

B. Professional Liability Insurance or Miscellaneous Professional Liability Insurance:

The Contractor agrees to procure and maintain professional liability insurance or miscellaneous professional liability insurance with a limit not less than $1,000,000.00.

C. Business Automobile Liability Insurance:

The Contractor shall maintain business automobile liability insurance or equivalent form with a limit of not less than $1,000,000.00 for each accident. Such insurance shall include coverage for owned, hired and non-owned vehicles.

D. Worker’s Compensation Insurance:

The Contractor shall procure and maintain workers’ compensation and employers’ liability insurance as required by South Dakota law.

Before beginning work under this Agreement, Contractor shall furnish the State with properly executed Certificates of Insurance which shall clearly evidence all insurance required in this Agreement. In the event a substantial change in insurance, issuance of a new policy, cancellation or nonrenewal of the policy, the Contractor agrees to provide immediate notice to the State and provide a new certificate of insurance showing continuous coverage in the amounts required.

Contractor shall furnish copies of insurance policies if requested by the State.

2.8 While performing services hereunder, the Contractor is an independent contractor and not an officer, agent, or employee of the State of South Dakota.

2.9 Contractor agrees to report to the State any event encountered in the course of performance of this Agreement which results in injury to the person or property of third parties, or which may otherwise subject Contractor or the State to liability. Contractor shall report any such event to the State immediately upon discovery.

Contractor's obligation under this section shall only be to report the occurrence of any event to the State and to make any other report provided for by their duties or applicable law. Contractor's obligation to report shall not require disclosure of any information subject to privilege or confidentiality under law (e.g., attorney-client communications). Reporting to the State under this section shall not excuse or satisfy any obligation of Contractor to report any event to law enforcement or other entities under the requirements of any applicable law.

2.10 This Agreement may be terminated by either party hereto upon thirty (30) days written notice. In the event the Contractor breaches any of the terms or conditions hereof, this Agreement may be terminated by the State at any time with or without notice. If termination for such a default is effected by the State, any payments due to Contractor at the time of termination may be adjusted to cover any additional costs to the State because of Contractor's default. Upon termination the State may take over the work and may award another party an agreement to complete the work under this Agreement. If after the State terminates for a default by Contractor it is determined that Contractor was not at fault, then the Contractor shall be paid for eligible services rendered and expenses incurred up to the date of termination.

2.11 This Agreement depends upon the continued availability of appropriated funds and expenditure authority from the Legislature for this purpose. If for any reason the Legislature fails to appropriate funds or grant expenditure authority, or funds become unavailable by operation of law or federal funds reductions, this Agreement will be terminated by the State. Termination for any of these reasons is not a default by the State nor does it give rise to a claim against the State.

2.12 This Agreement may not be assigned without the express prior written consent of the State. This Agreement may not be amended except in writing, which writing shall be expressly identified as a part hereof, and be signed by an authorized representative of each of the parties hereto.

2.13 This Agreement shall be governed by and construed in accordance with the laws of the State of South

Dakota. Any lawsuit pertaining to or affecting this Agreement shall be venued in Circuit Court, Sixth Judicial Circuit, Hughes County, South Dakota.

2.14 The Contractor will comply with all federal, state and local laws, regulations, ordinances, guidelines, permits and requirements applicable to providing services pursuant to this Agreement, and will be solely responsible for obtaining current information on such requirements.

2.15 The Contractor may not use subcontractors to perform the services described herein without the express prior written consent of the State. The Contractor will include provisions in its subcontracts requiring its subcontractors to comply with the applicable provisions of this Agreement, to indemnify the State, and to provide insurance coverage for the benefit of the State in a manner consistent with this Agreement. The Contractor will cause its subcontractors, agents, and employees to comply, with applicable federal, state and local laws, regulations, ordinances, guidelines, permits and requirements and will adopt such review and inspection procedures as are necessary to assure such compliance.

2.16 Contractor hereby acknowledges and agrees that all reports, plans, specifications, technical data, miscellaneous drawings, software system programs and documentation, procedures, or files, operating instructions and procedures, source code(s) and documentation, including those necessary to upgrade and maintain the software program, and all information contained therein provided to the State by the Contractor in connection with its performance of services under this Agreement shall belong to and is the property of the State and will not be used in any way by the Contractor without the written consent of the State. Papers, reports, forms, software programs, source code(s) and other material which are a part of the work under this Agreement will not be copyrighted without written approval of the State.

2.17 The Contractor certifies that neither Contractor nor its principals are presently debarred, suspended, proposed for debarment or suspension, or declared ineligible from participating in transactions by the federal government or any state or local government department or agency. Contractor further agrees that it will immediately notify the State if during the term of this Agreement Contractor or its principals become subject to debarment, suspension or ineligibility from participating in transactions by the federal government, or by any state or local government department or agency.

2.18 Any notice or other communication required under this Agreement shall be in writing and sent to the address set forth above. Notices shall be given by and to on behalf of the State, and by , on behalf of the Contractor, or such authorized designees as either party may from time to time designate in writing. Notices or communications to or between the parties shall be deemed to have been delivered when mailed by first class mail, provided that notice of default or termination shall be sent by registered or certified mail, or, if personally delivered, when received by such party.

2.19 In the event that any court of competent jurisdiction shall hold any provision of this Agreement unenforceable or invalid, such holding shall not invalidate or render unenforceable any other provision hereof.

2.20 All other prior discussions, communications and representations concerning the subject matter of this

Agreement are superseded by the terms of this Agreement, and except as specifically provided herein, this Agreement constitutes the entire agreement with respect to the subject matter hereof.

3.0 SCOPE OF WORK

The Division of Social Services is publishing this RFP to obtain a secure software solution that will aid various divisions of DSS in improving the customer experience for walk-in and appointment in-person constituents visiting DSS facilities.

The following sections describe the expectations for an offeror’s response and the work which needs to be conducted.

3.1 General Overview

3.1.1 A summary overview of your understanding of what needs to be done and your methodology for project management and expected timeline to implement the software. Include specialized expertise, capabilities, and technical competencies that will be leveraged during implementation and after.

3.1.2 Narrative describing similar implementations, including references for DSS to contact regarding said implementations, including price and cost data, quality of work, ability to meet schedules, cost control, contract administration, traffic volume, number of agents, and any special project constraints.

3.2 Security

3.2.1 Security standards met by the proposed software, including any relevant certificates of compliance, most recent and next testing/compliance review dates, and/or links. Required standards: SOC2 and HIPAA.

3.2.2 Single-sign-on, detailed in Section 3.9, must be supported.

3.2.3 Narrative on how the proposed software stores, encrypts, and protects data gathered.

3.3 Functional Requirements

The proposed software solution is desired to have the following functions. Describe how the proposed software solution meets these specific requirements and include graphics/screenshots as needed.

3.3.1 The proposed software solution must support: multiple locations (services/staff/groups specific to specific locations), multiple groups/sub-groups of staff (at least three levels) with separate services, and staff assigned to multiple services.

3.3.2 Customer Interface/Notifications

3.3.2.1 Walk-in customers should be able to register for queueing- and appointment customers should be able to check-in for appointments – for all DSS services configured in the software via a customizable interface available on a tablet or PC in the lobby of a location.

3.3.2.1.1 Registration should be complete with the minimum of a name field, entered prior to selecting services for a specific appointment. Registration is only for the specific appointment and should not require setting a password or additional gathering of information unless the specific service requires it.

3.3.2.1.2 The customer should be able to register for a single or multiple services during a single check-in/registration session.

3.3.2.1.3 Notifications via SMS should be delivered to the customer to confirm registration/check-in if the customer has entered an optional mobile phone number. The mobile phone number MUST be an optional field.

3.3.2.2 The check-in interface should be customizable to include DSS branding, DSS internal personnel/service groupings and sub-groupings to at least three sub-levels.

3.3.2.3 The check-in interface should have customizable fields (enumerate in detail how many/other information pertinent to customizable fields for the proposed software solution).

3.3.2.4 The check-in/registration interface should have the ability to capture a picture of the customer.

3.3.2.5 The check-in/registration interface should have the ability to scan a standard government ID and use the information to complete the pertinent fields. The scan of the ID should not be stored in the system.

3.3.2.6 The check-in interface should display a customizable message per service after check-in with instructions.

3.3.2.7 If a customer does not wish to use the tablet/pc for check-in (or if DSS has not deployed such a device) the receptionist should be able to use the proposed software solution to register the customer as a walk-in or check-in the customer for an appointment.

3.3.2.8 After check-in/registration, the customer’s entry should be queued for the requested service(s).

3.3.2.8.1 There should be a queue for each walk-in service. If a customer is registered for multiple services, they should appear in only one queue. DSS should be able to define priorities for which queue takes precedence when a customer register for multiple walk-in services.

3.3.2.8.2 The queue should be able to be displayed on digital signage with limited customer information (first/last initial and service and expected wait time) and updated in real time as the queue is worked by DSS staff.

3.3.2.8.3 When a DSS staff member uses the proposed software solution to select a queued customer entry, the customer should receive a SMS message (customized per service) and digital signage should be able to display a message.

3.3.2.9 After service is complete, the proposed software solution should send a customizable SMS to the customer. Ideally this can include a link to a customer-satisfaction survey included as part of the proposed software solution.

3.3.3 Receptionist Capabilities

3.3.3.1 The receptionist should have a view of all waiting customers across all queues/services, including time since registration.

3.3.3.1.1 If a customer has been waiting beyond a configurable amount of time per service, some sort of indication/notification should be provided to the receptionist and any supervisory staff for the queue/service.

3.3.3.2 If a customer arrives for an appointment that is not scheduled via the proposed software solution, the receptionist should have a procedure to receive notification and use the proposed software solution to assign the customer to the appropriate DSS staff member, if the staff member is available.

3.3.3.2.1 The receptionist should be able to see if the DSS staff member is available.

The DSS staff member should then receive notification.

3.3.3.3 The receptionist should be able to change the queue/service, add additional information (notes, flags or other indicators), of a customer’s registration/entry manually as needed.

3.3.3.4 Receptionists should be able to see appointments made for groups or individuals using the proposed software solution.

3.3.3.5 Receptionists should be able to see previous visits/appointments and the notes related if allowed by permissions to those groups/services.

3.3.3.6 Ability to print badges as designated in item 3.3.5.2 of this scope of work from the receptionist desk.

3.3.4 Agent Capabilities

3.3.4.1 Notifications for walk-in customers and appointment customers should be delivered to the appropriate staff group/staff member when the customer registers/checks-in at a DSS facility.

3.3.4.2 Agents should be able to only see the queues to which they are assigned.

3.3.4.3 Agents must be able to receive notifications only when they are available for service.

Logging in/out of the software/mobile app for notification does suffice for this.

3.3.4.4 Agents must receive notifications on mobile devices and desktop (optionally via email).

Browser notifications will suffice for desktops. SMS or app notifications will suffice for mobile devices.

3.3.4.5 Mobile device notifications must occur when the device is locked.

3.3.4.6 Mobile device notifications must occur without having a specific website/app open and “active” on screen.

3.3.4.7 Agents should be able to select a “room/window” in which to serve a customer prior to calling the customer to service.

3.3.4.8 Agents should be able to indicate/record if a customer does not respond to a call to service.

3.3.4.9 Agents should be able to make notes, add custom tags/flags/indicators to a customer’s entry during service.

3.3.4.10 Agents should be able to record the outcome of the service, preferably with a custom defined set of statuses that are available in reporting. Example: Customer did not respond, Service complete successfully, Customer was delayed in arrival, Customer needed a different service).

3.3.4.11 Agents should be able to route the customer’s entry to another queue/service after completing. When routed in such a manner, the customer’s wait time during this visit should be considered and queued accordingly for the newly assigned queue/service.

3.3.4.12 Agents should be able to put a service on hold and call another customer. Example: A customer needed their ID but left it in the car. The agent puts the customer’s service in some form of “on hold” and calls another customer. Once complete, the agent can then “resume” the previous customer’s service and call them back for service again. Recording time to completion of service should accurately reflect the pause of service in such a situation.

3.3.4.13 Agents should be able to see previous visits/appointments and the notes related if allowed by permissions to those groups/services.

3.3.5 General Functions

3.3.5.1 The proposed software solution should support multiple languages on all interfaces and notifications.

3.3.5.2 SMS sending/receiving must be handled by the proposed software solution and not require DSS to acquire a third-party solution that is billed separately from this RFP.

3.3.5.3 Availability to print visitor “badges” in some form (i.e. sticker, etc.) either at the kiosk or at the receptionist desk. This must be customizable and configurable per service and have customizable badges per service. The badge should have some unique identifier on each badge printed.

3.4 Reporting Requirements

The proposed software solution must have robust data collection and reporting. Give examples of pertinent reports and include graphics/screenshots as needed. At minimum, DSS is requiring the following reports:

3.4.1 Average time to completion for a service, available by location, group, agent, day of week, month of year, hours/days.

3.4.2 Average wait time for a service, available by location, group, agent, day of week, month of year, hours/days.

3.4.3 Ideally, the proposed software solution can include customer-satisfaction survey results, available by location, group, agent, day of week, month of year, hours/days.

3.4.4 Availability of a report that details time-in/time-out of all badged visitors for a specific service or set of services that can output in a printable format as well as Excel/CSV for a specified timeframe.

3.5 Appointment Requirements

The proposed software solution should have the capability to allow customers to schedule appointments via an online app.

3.5.1 Appointments should synchronize and use availability from agent’s Microsoft 365 Outlook calendar.

3.5.2 If the proposed software solution requires an account be created in the online app (mobile or-web-based), the login must be integrated with mySD, the State’s citizen portal for single-sign on.

3.5.3 Appointments should be able to be scheduled only for a configurable time into the future (example: 1 week).

3.5.4 Appointments should be able to be scheduled with a group or an individual, based on the service configuration by DSS.

3.5.5 Availability of appointments should be customizable by group(s) and service(s) combination.

3.5.6 Availability to have appointments involve more than one agent/staff member, either manually on the employee interface or available as a configuration per service for the customer facing interface.

3.5.7 Availability to have appointments with multiple customers, either manually on the employee interface or available as a configuration per service for the customer facing interface.

3.5.8 Availability of appointments with individual DSS staff members should be configurable to only be available in the proposed software solution for specific days/times and also take into account the pre-existing entries at time of reservation in a staff members Outlook365 calendar and ensure that customers cannot book individual appointments during such blocked-out days/times or during pre-existing appointments.

3.5.9 Appointments made for an individual should be included in the proposed software solution’s calendar view.

3.5.10 Agents with an appointment scheduled with them individually via the proposed software solution should receive notifications via email, browser notification, or app notification of the approaching appointment at configurable intervals and also when the customer arrives and checks-in for the appointment.

3.5.11 Receptionists should be able to make appointments (with the same restrictions as customers making appointments) on behalf of a customer.

3.6 Training

Provide a narrative containing information on your training staff and their credentials, the methods of training you have used in the past, and the proposed plan methodology and timeline for training for this implementation. The requirements below must be included.

3.6.1 Provide Training Materials: Training Materials in the form of videos, topic specific articles, and other forms must be provided at minimum a month prior to Go Live. These materials must include some type of framework for DSS staff that have not been exposed to the proposed software solution to be able to self-train (i.e. a course/model). Examples: your training courses/models come in SCORM (or other industry standard) format that can imported into many Learning Management Systems; your training courses/models are available online for DSS staff and the main course syllabus or outline can be customized for DSS specific needs and systems.

3.6.2 Train the trainer: Provide live training sessions for DSS staff that will become the trainers for the proposed software solution. Sessions must be recorded and ideally integrated with AI to make finding answers to specific questions easier and faster.

3.6.3 Administrative Training: Provide live training sessions for DSS/other South Dakota state employees that will become the administrators for the proposed software solution. Sessions must be recorded and ideally integrated with AI to make finding answers to specific questions easier and faster.

3.7 Other Features

The proposed software solution may have other features DSS may find useful. Describe each feature and its proposed use.

3.8 Hosting and Data Access Requirements

The contract doubles as an agreement for the State to own the data tables and is able to manipulate data, run reports as needed, pull code tables, access raw data, and develop dashboards as needed through Microsoft Power BI, ESRI, Tableau and associated platforms.

3.9 Single Sign-On Requirements

As part of the State’s Identity and Access Management (IAM) strategy, the proposed solution will need to integrate with the State of South Dakota’s standard identity management service single sign-on (SSO) which enables custom control of how citizens and state employees sign up, sign in, and manage their profiles.

The SSO supports the industry standard OAuth 2.0 protocol. This identity management will handle password recovery and multi-factor authentication (MFA). MFA is required for all application Administrators and may be required for other users. Microsoft’s official documentation on the identity provider the State has implemented can be found at: 1) https://docs.microsoft.com/en-us/azure/active-directory-b2c/ and https://docs.microsoft.com/en-us/azure/active-directory-b2c/integrate-with-app-code-samples for public/citizens (Azure B2C), 2) https://learn.microsoft.com/en-us/azure/active-https://docs.microsoft.com/en-us/azure/active-directory-b2c/ https://docs.microsoft.com/en-us/azure/active-directory-b2c/ https://docs.microsoft.com/en-us/azure/active-directory-b2c/integrate-with-app-code-samples https://docs.microsoft.com/en-us/azure/active-directory-b2c/integrate-with-app-code-samples https://learn.microsoft.com/en-us/azure/active-directory/architecture/auth-oauth2 directory/architecture/auth-oauth2 and https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc for state employees, businesses, partners, providers, etc. (EntraID, formally Azure Active Directory).

If the offeror is not able to fulfill this identity management standard, they will be excluded from the list.

3.10 Onboarding/Provisioning Users

The offeror must describe how new users are onboarded/provisioned in the system using an external identity provider and provide an Identity/SSO/Login Design Document. The offeror must provide an automated process for onboarding and offboarding users or must provide a process that requires minimal manual steps.

3.11 Interfaces and Integration

The offeror must describe how the system can adapt to business necessary interfaces using widely adopted open APIs and standards. Additionally, DSS expects that the offeror will make available/expose software services and publish documentation for those software services that would enable third party developers to interface other business applications. A detailed description of system capability must be included in the proposal.

3.12 Project Deliverables/Approach/Methodology

3.12.1 If the State will be hosting the solution the offeror will provide a system diagram. The diagram must be detailed enough that the State can understand the components, the system flow, and system requirements. It is preferred that the diagram be provided as a separate document or attachment. The file must be named “(Your Name) System Diagram and Requirements”. If the offeror elects to make the diagram part of the proposal, then the location of the diagram must be clearly indicated in the Table of Contents.

3.12.2 If the offeror is hosting the solution, provide a diagram giving an overview of the proposed system. It is preferred that this diagram be provided as a separate document or attachment. The file must be named “(Your Name) Hosted System Diagram”. If the offeror elects to make the diagram part of the proposal, then the location of the diagram must be clearly indicated in the Table of Contents.

3.12.3 The offeror should state whether its proposed solution will operate in a virtualized environment.

The offeror also should identify and describe all differences, restrictions or limitations of its proposed solution with respect to operation, licensing, support, certification, warranties, and any other details that may impact its proposed solution when hosted in a virtualized environment. This information must be included with the solution diagram for the offeror hosted solution.

3.12.4 This section identifies tasks and deliverables of the project as described in this Section 3. The selected offeror is responsible for providing the required deliverables. These deliverables will be the basis against which the offeror’s performance will be evaluated.

3.12.5 The offeror may be required to include a test system for its application. This test system will be used at the discretion of BIT. All resource costs associated with keeping the test system available must be borne by the project owner or the offeror. Any licensing costs for the test system must be included with the costs.

3.12.6 3.62.6 At BIT’s discretion, any code changes made by the offeror, either during this project or thereafter, will be placed in the above test system first. It is at BIT’s discretion if the code changes are applied by BIT or the offeror. If the code testing delays a project’s timeline, a change management process should be followed, and the State will not be charged for this project change. If the test and production systems are to be hosted by the State, the schedule for the testing of the code changes is to be decided by BIT. Testing of emergency code changes will be https://learn.microsoft.com/en-us/azure/active-directory/architecture/auth-oauth2 https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc scheduled by BIT based on the severity and resource availability.

3.12.7 The test system, if required, will be maintained by the offeror as a mirror image of the production system code base. At BIT’s discretion, updates to the production system will be made by copying code from the test system after the test system passes BIT certification requirements.

3.12.8 If BIT determines that the application must be shut down on the production system, for any reason, the offeror will, unless approved otherwise by BIT, diagnosis the problem on and make all fixes on the test system. The offeror is expected to provide proof, to BIT, of the actions taken to remediate the problem that led to the application being denied access to the production system before the application can go back into production. This proof can be required by BIT even if the fix passes all BIT certification criteria. BIT is willing to sign a non-disclosure agreement with the offeror if the offeror feels that revealing the fix will put the offeror’s intellectual property at risk.

3.12.9 All solutions acquired by the State that are hosted by the offeror, including Software as a Service, or hosted by a third-party for the offeror will be subjected to security scans by BIT or preapproved detailed security scan report provided by the offeror. The scan report sent in with the proposal can be redacted by the offeror. The State’s goal at this point is to see if the contents of the report will be acceptable, not to review the contents themselves. If the offeror will be providing a security scan report, one must be sent with the proposal for approval. Approval is not guaranteed. If the scan report is not acceptable, the State must scan the offeror’s solution. The actual scanning by the State or the submission of a security scan report will be done if the proposal is considered for further review. A detailed security report must consist of at least:

• The system that was evaluated (URL if possible, but mask it if needed).

• The categories that were evaluated (example: SQL injection, cross site scripting, etc.)

• What were the general findings, (meaning how many SQL injection issues were found, what was the count per category)

• Technical detail of each issue found. (where was it found – web address, what was found, the http response if possible)

The cost of any scans done by the offeror or the offeror’s costs associated with the State’s scans must be part of the offeror’s bid. If the offeror is sending a security scan report, it should price the product both as if the State was to do the security scan or if the offeror was to do the security scan.

3.12.10 All hardware, website(s), or software purchased by the State and hosted by the State will be subjected to security scans by BIT.

3.12.11 Security scanning will be performed during the software development phase and during pre-production review. These scans and tests can be time consuming and should be allowed for in project planning documents and schedules. Products that do not meet BIT’s security and performance requirements will not be allowed to go into production and may be barred from UAT until all issues are addressed to the State’s satisfaction. The State urges the use of industry scanning/testing tools and secure development methods be employed to avoid unexpected costs and project delays. Costs to produce and deliver secure and reliable applications are the responsibility of the software entity producing or delivering an application to the State. Unless expressly indicated in writing, the State assumes all price estimates and bids are for the delivery and support of applications and systems that will pass security and performance testing. If the State determines the hardware, website(s), software, and or cloud services have security vulnerabilities that must be corrected, the State will inform the offeror of the nature of the issue and the offeror will be required to respond in writing regarding mitigation plans for the security vulnerabilities. If the product(s) does not pass the initial security scan, additional security scans may be required to reach an acceptable level of security. The offeror must pass a final follow-up security scan for the website(s), software or cloud services for the product(s) to be acceptable products to the State. The State may suspend or cancel payments for hardware, website(s), software, or cloud services that do not pass a final security scan.

3.12.12 Any website or web application hosted by the offeror that generates email cannot use

“@state.sd.us” as the originating domain name per state security policy.

3.12.13 As part of the project plan, the offeror will include development of an implementation plan that includes a back out component. Approval of the implementation plan by BIT should be a project milestone. Should the implementation encounter problems that cannot be resolved and the implementation cannot proceed to a successful conclusion, the back out plan will be implemented. The Implementation and back out documentation will be included in the project documentation.

3.12.14 The successful offeror may be required to use the approved BIT processes and procedures when planning its project, including BIT’s change management process. Work with the respective agency’s BIT Point of Contact on this form. The Change Management form is viewable only to BIT employees. The purpose of this form is to alert key stake holders (such as: Operations, Systems Support staff, Desktop Support staff, administrators, Help Desk personnel, client representatives, and others) of changes that will be occurring within state resources and systems to schedule the:

• Movement of individual source code from test to production for production systems

• Implementation of a new system

• A major enhancement to a current system or infrastructure changes that impact clients

• Upgrades to existing development platforms

3.12.15 If as part of the project the state will be acquiring software the proposal should clearly state if the software license is perpetual or a lease. If both are options, the proposal should clearly say so and state the costs of both items separately.

3.12.16 Include in your submission details on your:

• Data loss prevention methodology;

• Identity and access management;

• Security intelligence;

• Annual security training and awareness;

• Manual procedures and controls for security;

• Perimeter controls;

• Security certifications and audits.

3.12.17 If the offeror will have State data on its system(s) or on a third-party’s system and the data cannot be sanitized at the end of the project, the offeror’s proposal must indicate this and give the reason why the data cannot be sanitized as per the methods in NIST 800-88.

3.12.18 The offeror’s solution cannot include any hardware or hardware components manufactured by

Huawei Technologies Company, Nuctech, or ZTE Corporation or any subsidiary or affiliate of such entities. This includes hardware going on the State’s network as well as the offeror’s network if the offeror’s network is accessing the State’s network or accessing State data. This includes Infrastructure as a Service, Platform as a Service or Software as a Service situations.

Any company that is considered to be a security risk by the government of the United States under the International Emergency Economic Powers Act, in a United States appropriation bill, an Executive Order, or listed on the US Department of Commerce’s Entity List will be included in this ban.

3.12.19 If the offeror’s solution requires accounts allowing access to State systems, then the offeror must indicate the number of the offeror’s staff or subcontractors that will require access, the level of access needed,…