Your New Portal Just Became Someone Else’s Extra Job

The demo looks great. One dashboard. Everything in one place. Fewer emails.

Then the coordinator gets the invitation, creates another password, completes the training, and discovers that the same information still needs to go into the other system.

Somewhere, a process became more efficient. It just may not have been theirs.

I come from software, so I understand the appeal of building a tool for a problem. I also work in research site operations. That makes me interested in what happens after the product demonstration, when the person using it has a participant waiting and a phone ringing.

A clinical trial portal should earn its place in that person's day.

Follow the task all the way through

Imagine a site entering its recruitment update into a sponsor portal. The CRO still needs a spreadsheet. The internal team needs its own tracker. A weekly email asks for a narrative explanation of the numbers.

That is an illustrative workflow, but the question it raises is very real: which step did the new system remove?

If the answer is none, we should be honest about what we introduced. Perhaps the portal improves oversight, standardization, or visibility across sites. Those can be worthwhile benefits. They still come with a workload that someone needs to recognize.

The mistake is announcing a time-saving tool without asking whose time it saves.

The sponsor's view matters, too

A sponsor trying to understand enrollment across many sites cannot run an entire study through scattered email threads. A consistent system can make missing information easier to spot and questions easier to route.

Sites also have responsibilities here. We cannot ask for fewer follow-up emails while leaving agreed updates incomplete. A shared process only works when people use it reliably.

But reliability gets harder when ownership is unclear. Is the portal the official update? Is the spreadsheet? If they disagree, which one should the team fix first?

Those decisions belong in implementation planning. Asking a coordinator to work them out after launch turns a design problem into a daily interruption.

Test a normal Tuesday

Before rolling out another research site system, I would ask a coordinator to walk through one ordinary task from start to finish. Use a realistic example with no participant information. Include the awkward parts: a missing field, a correction, a colleague covering an absence.

Watch the whole process. Count the handoffs, not just the clicks inside the new product.

• Name what goes away. Retire a duplicate spreadsheet, email request, or entry step where the study's requirements allow it. Put that decision in writing.
• Make ownership clear. Identify who enters information, who reviews it, and where the team should look for the current answer.
• Plan for ordinary problems. Access failures, staff changes, and corrections need a usable support path. A help button is not the same as a resolved issue.

Then return after the team has used it for a few weeks. Ask what still happens outside the system. That is often where the unfinished design work is hiding.

Give the benefit a fair test

I would measure total time to finish the task, duplicate entry, and unresolved support requests. I would also ask one plain question: would the coordinator choose to keep this tool?

Not every answer will be yes. Sometimes a system supports a necessary study requirement even when it adds work. In that case, explain the reason and resource the work honestly. People can handle a real tradeoff better than a promise that does not match their day.

For me, the best product conversation starts with curiosity. Show me where you get stuck. Show me what you have to copy. Show me the workaround you made because the official process did not quite fit.

That is useful information, not resistance to change.

Which task would you remove before asking a site to adopt another portal?

Enmanuel CorvoEngineer. Site leader. Always learning.

I write about the practical work behind clinical research and what sites, sponsors, and CROs can learn from each other.

Share your perspectiveAll perspectives