Choosing RTSM? Evaluate the Team Running It, Not Just the Software

 When Sponsors evaluate RTSM software for their clinical trial, early conversations tend to center on platform features, timelines, and cost. Those things matter, and they should. But they are only part of the decision. 

What often gets less scrutiny is the depth of experience behind the team that will run the system once the study is live. How well they understand RTSM, how fluent they are in the platform they support, and whether they can guide decisions when things change. 

Clinical operations teams are not just buying software. They are choosing the people who will help design the system, manage amendments, and support the study over time. That experience, or lack of it, often has more impact on trial execution than the platform itself. 

The challenge is that it is not always obvious what to evaluate before kickoff. This is where many Sponsors later wish they had asked different questions. 

The Hidden Risk: Inexperience at the Helm 

 Even when an RTSM platform is solid, the team running it may not fully understand RTSM or their own company’s system. Many project managers assigned to trials are still learning clinical operations, regulatory expectations, and how the platform actually behaves across different study designs. 

This is not always obvious at the start. 

The real issue shows up when decisions need to be made. If PMs do not know the platform and have not seen hundreds of protocols across different systems, they lack perspective.

Without that reference point, they cannot guide Sponsors toward proven approaches or flag risks early. Instead of advising on setup options or recommending safer patterns, they end up documenting requests and passing them along.

One Sr. Clinical Trial Manager described what this looks like in practice:

“There was really only one person I trusted to answer questions [at the vendor], because I didn’t feel confident that anyone else actually knew the RTSM system well enough to give me an accurate answer.”

That gap in experience often leads to poorly designed, one-off solutions instead of time-tested patterns. That increases rework, slows amendments, and raises risk.

A Senior Director of Clinical Operations echoed the same frustration:

“If we ask a question, they should be able to confidently answer what can and cannot be done. That was something we struggled with before.”

The risk usually is not the software itself. It is what happens when the person managing it cannot speak confidently about how it works, what it supports, and how to use it well. In those situations, the project manager becomes a note taker instead of a value-add expert, and Sponsors lose the guidance they actually need when trials change.

Why Continuity Gaps in RTSM Project Management Put Clinical Trials at Risk 

If project managers are so important, why does their involvement sometimes feel inconsistent? 

Part of the answer lies in how RTSM service models are built, especially within larger organizations. 

Many large vendors rely on segmented teams and layered communication. While this may help manage volume, it can slow things down when continuity matters most. 

In these setups, it’s common for project assignments to unexpectedly shift mid-study. When that happens, Sponsors end up re-explaining decisions, study details, and previous issues. Over time, this slows momentum and creates frustration. 

A model built to support scale can easily introduce the inconsistencies it was meant to solve. 

Continuity Isn’t a Luxury. It’s a Safeguard. 

RTSM systems are designed to support control, visibility, and compliance across the study. But when the project team lacks continuity or clinical fluency, that stability starts to erode. 

Outside of the RTSM system’s technical limits, the difference between a quick amendment and a six-week delay often comes down to whether the project manager understands the protocol and has authority to act. Vendors that treat project managers as interchangeable don’t just slow things down. They add risk. 

And when a study shifts, which it will, the ability to respond without causing new problems depends on whether the same team that built the system is still guiding it. 

Your Project Team Sets the Table for Change

In theory, almost anything can be built in an RTSM system. A project manager can write down a requirement, hand it to engineering, and get it programmed. The problem is not whether something can be done. It’s whether it should be done, and whether it can be changed later without creating risk.

RTSM exists for a very specific purpose: managing treatment assignment and supply. Both EU regulators and the FDA expect these systems to stay tightly scoped to those functions. When RTSM is stretched to support logic or workflows that belong elsewhere, even if they “work,” it starts to raise red flags.

This is where inexperienced teams get Sponsors into trouble. A PM may dutifully capture a request and turn it into a custom build inside the RTSM, even when that requirement should never have lived there to begin with. Those one-off implementations are often hard to amend, hard to explain during inspection, and quick to draw scrutiny when regulators review how the system is being used.

What looks like flexibility early on can turn into risk mid-study.

Supporting real-world trials means assuming change will happen while staying within the boundaries regulators expect. That requires more than responsive project management. It requires a platform and delivery approach built around standardization, reuse, and time-tested patterns that have held up across audits and amendments.

At Korio, system design decisions are made with future change and regulatory expectations in mind. The goal is not to say yes to every request, but to propose solutions that meet the study’s needs without misusing the RTSM or creating logic that becomes brittle later. Strong platform standardization makes this possible, and experienced project managers know when to guide a Sponsor toward a better approach rather than forcing everything into the system.

This is how repeatability is proven. Not by building whatever is asked once, but by designing solutions that can be reused, amended, and defended over time.

The brilliance is not just getting the system live. It is making sure it can change again, and again, without becoming fragile, slow, or problematic under regulatory review.

When Selecting RTSM Software, Check the Team as Well as the Tech 

RTSM selection often centers on software features. For Clinical Operations teams, careful evaluation should also focus on the service model, especially the people running your trial. 

Use this checklist to assess whether a vendor is prepared to support your study: 

Team Continuity 

• • • Will there be continuity within the project management team from kickoff through closeout? 
    • How many years of IRT/RTSM experience does the PM have? 
    • How many years of clinical research experience does the PM have? 

Relevant Experience 

• • • Has the PM worked on trials with study designs similar to yours? 
    • Do they understand your study’s operational needs?

Strategic Ownership 

• • • Can they escalate and resolve issues quickly? 

When Trials Change, People Make the Difference 

Great technology helps, but RTSM is more than software. It’s a service that supports patient safety, supply management, and compliance. It needs knowledgeable operators, not just licenses and logins. 

As trials shift, with amendments and delays becoming standard, vendors need to adapt. That adaptability doesn’t come from code alone. It comes from having the right people in the right model with the room to act. 

Final Thoughts: How Korio Solves What Others Create 

At Korio, we’ve shaped our RTSM approach to remove the problems many Sponsors face. That begins with people. 

Every client is assigned a dedicated, experienced project management team who stay with the study from kickoff to closeout. If a change is needed, backup team members already familiar with the trial step in without disruption. 

Our internal structure removes silos and supports faster, more accurate collaboration across engineering, testing, and client services. 

Our technology supports this model by using standard patterns, automation, and repeatable processes so our team can focus on thoughtful decisions instead of firefighting. 

We also follow a risk-based onboarding model so every study gets focused attention from the start. 

If it feels like you spend too much time managing your RTSM vendor, it may be time to expect more.  

Let’s talk about how Korio can give your trial the continuity, expertise, and flexibility it deserves. Schedule an intro call here.