Because Slate was built specifically for higher ed, it offers end-users many benefits, especially when compared to older systems that weren’t originally built for student-record data. Still, even schools using it find themselves facing some common challenges and questions when it comes to optimizing their use of the platform.

We asked Slate expert and Vice President for Client Technology at RHB, Erin Gore, to talk with us about how institutions can best use Slate to help them store, gather, and analyze top-of-the funnel data, helping them to build robust applicant and admit pools.

HAI: Hi Erin! Thanks for joining us. Could you tell us a bit about your background?

EG: Of course! As you mentioned, I am the VP for Client Technology at RHB which has been providing counsel for 30 years to colleges and universities and inspiring them towards greater relevance. Although we’re here to discuss Slate, RHB has also served as expert advisors to presidents, Boards of Trustees, enrollment management and marketing leadership. This affords us the opportunity to provide clients with cross-practice services that intersect Slate such as college search optimization, student success, recruitment, marketing and communication planning.

Before arriving at RHB, I worked at Technolutions, for six years. I started as a senior program manager, helping institutions with their Slate implementations and troubleshooting. I also served as the general manager of Slate.org, which is the 100% free Technolutions platform for the secondary school market, community-based organizations, and students. I had the opportunity to help launch it, conceptualize new features and work hands-on with college counselors and community-based organizations, which was quite rewarding.

Before I got into more ed-tech, I worked in admissions and enrollment management for over a decade – I worked in undergraduate admissions as well as graduate and business school admissions. And, as many do, in admissions I wore multiple hats and one of them happened to be becoming more of the data person and the person who implemented different systems and CRMs, one of which was Slate. As a result of these experiences, I’ve seen Slate through a variety of different lenses. I did everything from figuring out how to get data into the system and get systems to talk to each other, to working hands-on with Slate at Technolutions, to now, working with an entire team of Slate experts as we help guide institutions on best practices for implementing and optimizing Slate.

HAI: That’s such and interesting background and I’m sure that you have a lot of advice for our audience, so let’s jump into questions. First, in general, what do you see as the biggest strengths of Slate?

EG: I think the way it has been purpose-built for higher education, thinking about admissions and the process needs, which, to me, makes it not only robust, but also intuitive. It’s also a very comprehensive platform – it allows colleges and universities to more centrally manage their data, in terms of communications, applications, reporting, evaluation processes, you name it! The fact that it can handle all of these processes in one place, means that fewer systems are needed and fewer systems have to be managed.

HAI: We definitely agree with that. What are some best practices that you can share when it comes to migrating to Slate from another CRM or data system and what are some of the things enrollment managers should be thinking about before they begin an implementation?

EG: I think the first thing is to pause, and let your blood pressure lower! I think any time you say the phrase “data migration”, it can cause some anxiety. I joke with clients about how moving to a new system like Slate often requires you to break up with your previous system. To begin the implementation, I always recommend to clients that they start with their core data and break things into smaller chunks. Don’t try to dump everything in at the same time or replicate your SIS. Think of Slate as a new house and approach it with strategic optimism. You don’t want to shove old, clunky furniture into a new house. Instead, you want to really reimagine what is possible. As an example, if you have a code in your SIS, let’s say Biology has to be called BioUG12468, that doesn’t mean this is how you should structure it in Slate. Slate is very robust and you can export data back out in a way that other systems need to consume it. But, you should be building out in Slate in a way that is intuitive and makes sense for you on a day-to-day basis. Think about what core data you need first, knowing that you can bring additional data points in later. As an example, you can create a custom unique identifier in Slate that can be used for matching records in your other systems, such as your student information system.

HAI: I think you just touched on some elements of my next question, which is, are there particular places where you’ve seen clients run into difficulties and, if so, how did the issues get resolved?

EG: Yes. At the end of the day, Slate is a robust system and it is only going to do what you tell it to do, and, in many ways, that’s the beauty of it. But, if you tell it to do too much, or maybe you tell it to do the wrong thing, that’s where you can run into problems. I always say that a strong foundation for your database starts with a strong foundation for your data. At RHB, we start every implementation off by guiding clients through the set-up of their core configuration, such as their fields and prompts. The reason being that this is the foundation for storing your data in Slate. We have seen instances where problems arise, perhaps the client is seeing inaccurate data or inconsistent reports, due to a configuration that is overly complicated or has inconsistencies. For example, they may be storing a data point in two different places, or they have created custom fields for data that already has a place to live in Slate. In other words, you shouldn’t have a custom field for ‘address’ when ‘address’ data already has a home in the address table in Slate. We do database diagnostics and there are times when we will audit databases for colleges and universities that may have implemented Slate years ago. The first thing we do is look at the existing data configurations and how the client can streamline or improve the data collection process. I often say that, when trouble-shooting in Slate, sometimes you encounter an onion: an issue that looks very complicated, but when you begin to peel back layers, you realize it is stemming from a simple misconfiguration of a field.

HAI: Often, we see situations where a client migrates to Slate from a legacy system that they had to do a lot of customization on and they don’t realize that they will not have to do the same with Slate.

EG: And that is understandable. Even in Slate, there are different ways to store data points. There are tags, interactions, and fields, so we may see a tag on a record that says “Recruited Athlete” and then a custom field that says “Top Athletic Recruit” – now you have the same information being stored in two different locations.

HAI: We hear our clients talk about capabilities in Slate that they are not yet using, or that they would like to take advantage of that they are not. Are there any features you think Slate users should really be taking advantage of?

EG: We tend to see that clients are not taking advantage of the auditing tools that are available to them in Slate. For example, there is a “job activity monitor” where you can monitor scheduled exports and report rendering. There is also the ability to check the health of your automations, or rules, to make sure they are behaving as intended. These and other tools allow you to proactively monitor the day-to-day activity in your database and I think sometimes folks forget to look at the auditing menu in their Slate database.

HAI: When it comes to loading prospects and inquiries into Slate, or even defining these two stages, do you provide any advice to clients on how they can ensure they have a clear delineation between the two?

EG: I think it goes back to consistency. There certainly are conversations that need to take place outside of Slate to make decisions about what it means to be a prospect or inquiry. But, equally as important is that, if a client is running many searches from different sources, or working with a few different vendors, they need to make sure their definitions are consistent across these channels. Once again, the beauty of Slate is that it’s going to do what you tell it to do. You can tell Slate when someone should be considered an inquiry or a prospect upon import.

HAI: Another thing we have seen is that there is a lot of variation in terms of the information clients are deciding to bring into Slate – some are using it strictly as a CRM, while others are pulling financial aid data into it. Do you see that variation as well with the clients you work with, and do you have any thoughts on what the best practices are around this issue?

EG: We encourage people to maximize their Slate instance in phases. But the more data you can house in one place, the more consistency and data integrity you will have, not only for yourself and your reporting, but also in terms of the student experience. You have to think about the student user experience. We often see that schools are sending emails to inquiries out of Slate with links that allow them to sign up for events. If they do the same for applicants or admitted students, that makes the experience more consistent from the students’ viewpoint.

We tend to work with clients on establishing what we call the “applicant experience portal”. These portals consist of dynamic views that empower colleges and universities to communicate with students along their journey from the point of application to enrollment. Calls to action may be centered around missing application materials, admitted student events, and financial aid and scholarships to help them make a more informed decision. Does that mean schools should be importing every piece of data they have in their financial aid system into Slate? Probably not. We encourage clients to think about the goal. For example, are there actions they need the student to take to help complete the financial aid process; or, is there information students need to know and at what stage of the funnel do they need to know it? Identify the calls to action that you need to push out to the students through Slate and have that inform the data you decide to bring into Slate.

HAI: Erin, this has been incredibly informative. As we wrap up, are there any other best practices that you feel like readers need to know that we haven’t touched on yet?

EG: There is so much that we could talk about, but, I honestly can’t emphasize enough how important it is to really think through what your processes are and what your strategy is before you try to build anything out in Slate. Too often, we’ve seen folks try to build out their communication plan or their engagement scoring in Slate, before having a conversation about what their strategy and goals are outside of Slate. Ask questions like, what does engagement mean to us?

HAI: Erin, thank you so much for taking this time to talk with me. If one of our readers would like to talk with you more about the services you offer at RHB, how should they reach out?

EG: They can always go to rhb.com to learn more about our services or reach out to our SVP of Relationship Development, Alex Williams. I also encourage readers to follow RHB Insights, as well, where they can hear more from our team of experts.

If you would like to hear more about the solutions provided by HAI, you can find more information here, or send us a note here.