Using Journey Builder in Higher Ed to Engage Applicants
A continual challenge Higher Ed institutions face is engaging applicants digitally. Outlined below is our perspective when it comes to the strategic, tactical, and functional elements of engaging higher education applicants until they become students.
First, the following questions need to be answered:
- What should be communicated?
- What digital channels should be used/activated?
- What’s the messaging frequency and cadence?
- Is there an applicant lifecycle/flow built out?
- What content should be focused on?
- What data is available for an individual applicant as well as what data is available at a macro level to action on?
The answers to these questions begin the process of developing (or updating) how to leverage a platform, like Salesforce Marketing Cloud’s Journey Builder, to power these interactions.
Second, is to discover the ultimate goals associated with a digital engagement strategy for the applicant. They may include:
- Barrier reduction
- Information sharing
- Reduce attrition
- Centralize and standardize
- Deflect traditional means of communications in favor of digital communications
Creating a Journey for Applicants
Once the foundational work is finalized, approved, and there’s a path forward to begin building, it’s time to focus on the technical elements of using an orchestration mechanism, -- in this case, Journey Builder. As applicant data is fed into a CRM system (or data warehouse) from first party sources (eg. UND.edu/apply) or third party sources (eg. CommonApp), immediate communications to set expectations on the application process need to be initiated. This includes next steps, key decision points, FAQs, etc.
The platform’s function is architected to introduce layers of data-based decisioning, a/b testing, dynamic content and a branch-flow method to customize and personalize the applicant’s interaction with the institution.
TIP: Don’t over-engineer a journey to meet every single use case you can think of. It creates a headache in updating, troubleshooting, and versioning over time. Instead, break down each journey to its core components and spin off other journeys to fill in gaps, complement or supplement, as needed.
Once you’ve gone through the process of design -> build -> test -> QA, it’s time to go live. This process shouldn’t operate like Ron Popeil's “set it and forget it” ideology. Now that you’re live it’s time to look for key metrics in the reporting to see if your messages are being received, applicants are engaging, and if they’re completing intended actions. Using that data you can start the iterative process of optimizing that journey through A/B/C/n testing on timing, content, and decisioning as intel is gathered intel to compare against your KPI(s).
Some final considerations surround approaching a new applicant: Once the lines of communication are open, it’s important to tread carefully and understand the applicant’s needs/wants/desires before embarking on what you think they need/want/desire (or even worse, what you need/want/desire) to avoid burning the bridge that was just built.