Slate for Student Success

Technolutions’ Slate software is built for admissions, but the system is highly customizable and can be used for more than just admitting students. You can build processes in Slate that help you manage advising, academic standards investigations and appointments with the career services team. All these activities would be considered “Slate for Student Success,” which is really anything that happens after recruiting and enrolling a student. 

Building student success processes into a system like Slate is attractive for a lot of reasons. It’s not enough to enroll students; we want to make sure they’re thriving, growing and succeeding past graduation. Colleges need to make higher education easier to navigate, especially complex processes like financial aid. Universities have SIS systems that might be difficult for faculty to navigate, or they might not be the correct place to hold certain student data. Most universities use multiple data systems, and you might want to see, display or aggregate information from multiple places, while being able to add data on top. These are all great reasons to use Slate for Student Success.

After implementing student success systems at a variety of different institutions, we’ve noticed some themes and trends. If you’re considering using Slate to serve your current students, faculty or staff, you should have a clear vision before beginning. Slate for Student Success doesn’t have a defined step-by-step roadmap like admissions; each student success implementation is highly customized to the school’s particular place in the universe. 

Same database or different?

First things first. You already have a Slate system. Why not just add on? We’ve worked with schools who have gone both ways—a system where admissions and student services work in the same database—and other schools where separate databases house each silo. Both can work, and maybe your budget constraints make the decision easier for you.

We’ve seen adding on to an admissions database works best for smaller institutions, and those with younger admissions databases. But if we’re honest, separate databases for admissions and student success provide the best opportunity to take full advantage of all the creative ways you can customize Slate tools for your students’ needs. You have the sandbox all to yourself, and you get to decide the rules.

However, if you choose to add on to an admissions database, make sure that:  

  • There is one central Slate Captain and a Slate Team with the governance authority to make decisions on how tools are used (and who can manage user permissions, which can become tricky). The Slate Captain should have the time to oversee student services in Slate and the authority to lead decisions.
  • Accept that some student success ideas may not be feasible or as easy to implement because the “sandbox rules” have already been set with admissions’ needs in mind.
  • If you only need Slate for Student Success for smaller, more specific goals, combining databases might be fine, especially if it is going to be the same user managing/adding data for admissions and student success.
Make decisions on who 

Every system needs a Slate Captain, and a student success implementation is no different. Whether you’re using the same system as admissions or building a new Slate database, you will need a systems analyst who will take the lead and who will have authority to drive decisions. “Who” is also which office on campus will own the Student Success side of Slate. Is “who” Career Services? Financial Aid? The Dean’s Office? You need to decide on a clear Slate leadership team and governance strategy. 

Once other offices realize they can also use Slate for their work, you’ll be pulled in lots of different directions, which is why you need to decide who has ultimate governance over the project and why you’re implementing the system.

Make decisions on why 

Because there’s no defined roadmap, and you can do almost everything, you need to keep your eyes on the prize. Define your one to two primary specific goal(s) and stick to them while developing your system. 

Some primary goals we’ve helped schools develop in the past are:

  • A student tracking system for a K-12 school to share notes about student’s well-being and trigger immediate action when intervention is necessary.
  • An appointment booking system for a small liberal arts university where success coaches and career services staff can manage their appointments with students, the students can book appointments with staff and the office can ensure students with specific profiles (such as a low midterm grade) are meeting with a coach.
  • A central place for students at a large university to see a list of resources and links, and a system for managing various institutional and national award applications, like Rhodes, Fulbright and Marshall Scholars.
  • A place to pool data from multiple systems into a central view and provide a way for faculty and staff at a large university to view selected student data points easily.
  • A place where graduate program administrators and advisors at a state flagship graduate school can log study milestones, faculty committee members, publications, funding, research contributions, etc. 

It’s easy to get distracted once you realize Slate can do so much. And you might say “yes” to everything above. But picking one key priority for you and your team will help you create a system that is immediately additive to your work. Once everyone’s comfortable, then you get to add to it with more goals and more stakeholders.

Make decisions on how much

Now that you know your primary “why,” you’re going to get overwhelmed with all the possibilities. What do you want the system to do? The answer to that question can’t be “everything!”

Make a list of everything you hope to accomplish in Slate. Then ask yourself, “Which of these moves me to my primary goal I defined in step 3?” Those are your Phase 1 implementation strategies for Slate for Student Success. 

Anything that sounds exciting but does not move you toward your primary goal is Phase 2. This should come after Phase 1 (obviously) but it’s still important to outline them! Your other ideas are still goals, and you might be able to think longer term by structuring your database in a way that sets you up for Phase 2. 

For example, maybe you primarily want a system to help schedule coaching appointments with students who have lower midterm or final grades. But maybe eventually you’d like to report on which classes tend to have lower midterm grades to target your outreach even earlier or advise students to be wary of taking too many of these classes at once. That’s a Phase II goal, but you might set up the data structure in your system with an eye on that (eventual) prize.

You’ve made your big decisions. You’ve got a governance strategy in place, and you have some immediate and long-term goals. You’re ready to implement Slate for Student Success. In our experiences designing student success systems, we’ve begun advising clients to begin thinking about a few things sooner rather than later. Here’s what you should be ready to tackle as soon as you confirm your Slate database. 

Get your IT department’s time right away

The first step to almost all student success implementations is integration with one or more information systems on campus, most notably your school’s central SIS. You will need to complete this step before building anything in the database, because this is your source for data and records.

Your IT department will need to be ready to build data exports that include all the fields you’re hoping to display or use in your Slate system with the specific group of students you need. You can be ready with a brainstormed list of fields. 

You should also think of the group of students your Slate system will hold. Is it all currently enrolled students? Does that include students on study abroad or leave of absence? Does it include non-degree seeking students? When do incoming students move from admissions into student success? Should the system house newly graduated students? 

All these questions will need to be answered before IT can build your data feed into Slate for Student Success. Be ready with answers—and be sure someone is ready with time to build those file exports and then assist with setting up a regular data feed (usually nightly) into your Slate database.

Portal or Custom Tabs with Population Permissions?

There are so many ways you can display data in Slate, and you’ll need to define who should have access to Slate and who might best be served with a portal to view only selected students and selected data. While beginning a Student Success implementation, you should define what types of staff might fall into each category. 

Photo and other multimedia content needs

Of course, when you look up a student, you’ll probably want to see their picture! That’s not exactly ready-built technology in Slate (admissions offices don’t tend to ask for an applicant’s photo), but there are tools to use.

  • If your campus already has a student photo library that you can access with a unique URL for each student, you can easily embed the photo in a dashboard and portal. If that’s the case, each student likely has a corresponding URL like[Student ID here]. 
  • You can use the Deliver Library to house your student photos, but this does take manual upkeep from your team. You’ll need to develop a process to remove old photos from students who have graduated. To make that as easy as possible, think carefully and begin using a folder structure from the beginning that will help you identify photos that need to be removed when the time comes. An example might look like:

  • You can also save photos in a text field using base-64 encoding within a form. There are limitations here, too, though. You will likely need to upload each student’s photo separately using a form to get the base-64 encoding saved in the field. This might be a viable solution if you plan on students entering their photos themselves in a portal. And since you’re saving the photo in a field, you’re able to easily query and delete those photos when needed.

We often speak with schools who want to send emails to students. It’s a primary goal of many Student Success implementations. Anyone using Slate in a portal or in the administrative view will be able to send individual emails to students, and that email will be saved on a student’s timeline. You’ll also be able to see when a student opened the email–very useful information when checking someone’s engagement.

You can develop configurations in Slate Deliver and Slate Forms to allow staff and potentially faculty to send emails to larger groups of students. We have also helped teams configure forms to request emails that are then built by a coordinator trained in Slate Deliver.

To decide which tools are best for your team, discuss internally to decide:

  • What types of emailing tools do you want staff to use? What are some examples of email communications you see staff sending?
  • Should staff/faculty be able to send mass emails themselves, or should they send email content to another Slate user to build the email and deliver query?

Having answers ready for these questions will help develop the system’s configuration for your institution, which will likely use:

  • Populations, realms and permission structures to allow separate departments to access (and email) students within their population.
  • Form solutions for users to email (or request an email) with content they write. 
  • Query templates to help users build deliver queries to common groups of students.

Developing a clear vision and setting primary goals is key. Making sure you have personnel in place to manage the system and make decisions on system configurations is equally important. Thinking about all of these decisions before starting a student success implementation puts you—and your students—on the path to success.

  • Spread the word