Most university RFPs for a Salesforce partner ask about company size, years in business, and certifications held, and those answers predict almost nothing about how the project will go. The ten questions below predict a great deal. Each comes with what a good answer sounds like and the warning sign to listen for, drawn from the projects ElevateActual has delivered.
Why Do Most RFPs Ask the Wrong Questions?
A Salesforce project at a university fails in predictable places: the people who sold it are not the people who build it, the data model is customized before anyone checked the platform, the SIS integration has no owner, the scope has no edges, and nobody planned the two weeks after go-live. None of those failures shows up in a certification count. They show up in answers to specific questions. A partner who has done the work answers in names, objects, dates, and screens. A partner who has not answers in adjectives. Our delivery method is built around the same ten questions.
What Should the Committee Ask?
1. Who Exactly Will Do the Work, and Have They Built This on Education Cloud Before?
Ask for names, roles, and the share of each person's time on your project, then ask each named person which Education Cloud (Agentforce Education) build they personally delivered. A good answer names a solution architect, a functional lead, and a project manager who will be on every call. A warning sign is a practice lead for the sales cycle and "a certified consultant" for the build. Our team page lists the nine people who do our work.
2. Show Us a Storefront or Portal Running on Your Own Org Before We Sign
Ask to click through a working storefront or applicant portal on the partner's own org, on the products proposed. A good answer is a URL, sent before the demo, that the committee can open alone. A warning sign is a demo only the partner can drive. Our demonstration storefronts and the demo archive exist so a committee can click through working storefronts before a call.
3. Which Standard Objects Will You Use, and Which Customizations Do You Plan, With Reasons?
Ask for the standard Education Cloud objects the partner will use and every custom object or field they expect to create, each with a reason. A good answer uses LearningProgram, CourseOffering, CourseOfferingParticipant, IndividualApplication, and AcademicTerm by name. A warning sign is a proposal that leads with a custom data model. Our standard-first architecture stance explains why we hold this line.
4. How Do You Integrate With Our SIS, and Who Owns the Integration?
Ask which integration pattern the partner proposes for Banner, Colleague, Jenzabar, or PeopleSoft, and who owns each side after go-live. A good answer names the pattern (a supported API, a staging table, or an integration platform the university already licenses), names the university-side owner, and refuses direct database writes. A warning sign is "we will figure out integration in discovery," or a plan in which the partner owns a nightly job forever.
5. What Is in the Fixed Scope, and What Is a Change?
Ask for the scope boundary in writing: what the project delivers, what it explicitly does not, and how something moves from the second list to the first. A good answer is a "not included" list as long as the "included" list, and a change process that names who approves and how it is priced. A warning sign is a scope written as goals rather than deliverables. Our fixed-scope accelerators each come with a published boundary for this reason.
6. How Do You Run UAT and the Production Hot Test?
Ask who writes the acceptance scripts, who executes them, what the exit criteria are, and whether a real transaction runs in production before launch. A good answer has the university's own staff executing the scripts, a signed acceptance, and a hot test in which a real card is charged, a real receipt is sent, and a real enrollment lands, then is reversed. A warning sign is UAT described as "a two-week window" with no scripts, or no production test at all.
7. What Happens in the Two Weeks After Go-Live?
Ask who is on call, how defects are triaged, and when the project team hands off to support. A good answer names the people who stay on, sets a daily check-in for the first week, and defines a launch defect (fixed under the project) versus a change request. A warning sign is a plan that ends at go-live.
8. How Will Our Admins Maintain It?
Ask what a university administrator will be able to do without the partner: add a program, change a price, open a term, or adjust a Flow. A good answer includes a permission set designed for the unit, training on the real configuration, documentation of every Flow, and a list of what still requires a developer. A warning sign is Apex where Flow would have done; most units do not have a developer.
9. What Is Your Partner Tier and Accreditation, and What Does the Tier Measure?
Salesforce consulting partners carry a program tier; as of October 2026 the tiers you will see on proposals are Select and Summit. A good answer is honest: the tier reflects a partner's overall standing in Salesforce's program across every industry it serves, not Education Cloud experience. The industry signal is the Education Cloud accreditation. A warning sign is a partner who presents the tier as a product credential. ElevateActual is a Select Partner with the Education Cloud accreditation; a larger firm without that accreditation has more people, not necessarily a deeper education practice.
10. Which References Can We Call?
Ask for references at institutions like yours, for the product you are buying, delivered by the people named in the proposal, with at least one that went live in the past twelve months. Then ask the reference about the two weeks after go-live. A warning sign is a reference from a different industry, product, or team. Our case studies describe the scope of each engagement.
How Do You Read the Answers?
A partner who gives warning-sign answers to three or more of these is telling you how the project will go.
| Question | A good answer | A warning sign |
|---|---|---|
| Staffing | Named people, roles, time allocation, each with a first-person Education Cloud build | "A certified team" or an unnamed bench |
| Working demo | A URL the committee can open alone, on the products proposed | Slides, or a demo only the vendor can drive |
| Standard objects and customizations | Standard objects named; a short custom list with reasons | A custom data model, or no knowledge of the standard one |
| SIS integration | A named pattern, a university-side owner, no direct database writes | "We will figure it out in discovery" |
| Scope and changes | A "not included" list and a priced change process | Scope written as goals; time and materials with no boundary |
| UAT and hot test | University staff execute scripts; a real production transaction, reversed | A two-week window with no scripts; no production test |
| Two weeks after go-live | Named people on call, daily check-ins, a definition of a launch defect | The plan ends at go-live |
| Admin maintenance | A unit permission set, Flow automation, documentation, training | Apex everywhere; every change goes through the partner |
| Tier and accreditation | Tier stated as program standing; Education Cloud accreditation held | Tier presented as an education credential; accreditation unknown |
| References | Same product, similar institution, same named team, one recent go-live | Different industry, product, or team |
The Committee Checklist
Copy this list into the RFP or bring it to the finalist presentation. Each item is a request for a specific artifact, so the answer is either present or absent.
- A staffing table naming each person, role, time allocation, and one Education Cloud build each has personally delivered.
- A URL to a working storefront or portal on the partner's own org that the committee can open alone.
- The standard Education Cloud objects the partner will use for this scope.
- Every custom object and field the partner plans to create, each with a written reason.
- The SIS integration pattern, the university-side owner, and a statement that no direct database writes will be made.
- A scope section with an explicit "not included" list and a change process that names the approver and the pricing method.
- The UAT plan: who writes scripts, who executes them, the exit criteria, and the sign-off form.
- The production hot test plan: what transaction runs, by whom, and how it is reversed.
- The post-go-live plan: named people on call, the week-one cadence, and the definition of a launch defect.
- The administrator enablement plan: permission set, training, documentation, and the changes that still require a developer.
- The partner's program tier, Education Cloud accreditation status, and its own description of what the tier measures.
- Three references at comparable institutions for the same product, delivered by the named team, at least one live within twelve months.
- A timeline that states the scope it assumes; our guide to Education Cloud implementation timelines by scope gives the committee a baseline.
A committee that gets all thirteen artifacts will know more about its finalists than most universities know about their partner at go-live. Our pillar guide to Salesforce for higher education covers what those artifacts should contain for each scope.
Questions We Hear
Should we require a Summit partner?
No. Require the Education Cloud accreditation and the named people, and treat the tier as a measure of overall program standing, not education depth. A Summit partner's education practice may be a small team inside a large firm; the tier does not tell you. Ask questions one and two, and the tier question answers itself.
How do we verify that a demo is real?
Ask for the URL before the presentation and open it yourself. Add a course to the cart and check out as a guest; a real Salesforce Commerce storefront produces an order and, if connected to Education Cloud, an enrollment record. Ask the partner to show the Salesforce record your test created, with its timestamp.
Can we ask these questions of an incumbent partner too?
Yes, and you should. An incumbent has an advantage on question one, because the people are known, and should be held to the same standard on questions three through eight. The most useful question for an incumbent is number eight: ask what your administrators can change today without opening a ticket.
What if our procurement office requires a fixed price?
Fixed price works when the scope is fixed, and the scope is fixed only when the "not included" list is written down. Ask every finalist for the same scope boundary and compare prices only after confirming the boundaries match; a lower price with a shorter "not included" list is often a higher price once the changes arrive.
How long should the evaluation take?
Shorter than most committees plan, if the questions above are in the RFP. Reference calls are the long pole; schedule them before the finalist presentations. A committee that allows three weeks for responses, holds presentations in week five, and calls references in week six will have a defensible selection in under two months.