Closed Ticket, Open Problem: How Vendor Handoffs Keep Becoming Site Work

A participant calls the site because a reimbursement hasn’t arrived.

The coordinator knows the visit happened. They might even remember the participant submitting a receipt. None of that means they can see where the payment sits, who’s reviewing it, or whether something else is holding it up.

But they still get the call, because the participant knows the coordinator. The coordinator understands the study and can tell whether an unresolved payment might affect the next visit. So the site becomes the natural place to ask, even when another company owns the answer.

One reimbursement question can turn into several emails and a search through old study materials. By the time someone responds, the coordinator may also need to call the participant back and explain what happens next. At that point, the site’s doing the follow-up the handoff was supposed to prevent.

Why questions keep coming back to the site

Participants experience one study. They rarely know which provider handles travel, which system processes payments, or which support contact owns a particular request. Those distinctions may be perfectly clear behind the scenes. They mean very little to someone trying to get to an appointment or recover money they’ve already spent.

The site’s usually where the relationship lives. Coordinators know the participant’s history and understand the visit schedule. They can recognize when a support issue is becoming a study issue. That context makes the site valuable—and the coordinator the default interpreter for every process surrounding the study:

• A participant may contact a payment provider directly and return to the coordinator when the answer is unclear.
• A travel problem may belong to another team, but the site gets involved because the change could affect a visit window.
• An app may have its own help desk, though the participant feels more comfortable calling someone they already know.

Before the question is resolved, the coordinator may have translated it across several contacts the participant never knew existed.

A handoff should move the responsibility

Telling a participant to contact another inbox may move the question, but it doesn’t always move the work. A usable handoff gives the next person enough context to act without making the participant start over. Once the issue leaves the site, coordinators should not have to keep checking whether someone responded. Ownership also needs to remain clear when more than one provider is involved. A handoff has failed when the contact changes but all the work stays with the site.

Consider the reimbursement question. The coordinator sends the participant to a payment contact and considers the referral complete. Two days later, the participant calls again without an answer. Now the site has to find the original request, explain why it matters, and report back. That’s just a referral followed by site-managed follow-through.

A real handoff would work differently. The coordinator would send the issue to a known owner with the relevant context attached. That team would communicate directly with the participant and confirm when the matter had been resolved. The site could remain informed without becoming the tracker.

What completion looks like from the site

Receipt’s in. Ticket, closed. But hey, the participant still hasn’t been paid.

Operational reporting usually captures what happened inside a particular workflow. Site staff deal with what happens between workflows. Closing a ticket can still send the coordinator back to email. A transfer may be complete on paper while the participant remains unsure whom to contact next. Even an on-time request can take too long to ease the expense that prompted it.

Coordinators also hear what the status fields miss. They know the participant has asked for an update twice. Another visit is approaching, and now the participant wants to know whether it will mean another out-of-pocket expense.

Site staff search for the correct contact and forward old messages. They interpret answers from systems they cannot always access. Until another team resolves the issue, the site manages the consequences. The coordinator remains accountable to the participant, even though another team controls the outcome.

What sites need before enrollment begins

Support responsibilities are often presented during startup as separate services. Sites also need to understand what happens when an actual participant question crosses the boundaries between them. A directory of names and email addresses won’t answer that. Before enrollment begins, sites should be able to ask:

• Who owns an issue until the participant receives an answer?
• After the site hands it off, who follows it through?
• Can coordinators see whether an open issue has moved forward?
• Who contacts the participant when several providers are involved?

The answers reveal whether the support process has been built around actual use.

Sites also need a clear escalation path. “Contact support” doesn’t cut it when a missed payment or changed itinerary could affect the next visit. Staff need a named escalation contact and a clear definition of what counts as urgent. They also need to know when an update will come.

This information belongs in startup materials and SIV conversations. Otherwise, site staff learn the process by chasing down problems.

The site can still be the trusted contact (without becoming the help desk)

Participants may continue to call the site first. That’s fine; the relationship is valuable and unavoidable. A functioning support process makes the call straightforward for the coordinator to resolve. Site staff know where the issue belongs and can transfer it without reconstructing the vendor structure. The participant reaches someone who already has enough context to help. The coordinator can see when the matter has been handled.

Before support goes live, every process should make two things explicit. Someone must own the issue until the participant gets an answer. The site needs a reliable way to confirm that the issue has been resolved. Sites can test the process with one question: After we hand this off, who owns it until the participant gets an answer?

When nobody can answer clearly, the process isn’t ready for participants or the site teams they’ll call.

---

Eva Wilson is a Content and Communications Strategist at Scout focused on clear messaging about the decisions and operational realities that shape clinical research.