What did your orientation team do manually this summer that you’re already planning to do manually again next summer?
Move information between systems?
Reconcile another spreadsheet?
Check whether students had completed something?
Adjust schedules?
Track down exceptions?
Send the same information to another office?
Or keep a process moving because someone on your team knew exactly how to hold it together?
This is the part of the year when those things are still fresh.
And before another orientation cycle gets too far away, I think there is a question worth asking:
Is that workaround actually part of your orientation model, or is it something your team has simply learned to compensate for?
Those are very different things.
Manual doesn’t automatically mean broken
Not everything manual needs to be automated.
Not every exception needs software.
And every institution operates differently.
Sometimes a human decision is exactly where it belongs.
Sometimes an exception exists because the institution intentionally handles a particular situation differently.
Sometimes a process reflects something important about how that institution chooses to operate orientation.
The goal shouldn’t be to automate something simply because technology can.
The first step is understanding why the work exists.
Workarounds can become invisible
Other manual processes are different.
They survive because someone knows what spreadsheet to check.
Someone remembers which information needs to move from one system to another.
Someone knows which office needs an update.
Someone recognizes an exception before it becomes a problem.
Someone knows the sequence well enough to keep everything moving.
Over time, that knowledge can become so familiar that the workaround starts to look like the process itself.
But those aren’t necessarily the same thing.
When the same workaround survives orientation cycle after orientation cycle, it may be worth understanding what problem the team is actually solving.
Protect the model, question the workaround
This distinction matters to the way I’ve learned to think about technology.
An institution’s orientation model reflects its people, responsibilities, priorities, policies, systems, and decisions about how orientation should operate.
Technology should not casually redefine those things.
But that doesn’t mean every workaround created around that model deserves to survive forever.
The challenge is separating the parts of the orientation model worth protecting from the manual work people have learned to perform because their technology doesn’t fully support how the institution operates.
That’s a very different starting point from asking:
What can we automate?
Start by understanding how the institution operates
I’ve spent years learning that orientation models can look very different from one institution to another.
That’s why I don’t think the answer is simply to replace the process.
Before changing the technology, understand the work.
Why does this step exist?
Who needs the information?
What depends on it?
Which exceptions are intentional?
Which parts require professional judgment?
And which pieces are manual simply because nobody has given the team a better way to handle them?
Only then does the technology question become useful.
Because sometimes the better question isn’t whether a process can be automated.
It’s:
What could the process look like if the technology actually understood how your institution operates?