What is an enrollment product in higher education?

When it comes to enrollment management, I hypothesize that institutions in the education industry share many common administrative concerns as companies in other industries.

1. What's our forecast for the next quarter or year?
2. How much are we allocating to Marketing?
3. What's our historical ROI on past campaigns? And what are we expecting for new Marketing campaigns this year?

But one big difference I see between education institutions and other companies is how the above questions are answered. While other companies usually answer Questions 1 and 3 above with dollar amounts, education institutions (from the enrollment perspective) answer with student headcount or with class enrollments.

This may seem like a trivial distinction, but how useful would it be for Apple to announce their forecasts using the numbers of iPhones, iPads and MacBooks it plans to sell in the next year? Or worse yet, what if Apple simply said it would sell 1,000,000 products this year? And how would Apple's Marketing department calculate ROI for its myriad campaigns if this was the case?

Back in the world of education, I think there is a mental roadblock which prevents us from recognizing what our products truly are. Culturally, we, the administrators, think highly of education (which we should). But perhaps we've become ignorant of the underlying business model for education, which in the simplest sense revolves around the sale of products to customers. Put another way, the business model revolves around the enrollment of students in classes.

Let's explore the potential similarities and see whether they are legitimate.

• Student vs. Customer
• Enrollment vs. Sale
• Course vs. Product
• Class vs. Lot
• Seat in a class vs. Asset

We have recruiters, enrollment coaches and advisers who work with students to identify which courses to take to best meet their career aspirations and personal goals. Once the courses are identified, our staff help students to register for classes, thereby reserving their seats in the upcoming term. Once the add/drop period ends for a term, the enrollments are "closed" and invoices are sent to the students.

Other companies have salespeople working with customers to pick the most suitable products for each customer. Once customers decide to buy, they put in orders that are fulfilled in lots, resulting in assets (and associated invoices) delivered to each individual customer.

So, how different is an education institution from other companies? And if it's not that different, could adoption (or at least reconciliation) of real sales terminology be the way for an education institution to start answering the tough questions directly with real dollar amounts?

Note: I speak largely from my own experiences, and I recognize that there are other institutions which are already far along on the path of leveraging the concept of products in their CRM operations.

What Programs and Products Mean in Higher Education

The word "program" is very interesting in its application to higher education. If you ask any higher education administrator or staff member whether his or her institution offers programs, 99% (if not 100%) of the time you'll get a quick and confident "yes". But dive a little deeper and start asking how programs fit into the scheme of CRM, especially within the Salesforce framework, and you may run into a lot of unanswered questions (depending on which institution you're at).

At the crux of the confusion: What exactly is a program?

Merriam-Webster provides one definition of the word "program" as "a plan or system under which action may be taken toward a goal"; Merriam-Webster also provides an alternative definition as simply "curriculum". Great, now what?

Translated into higher education lingo, a program may be defined as a curriculum of study under which a student may enroll in classes with the goal of earning a degree or certification. In the world of enrollment, a program boils down to just another tool to entice people to purchase the products sold by a school, college or university.

At this point, another question may arise: Aren't programs the same thing as products in higher education?

The answer is "no", unless someone can give a convincing argument to support a different position. Products in higher education are the courses offered by an institution. Some may argue that students buy degrees, not courses. "A student comes to us saying that he wants a Bachelor of Science degree with a major in Accounting; the student doesn't come to us saying that they just want to take ACCT 101 and ACCT 102." This argument sort of makes sense but misses the mark in describing the true business relationship between institution and student. In reality, students buy courses and get degrees when enough courses are purchased and completed at an established standard of achievement.

So, in short, courses are the products, not programs. Programs exist to get customers to buy more products, which in the case of higher education are courses.

Armed with these two answers to two high-level questions, the conversation can now move on to how to setup this business model in Salesforce for effective CRM.

People, Not Contacts and Affiliations, Are the Way to Go

Poking around the nonprofit space today, I came across the Affiliations for the Nonprofit Starter Pack app on the AppExchange. I installed it, and all it ended up doing was creating a new object called Affiliation that links contacts with accounts. Ugh... I sense a very unpleasant asymmetry here, where a contact record can be related to an account either directly through the Account field or through an affiliation record sandwiched between the contact and another account.

While this structure definitely works to get us through most of our work, is this really the right way forward? If people at the Saleforce Foundation are pouring time and energy into developing something for the greater good, wouldn't it be great if we are assured that their focus is on the right vision?

Regarding affiliations, I don't think the Affiliation object is the right vision.

Here's a thought: Contacts were originally defined as people of interest related to an organization. Somehow, we diverged from this model by redefining contacts as people with a primary connection to a specific organization via the Lookup(Account) field. What's the difference, you ask? The difference is that in the original definition, a Contact record is the link between a person and an account; in the world with Affiliation as a junction between Contact and Account, we've redefined a Contact as the person, which it was never meant to be.

So, by introducing the Affiliation object, we've bastardized the idea of a "contact". How do we pick which Contact record stays with its account? How do we choose between a creating new Contact record and creating an Affiliation record? Is it better to have my Contact record as a child of account A with an affiliation to account B, or the other way around?

The answer: For orgs that want to map out people's relationships to different Account records, introduce the Person object. Then, link every Contact record to the appropriate Person record, and you have the magic sauce that paints the real picture of a person and his or her affiliations.