Higher education · Salesforce Strategy
Our first plan was a reusable package. Discovery found the delivery process had to come first.
Three Salesforce orgs, several hundred CRM licenses, and a central team already fully committed to day-to-day support. Bringing on a single department was taking between eight and sixteen months, and more than a dozen were waiting. The university secured budget specifically to shorten that.
12+ Departments
waiting
8–16 Months per
department
3 Onboardings
underway
A queue of departments waiting to get onto Salesforce, a central team already fully committed to day-to-day support, and budget secured specifically to shorten onboarding time.
A seven-stage onboarding playbook, a written baseline of the existing delivery process, and a reusable template set covering intake, scoping, user stories, testing, and adoption.
A standardized process across teams, with clearer expectations for stakeholders and more visibility into the work. Three onboardings now run concurrently, with departments ready and waiting behind them.
A queue of departments, and no spare hours to move them
A public research university runs Salesforce as a shared institutional service. Three centrally supported orgs covering several hundred CRM licenses and tens of thousands of community portal licenses, with several colleges running their own orgs alongside.
Two groups share the service. An institutional planning group owns the business relationship with each department. The central IT office owns the platform. Between them they run the queue of departments waiting to get onto Salesforce, alongside day-to-day support work. The team covers the full range of the work: two enterprise application admins, two developers, a QA analyst, and a scrum coach. It is also fully committed. The constraint was never capability. It was the hours available to redesign a process while continuing to run it.
Bringing on a single department was taking between eight and sixteen months. More than a dozen were waiting. The university secured budget specifically to shorten that, and that is what brought CUBE84 in.
The written brief was direct about the reason. They wanted a Salesforce consultant’s help to speed things up so the Office of IT team could work through the queue rather than redesign the process around it. The stated goals were fewer high-touch service hours, shorter time to launch, and better adoption after go-live.
“Through our work with CUBE84, we have been able to standardize our process between teams, which allows us to set better expectations with our stakeholders, and bring more transparency to our work.”
– Manager, Enterprise CRM, at a public research universityThe engagement started as a package build and changed during discovery
The original plan was straightforward. Review the Salesforce orgs, find the parts of department onboarding that repeat, and build a reusable package so each new department was not a fresh build.
Discovery changed the plan. One detail settled it: user testing scripts were being written first, and user stories were being derived from them afterwards. Requirements were arriving through the test layer. Building a package on top of that sequence would have made the wrong process faster.
The client pushed back at first, and reasonably so. The engagement had been scoped and priced as a package build, and changing the plan mid-engagement is not a small ask.
What resolved it was repositioning the offer rather than withdrawing it. Instead of a reusable package built on a process that was not yet stable, CUBE84 proposed reusable templates, for BRDs, user stories, and prioritization, that would surface the real onboarding process first. That reframing is what carried the decision.
Ten discovery sessions across autumn 2025, plus weekly check-ins running through to the start of 2026.
Requests arrived by web form or direct email. Detail varied, so the team ran exploratory calls to collect baseline information that could have been captured at submission.
A technical fit checklist and a strategic fit checklist existed, both reviewed conversationally with no shared scoring. An older weighted scoring matrix existed but was never put into use.
Depth varied by analyst. Current state was documented; the future state in Salesforce rarely was. No repository of past work existed to reuse, and no defined point marked analysis as complete.
No traceability ran from process documentation to user story to test scenario. Story-level visibility sat with the IT team, so business stakeholders could not see progress.
Testing was live and heavily facilitated by the IT team. With no defect taxonomy, usability questions were logged as bugs. Training materials were built fresh for each department.
No defined hypercare window, and no adoption measurement after go-live. Where usage dropped off in the weeks following launch, there was no mechanism to detect it.
The last row carries the most weight. Onboarding effort only returns value if the department is still using the system months later, and nothing in the process was set up to confirm that.
Two documents and a set of working templates, produced without configuring anything in Salesforce. Seven stages defined, and ten established practices given a documented replacement.
A seven-stage model covering intake, qualification, analysis, implementation, testing and training, go-live, and post-go-live adoption. Each stage carries its purpose, what CUBE84 observed, what to do instead, who owns it, and the benefit to expect.
A written baseline of how the university delivered Salesforce work before the engagement, covering six stages and naming the tools and roles at each one.
Reusable templates built against a real use case, centralized event management: a discovery questionnaire, a SIPOC Lite worksheet, a functional scope document, user stories, a data dictionary, to-be process diagrams, and a standing assumptions and constraints document.
Ten practices, each with a documented replacement
The university has been running the new process for nearly a year. Rollout is ongoing, and the changes below are at different stages of adoption.
Requests arrive by web form or direct email, with detail varying by department
Fit assessed conversationally against two checklists, with no shared scoring
No defined point at which analysis is complete
Future state in Salesforce rarely documented
No traceability from process documentation to user story to test scenario
Usability questions logged as defects
User testing facilitated live by the IT team for every department
No defined hypercare window, and adoption not measured
Every department configured from scratch
No one owning requirements capture for onboarding
A single structured intake with required baseline fields, so the first call is a conversation rather than a data-collection exercise
Five weighted categories producing a score out of 100, with three thresholds returning an immediate advance, hold, or redirect decision
Entry and exit criteria at every stage gate
A finalized current-state documentation template set, delivering to the CRM service in a consistent format and on schedule
A documented chain running from SIPOC through to-be process to user story to test scenario
A five-part taxonomy separating defects, expected behavior, usability concerns, enhancement requests, and training gaps
A two to five day self-test window with office hours and a formal readout
A fixed hypercare period with a defined exit, plus business reviews at 30 and 60 days to confirm departments are using the system as intended
A core configuration expected to fit 60 to 70 percent of a typical department, with delta work built on top
Named roles at each stage, including a business analyst function
The work the central team no longer does by hand:
Walking each department through user testing live, session by session.
Rebuilding training material from scratch every time.
Triaging usability complaints as if they were defects, then explaining the difference.
Running exploratory calls to collect intake information a form could have captured.
Answering progress questions from business stakeholders who cannot see the work.
Current-state documentation now arrives from the business analyst in a consistent format and on time. Departments are ready and waiting to be onboarded, and three onboardings are running with capacity left at the end of the program increment.
A central repository holds onboarding resources, with debriefs after each onboarding feeding updates back into it.
The qualification tool now identifies which department to onboard next against defined criteria, making sequencing objective and simpler.
A consistent demo, train, and test loop is familiarizing users earlier, with fewer support tickets during hypercare.
Asynchronous user testing with office hours gives users time to think about usability and returns meeting time to the team.
A growing library of user stories and test scenarios.
Business reviews at 30 and 60 days confirm departments are adopting the system as intended.
Some of the strongest parts of the current process were not in the playbook. The team built the central repository, added the post-onboarding debrief that feeds it, developed the qualification tool further than the original scoring model, extended adoption checks to 60 days, and started a shared library of user stories and test scenarios. The playbook gave the structure. The team made it theirs.
“For the first time since I have been here, we have units [departments] ready and waiting to be onboarded.”
Built with the university, not delivered to them
Ten discovery sessions ran across autumn 2025, with weekly check-ins through to the start of 2026. The team reviewed the playbook, returned feedback in December 2025, and signed it off by email.
The university continues to roll out the model, with more of the playbook still to implement. A second phase has been discussed: joining a live onboarding, working directly with the departments rather than only the central team, auditing the Salesforce orgs, and packaging what proves genuinely repeatable.
We can walk you through what we found on this engagement, and what we would check first in your environment.
Start a conversation
%201%20(1).png&w=640&q=75)