Student Engagement Platform

The Vendor is required to provide for a student engagement platform to enhance the student experience while empowering students, fostering innovation, and streamlining student organization management.
- The solution must integrate with existing systems, offer a user-friendly interface, and provide a wide range of key analytics to monitor and improve student engagement.
- Provide for a comprehensive Student Engagement Platform that supports community building, student organization management, event planning, communication, assessment, and data reporting.
- Implementation and Onboarding
•    Provide project management services, including a detailed implementation plan with milestones, deliverables, and timelines that meet the needs of the University.
•    Facilitate data migration from the current system (Engage), including user accounts, organizations, events, service hours, and historical engagement data. Include testable features including required migration approach, formats, validation, mock conversion, and acceptance criteria to reduce go-live risk and change orders.
•    Configure and customize the platform in alignment with institutional branding, hierarchy, and access controls.
•    Ensure integration with institutional systems, including but not limited to:
o    Single Sign-On (SSO)
o    Student Information System (SIS)
o    Learning Management System (LMS)
o    Institutional data warehouse or reporting tools
•    Conduct testing and user acceptance validation of all functional components, including form creation tools and service hour tracking, prior to launch.
- Implementation, Data Migration, and Go-Live Requirements (IT)
•    Provide a detailed implementation plan including work breakdown, milestones, dependencies, roles/responsibilities, and a week-by-week timeline through production cutover.
•    Provide a data migration plan that includes (at minimum): source-to-target mapping, transformation rules, required extracts from Engage, import templates, and a reconciliation approach.
•    Perform at least one mock migration and one final production migration. Offeror shall provide reconciliation results for each migration demonstrating record counts and field-level validation for agreed critical fields.
•    Data migration acceptance criteria: unless otherwise agreed in writing, the final migration shall achieve at least 99.5% successful migration of in-scope records (users, organizations, events, attendance, service hours, and historical engagement data) with documented exceptions approved by the University.
•    Provide a cutover plan including freeze window, downtime estimate, communication plan, and rollback/contingency plan.
•    Provide a testing plan that includes integration testing and University user acceptance testing (UAT) with defined entry/exit criteria and defect severity definitions.
- Maintenance and Updates
•    Provide regular product updates, feature enhancements, and bug fixes.
•    Maintain compliance with all applicable data privacy, accessibility, and security standards (including FERPA, ADA, and GDPR where applicable).
•    Notify the Institution in advance of any system maintenance, downtime, or major version updates.
•    Provide at least 7 calendar days’ notice for planned maintenance that may impact availability and at least 30 calendar days’ notice for material changes that impact end users, integrations, authentication, or reporting.
•    Maintain and publish release notes for production changes.
•    For any API or integration used by the University, Offeror shall provide a versioning and deprecation policy including at least 12 months’ notice prior to removal of a supported API version or a breaking change.
•    Provide at least 7 calendar days’ notice for planned maintenance that may impact availability and at least 30 calendar days’ notice for material changes that impact end users, integrations, authentication, or reporting.
•    Maintain and publish release notes for production changes.
•    For any API or integration used by the University, Contractor shall provide a versioning and imprecation policy including at least 12 months’ notice prior to removal of a supported API version or a breaking change.