Response to Offeror Questions document.docx
DOCX document 41 KB Posted
- Attached to
- Slate CRM Software Implementation
- Solicitation number
- 24RFP-USD08052024
- Issued by
- Clay County, South Dakota
About this file
This document is a Response to Offeror Questions for the Slate CRM Software Implementation RFP issued by the University of South Dakota (USD). The RFP seeks a consultant to implement a Slate customer relationship management (CRM) solution to support the university's undergraduate, graduate, law, and medical school recruitment and admissions processes. Key details include:
The consultant is expected to provide recommendations on whether to use a single Slate instance or two separate instances (one for undergraduate and one for graduate programs). The university is seeking to have the Slate implementation completed by May 1, 2025, including the migration of 2-4 years of application and prospect data from the current Salesforce system. The RFP outlines various application types, data integrations, security requirements, reporting needs, and marketing/communications functionality to be included in the Slate implementation. The university is open to a phased approach if certain elements cannot be completed by the May 2025 deadline. While the university will manage the third-party integrations, they are seeking guidance from the consultant on best practices. The university plans to have a dedicated implementation team and expects approximately 150 Slate users.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Additional Response to Offeror Questions document.docx | DOCX document | |
| RFP Document.pdf | ||
| Addendum 1-RFP Document.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Questions and Answers for Slate CRM Software Implementation RFP
RFP # USD08052024
1. Q: Regarding Recruitment Entities: Are the expectations to stand up a singular instance that houses student-facing and operational processes for all of the following audiences: Undergraduate (including pre-professional applications), Graduate (including health science programs), Law School, Med school?
A: Two instances: One for undergraduate, one for graduate We are seeking a consultant’s recommendation. We are looking to understand better the pros and cons of a single instance vs two separate instances.
2. Q: Regarding Timeline: Is the expectation to have all facets of all the implementation complete by May 1, 2025? Please consider that Common App data will not come into the system until mid August.
A: We are looking to have all of this completed by the May 1, 2025 deadline.
3. Q: Regarding Ongoing Support: What level of support do you anticipate the team requiring? Is there a minimum number of hours per month you are seeking (over 5 years)?
A: A consultant’s recommendation of the number of hours and cost per hour will be considered.
4. Q: Regarding Alternate Proposals – Campus Communication: Please describe the nature of these communications. Are they automated or scheduled sends? Who is the intended audience?
A: Single sends, automated and scheduled campaigns/journeys will be needed. Audiences: Current Faculty/Staff and Students are our main audiences. We also communicate with non-recruitment external audiences. Some contacts may represent multiple groups (e.g., a staff member who is also a current graduate student and a parent of an undergraduate student). We have several different types of emails that are targeted at various demographic and academic groups. Campus alerts, newsletters, event information, faculty/staff and graduate student onboarding communications.
5. Regarding Alternate Proposals – Curated Set of Journeys: Please list the populations you would be looking to support with these automated campaigns (Senior Inquiry, Junior Inquiry, Incomplete Applicant, Admit, Graduate Occupational Therapy Inquiry, Graduate Incomplete Applicant, Graduate Admit, etc.)
A: Our combined audience total is approximately 300k contacts. Audiences for automated campaigns below:
Inquiries & Prospects (Name Buys):
Undergraduate: HS sophomores, HS juniors, HS seniors, transfers, readmits, internal audiences, Honors-eligible, parents of prospective students Graduate: Undergraduate USD students, internal & external audiences, staff, UG admits who attended a different school for undergrad, alumni, vocation-specific professionals such as nurses or teachers, employers, other professionals, busy adults, anyone with an undergraduate degree International: Prospects from a recruitment fair, (any previously mentioned audiences, international recruitment agents) Applicants:
Undergraduate: HS Dual Credit, HS seniors, transfers, readmits, adult learners, honors, parents of applicants Graduate: Current USD students, college students (from other schools), current USD faculty or staff, any other applicant International UG & Grad: HS seniors, adult learners, current UG students from USD or other school, professionals, other audiences previously mentioned (excluding HS dual credit)
6. Q: Regarding Alternate Proposals – Replicating Journeys: How many campaigns/populations would this entail? And approximately how many messages across each?
A: For populations, please see answer in question 5. For campaigns, we currently have the following journeys in Salesforce Marketing Cloud:
Undergraduate: USD story (13 emails), application-related (4 journeys, 1 email each), registration (4 journeys, 1-5 emails each), scholarship process (3 journeys, 1 email each), specific scholarship eligible (3 journeys, 1-5 emails each), dual credit-related (1 journey, 5 emails), financial aid (4 journeys, 1-5 emails each), honors (2 journeys, 1-5 emails each), housing (1 email), ROTC/military (1 email), application missing items (5 emails), enrollment missing items (1 email), career readiness (5 emails), high school visits (2 journeys, 4 emails each) Undergraduate Parents: Registration (1 email), financial aid (1 email), housing (1 email), Honors (1 email), newsletter confirmation (1 email) Graduate: USD story (5 emails), admitted students (8 emails), application submitted (1 email), registration (1 email) International: Prospect (4 emails), USD story for inquiries (12 emails for UG, 10 emails for grad), application submitted (1 email), I-20 missing items (5 emails), visa steps (3 journeys, 1 email each), PDSO-readiness (1 email), arrival information (1 email), enrollment deposit deadline (6 emails), graduate contingencies (1 email), housing registration survey (1 email).
7. Q: Regarding Alternate Proposals – Pre-Professional Applications: This is also listed as a core recruitment entity/target. Should this work be accounted for in the core proposal or as a supplementary add-on?
A: The building of the pre-professional applications should be considered a supplementary add-on.
8. Q: Is there a budget you can disclose?
A: No, we don’t disclose our budgets.
9. Q: Is there an end date for your current contract with Salesforce?
A: May 2025
10. Q: Have you identified a Slate captain or team?
A: We will have a Slate team that consists of resources in our various offices as described in Question 12. We will also have IT staff that will support these resources as needed.
11. Q: For 1.4.3 in the Scope of Work, can you elaborate on what you mean by alternate or sub-proposals? Are these items not included in the current proposal or phase of the implementation?
A: We are looking for separate cost breakdowns for these to determine whether we can include them in the initial project or if we will need a phased approach.
12. Q: How is your recruiting and admissions structure organized? Is it centralized or decentralized for the population listed in the RFP?
A: Recruiting and admissions operations are spread across three main offices (UG Admissions, Graduate Admissions, Enrollment Processing Center), though there is some involvement from academic areas in the recruitment process. Most of the application process is centralized. The review of applications can be decentralized for our graduate programs.
13. Q: Are your undergraduate and graduate enrollment teams completely separate?
A: USD has UG admissions, graduate admissions, and international admissions teams. The enrollment processing center supports all of these teams with data and document processing.
14. Q: What are you sources of applications:
A: NextGen, Form Assembly, FY Common App, Transfer Common App, GradCAS, CASPA, CSDCAS, NursingCAS, OTCAS, PTCAS and DocuSign.
15. Q: Could you provide more details on the integration purposes with CAS(s), Transact Campus Date, EAB Concourse Application Data, StarRez, and Scholarship Manager?
A: CAS(s) - These are application systems. We want all application data from these systems to be brought into Slate. Transact – We would like some data elements from Transact brought into Slate to determine if a student’s id card has been generated and picked up. EAB Concourse Applications – This is a reverse application tool that allows us to extend offers to students interested in USD without providing us identification information. Upon acceptance of our offer, loading their application data into Slate would be needed. StarRez – This is our housing software. In Salesforce, we are bringing in whether they have paid their housing deposit, move-in date, and room. Scholarship Manager – This is our scholarship management system. We would like to pull in data from this to associate with a given record.
16. Q: Will USD handle the integration configurations outside of Slate and data extraction from existing systems, or will these tasks be managed by the implementation partner?
A: USD will seek guidance on integration with Slate. All application integration (WebAdmit, CommonApp, etc.) we are seeking the consultant to build these out. StarRez, Transact, and other non-application tools, USD ITS will build those integrations.
17. Q: For portals and communications, are you migrating existing content and design or are you seeking assistance with new design, coding and content?
A: We have current designs in our Salesforce Experience (the application portal) and Salesforce Marketing Cloud (email communications). We can use those designs and code from them if possible and appropriate. If it's not realistic to migrate those for use in Slate, we will need to discuss design and coding options. We do not need assistance with content creation.
18. Q: You list several different student types throughout the RFP (Undergrad, Grad, Law, Med School, Pre-Professional, etc). In some areas these groups are listed under the “Alternate Proposals” section (Section 1.4.3). Can you provide a clearer prioritized list for which of these student groups will be implemented in Slate and what functionality will be implemented for each group?
A: *** UG and grad are priority. Law, Med and pre-professional are secondary.
19. Q: Can you confirm the project involves building only one Slate instance for all the referenced student groups/types (see Section 2.2)?
A: Please see the answer to Question 1.
20. Q: Section 2.2 (Recruitment Entities/Targets) references building an application and review process for each of the student groups mentioned in that section. Is the desired functionality truly only an application and review process? What is the full scope of this section? Does it also include and of the following: decision release and applicant notification, accepted student or enrollment response process?
A: We are looking to maximize our usage of Slate. We are open to learning more about Slate’s functionality and how it could improve our communication/application-decision workflow.
21. Q: Section 3. Deliverables and Requirements outlines desired functionality in the areas of Data Migration, Admissions Applications, Security and Access, Integrations, Reporting, Applicant Portal, Application Evaluation Workflows, and Marketing. Is there any additional functionality desired within the new Slate CRM?
A: See the answer to Question 20. We would like to use Slate’s integrated print solution for domestic acceptances.
22. Q: Section 3.1 Data Migration - Does USD have internal capacity to extract the historical data from Salesforce EDA or will you need additional expertise to assist with that function as well?
A: We have the expertise required to export this ourselves. Making this exported data useable and ingestible for Slate may require some assistance.
23. Q: Section 3.3 Applications to be Built – Please define “other application types to be specified” and their priority related to the May 1, 2025, deadline.
A: This would include the applications and forms below:
High Response Forms (in order of use) USD Application for Admission For undergraduate applicant for On Campus, Online, and USD – Sioux Falls USD Registration Survey Used to provide information required prior to sign up to a registration event for undergraduate on campus students.
Request Graduate Program Information USD Request for More Information Undergrad interest form USD Parent/Family Communications Used to allow parents to opt-in to special parent communications
Low Response Forms University of South Dakota Inquiry INTL This form is used for international travel, it adds the inquiry and marks them as a student met during international travel.
Employee of the Month Nomination Form Used by Human Resources International Non-Degree Seeking Application MD-MBA USD Application for Admission
24. Q: Section 3.4 Security and Access – Please define the functionality desired for “Workflows by application type” A: When a student’s application reaches a particular status, the application is ready for review, that application would be assigned to a team for review. There are various audiences that would receive different types of applications. The storage of this application and decisions should happen in Slate.
25. Q: Section 3.5 Integrations – How much support will the USD IT office be able to provide related to integrating with other campus-based systems?
A: USD ITS will be able to provide several resources for integrating between Slate and our SIS and application sources. We may need some assistance regarding best practices for Slate integration.
26. Q: Section 3.6 Functionality Replacement – Please provide a high-level review of “all functionality” that exists in the current platforms.
A: Outside of base Salesforce functionality, we are looking to replace our use of the following tools and their respective uses mentioned in 1.3 of the “3.0 Scope” in the RFP with Slate specific tools where possible:
Mogli – SMS texting; Marketing Cloud – Email Journeys; Conga – Emailing; VisitDays – Event management and tracking of campus visits; etc.
27. Q: Section 3.10 Marketing - Will the marketing/communications component of this project consist of migrating existing communications to Slate or will new campaigns/communications need to be developed as part of the project?
A: Migrating existing communication campaigns is part of the alternate proposal option in 1.4.3. No new communications need to be developed as part of this implementation project unless current communications are not applicable once in Slate due to new or change in functionality. USD does not need assistance with content creation.
28. Q: Section 3.11 Workflow Developments – Please provide additional detail for “Show available scholarship opportunities for qualified applicants.”
A: We have a table of existing scholarships with eligibility criteria. This would show the counselor which scholarships an applicant may be eligible for. Counselor communicates with applicant to remind them to apply to these.
29. Q: Is the core proposal for undergraduate and graduate programs or would graduate programs be considered under sub proposals as alternate proposals?
A: The core proposal includes undergraduate and graduate programs.
30. Q: How much historical information is the institution interested in transferring over from salesforce to Slate? Seven years was noted but only for applicants. Is there any historical perspective information to be migrated?
A: Undergraduate: 2 years of application and prospect data, Graduate: 4 years of application and prospect data
31. Q: Should alternate proposals be submitted as independent documents, or as an addendum to the existing proposal?
A: Please submit these as an addendum to the existing proposal.
32. Q: For graduate programs using the CAS Liaison system (or other common application systems) is the intention that an evaluation would continue in WebAdmit or is there interest in leveraging Slate workflow functionality for these graduate programs?
A: We would like to know the consultant’s recommendation on this topic.
33. Q: Please elaborate on the necessary data integrations with StarRez and TransAct. For payment processing, is the intent to integrate with an existing processor or to leverage Slate payments?
A: We would like to reflect in Slate whether the housing deposit, paid in StarRez, has been paid. Regarding Transact, we are looking to include a piece of data from our Transact system in Slate (not making payments).
Regarding payments in Slate, we are open to discussing Slate Payments. We currently utilize Authorize.Net. The policies regarding payment processors are set by the South Dakota Board of Regents.
34. Q: Does the institution intend to use a middleware solution for bidirectional feed development with SIS? Would you like us to include end-to-end integration services as a part of this proposal?
A: Yes, we are using TeamDynamix iPaaS for moving data. No, we don’t need end-to-end integration with our SIS included in this proposal.
35. Q: How many application processing workflows are there currently?
A: High School Dual Credit – 2, UG – 4, Grad – 2, non-degree seeking - 1
36. Q: Are you open to a communications analysis as part of this engagement to consolidate journeys where possible? 20 have been noted, but there may be significant opportunity to further consolidate.
A: Yes, we are open to the analysis and potential consolidation of journeys/campaigns.
37. Q: Please elaborate on “available scholarship opportunities” and aspirations around scholarships/financial aid in Slate.
A: Please see the answer to Question 28.
38. Q: It appears that USD is amendable to a phased approach based on the RFP. If there are elements noted in the scope that we feel would be best staged for a post May 2025 launch, is this acceptable for our response, providing reasoning aligns with USD’s aspirations?
A: Yes, a phased approach would be acceptable as long as recruitment processing can continue uninterrupted.
39. Q: Please describe the core team with whom we will be engaged for this implementation.
A: Please refer to the answer to Question 10.
40. Q: What specific data are you converting from Salesforce in terms of record types, amount and timing?
A: We have records that are applicants (~15k/year), prospects (~115k/year), leads (~30k/year), and other non-prospective contacts (~20k/year) which includes school counselors (~2k), parents (~5k), and current students (~10k).
41. Q: Since "Student Success" is out of scope, but "Deliver" (a Slate function) could be used for current students, is your intention for this to apply to current students or prospects/applicants?
A: Yes, we are looking for Deliver to be used with prospects, applicants, current students, and other internal audiences such as faculty and staff. We do not want to build out the full “Student Success” module, but just enough to use Deliver with our internal audiences.
42. Q: Could you include a subproposal for replicating a curated set of journeys provided by USD? Where are these journeys defined, and who are the target populations?
A: Refer to the answers to questions 5 and 6
43. Q: Do you plan to have a separate Slate instance for each of the application groups? Assuming one but please confirm.
A: Please see the answer to Question 1.
44. Q: With a May 1st go-live date, will you be mid-cycle and expecting conversion during that period?
A: We will be mid-cycle and need conversion of 2025 applicants.
45. Q: How many users from each group are expected to access the system?
A: We have 110 users in Salesforce. We are expecting an increase to around 150 when we move to Slate.
46. Q: Do you intend to use Slate Payments, or do you have a different payment vendor in mind?
A: We are currently using Authorize.net for payment processing, but we are open to learning more about Slate Payments.
47. Q: Are you operating on a rolling admission basis or with set deadlines? How will the timeline impact your notification processes?
A: Yes, both rolling admission basis and set deadlines. Also, see the answer to Question 44.
48. Q: Is USD planning to manage the third-party integrations, or are you seeking support for those integrations?
A: USD would like to manage the integrations. Building out the initial integration, help will be needed.
49. Q: Will USD provide dedicated resources for the implementation? If so, how many people will be involved, and what percentage of each person's time will be allocated to this work?
A: Yes, USD will provide resources whose highest priority will be this implementation.
File details come from the government source that posted it. Updated .