The Other Side of the Digital University: Paper Processes, Duplicate…

In a previous post, we looked at the university through the eyes of its students: the generation that compares it with Netflix and finds itself jumping between several systems for a single procedure.

The conclusion was that the problem isn't the app, but the layer underneath. That "underneath" has a side students never see, and it's the one we dig into in this article: the back room, the engine room where university staff hold together, by hand, what the digital front end promises to the outside world.

We write from Spain, but the pattern will be familiar to anyone who has worked in higher-education IT. Because the same piece of data a student has to type in several times is also being typed in repeatedly by someone inside the university. And that person isn't the villain of this story: they're its main victim.

Several systems, several versions of the same student, and none of them definitive

Information at a university tends to live fragmented in silos, one per system. Admissions has its own in the recruitment CRM; the academic records office, in the academic management system; payments, in the payment platform; teaching activity, in the virtual campus...

Each one rules its own patch and none knows the state of the others. The student is one person, but inside the university there are several records that diverge from one another, get updated at different paces and have never been matched against a common identifier.

This isn't an abstract data-model problem. It's the reason a tutor who wants to understand a student's situation (how they're doing, whether they've paid, whether they applied for a scholarship or financial aid, whether they're showing signs of dropping out…) has to open several screens and manually reconstruct a story that no system tells in full.

It's the reason that, when two departments argue over a figure, the meeting ends up being about which system is the reliable source. And it's the reason that leadership decisions are made, more often than anyone admits, on partial Excel exports instead of a consolidated view.

Staff as human middleware

When two systems don't expose a common interface, you need an intermediate layer to translate between them: middleware. At many universities, that middleware is a person.

They're the one who exports a list from the admissions system and imports it into the academic management system. The one who re-enters a student's data by hand from the CRM into the payment platform because there's no integration between the two.

The one who maintains the parallel spreadsheet (the one the team actually uses) because the official system doesn't provide the view day-to-day operations need.

Each of those tasks is a connector implemented in flesh and blood: it exists because, at some point, two systems that should exchange data went silent and someone had to sync them by hand.

It's invisible work and, above all, a skilled resource misused: people with judgment spending their best hours extracting, reconciling and reloading data by copying and pasting.

And one thing needs to be said clearly: this isn't solved with more training. At most universities, the team knows its tools well; the real brake is adoption, not knowledge.

The limit isn't that they don't know how to use the tools. It's that the tools force them to do by hand a process that should be automated. Training someone better for a task that shouldn't exist doesn't eliminate the task.

Why the same piece of data ends up being typed in several times

It's worth understanding the origin, because it's the logical consequence of how the system map was built.

Universities didn't buy their technology all at once or under a common blueprint. They accumulated it in layers, as needs arose: first the academic ERP, then the virtual campus, later a recruitment CRM, then the electronic administrative portal required by Spanish e-government law.

The academic management system, the virtual campus, the CRM, the electronic portal, the institutional website, the Microsoft or Google environments, the library and HR all coexist, and none of them was bought, deployed or is governed with the others in mind.

When it's time to integrate them, the default route is point-to-point: a custom bridge between system A and B, another between B and C, another between A and C. It's an approach that doesn't scale.

With four systems the bridges are manageable; with twelve they become a tangle nobody maintains, one that breaks in a chain reaction every time one of the systems is updated.

There comes a point where it's "cheaper" to absorb the difference with a person than to build and maintain yet another fragile integration. That's how manual work stops being an occasional workaround and becomes the de facto integration architecture.

On top of this comes a limit we already pointed out in the previous post: many of the shared platforms universities rely on only allow services to be embedded through iframes or webviews, without exposing their own APIs to build real integrations on.

They share a screen, but not the data. And then there's the permissions layer: students, faculty, administrative staff and external users all live under a single role model that fits none of them well, so exceptions end up being handled, once again, by hand.

The result is that student data has no single source of truth. It's entered in admissions, replicated in the academic records office, typed in again in payments. The same data three times means three chances to introduce an inconsistency, and no reliable way to know which of the three versions is the right one.

The bill that appears in no budget and that everyone pays

This back room has a real cost, even if it doesn't appear on any budget line. The most visible part is time, but underneath there are costs that are more expensive and quieter:

Human error, which in a manual process at enough volume isn't a risk but a statistical certainty: it spreads through every system that draws on that data until someone catches it (or until the student does, which is worse).
Inconsistency between sources, which turns every data point into a subject of negotiation between departments.
And the most expensive of all: decisions made on incomplete information, because there's no consolidated view and everyone decides based on the piece they happened to see.

There's also a regulatory layer that is tightening the screws and making all this less and less sustainable. Spanish public-sector and higher-education rules on digital administration and interoperability, together with the GDPR and the EU AI Act, aren't recommendations: they're growing obligations.

Data scattered across several silos, synced by hand and with no traceability of who changed it, when and on what basis, is hard to govern and almost impossible to audit.

And above all, there's the opportunity cost. A team that spends its capacity keeping systems in sync (acting as glue between pieces that don't fit) is a team that isn't working on spotting a dropout in time, redesigning a process or attending to what really matters.

When data moves without anyone pushing it

It helps to ground the opposite scenario, because it isn't a utopia: it's what's already being built at several Spanish universities.

A student writes "I need my transcript for a scholarship application" and the process resolves itself: it's generated, signed and sent, without opening a form or going through the back office.

A tutor looks up a student's full history and gets a single, coherent answer, not several screens they have to cross-reference in their head. The student's data is captured once, at enrollment, and from there it travels on its own: the admissions record triggers the academic record, which activates the student file, which connects to payments, without anyone typing it again. When something changes, it changes in one place and propagates to the rest.

The difference isn't in having "better" systems, but in how they're connected. Instead of a tangle of point-to-point bridges, an orchestration layer through which data flows once and remains available, governed, to every process that needs it.

And without ripping out what already exists: the academic system, the virtual campus and the CRM aren't replaced, they're orchestrated on top of a common foundation that gets them talking. On top of that layer, repetitive work gets automated and what requires judgment is left to people.

A change of role for teams: from typing data to making decisions

When the mechanical work is handled by the platform, the team's role changes in nature. Administrative staff stop being the human connector that enters data and move on to supervising that the system handles it properly; they stop executing procedures in a chain and focus on the exception, the case that fits no flow and needs judgment.

It's not that they work faster doing the same thing: it's that they stop doing what should never have been their job.

This matters especially now that agentic AI has entered the conversation, because the question everyone worries about, "does this replace my team?", has a concrete answer here.

An agent that automates the transcript doesn't replace the academic records office: it frees it from issuing a thousand transcripts so it can attend to the thousand students. The agent can propose awarding financial aid to an at-risk student, but a person confirms the final decision, and a record is kept of who decided what and why.

The role doesn't disappear: it moves up a level, from processing to supervision and judgment. And that leap is only possible if there's a layer underneath that governs who can do what and leaves a trail of every action; something a patchwork of loose systems, each with its own permissions logic, can't offer.

Students, teams and leadership suffer the same problem… without knowing it

The broken experience students suffer and the manual workload teams carry aren't two problems: they're the same one, seen through two windows. Both stem from technology that was added piece by piece without a common plan and from a dependence on platforms the university doesn't fully control.

Students experience it as friction; teams, as overload; university leadership, as blind decisions and regulatory risk. Three symptoms, one cause.

That's why none of them can be fixed separately, and certainly not by asking the team to run faster or by adding one more tool to the patchwork. It gets fixed at the foundations: by regaining control of the data and of how the pieces fit together.

In the end, what's at stake isn't time, it's talent: what a team spends it on, whether fighting its own systems or serving the people the university exists for.

If leadership needed to know tomorrow how many students are currently at risk of dropping out, would the answer come from a system, or would someone have to cross-reference several spreadsheets to find out?

The answer to that question says more about how digital a university really is than anything you'll see on its website.