A client recently came to us with a request to collect post-event survey feedback from MSLs attending HCP speaker programs.
The proposed workflow was highly specific: once a rep completed an event attestation, the system would prompt them to indicate whether an MSL attended the program. If they selected “Yes,” additional dropdowns, notifications, and follow-up workflows would be used to route the survey request to the appropriate individual.
But before designing around the proposed solution, we stepped back to better understand the underlying business process.
The real question wasn’t simply how to send a survey. It was how MSL participation was actually being managed within the platform today.
Were MSLs already represented in the system?
How were they aligned organizationally?
How was their attendance currently being tracked?
Could multiple MSLs attend the same event?
And most importantly, what data needed to be reportable at the end of the process?
Those answers changed the direction.
Once we understood that MSLs were already participating operationally within events, we realized the cleaner approach was not to introduce entirely new attendee workflows, custom routing logic, or disconnected survey structures.
Instead, we focused on leveraging existing platform functionality and workflows that already aligned naturally with how these users were participating in programs.
We recommended using a dedicated Internal/MSL speaker type, allowing the platform to reuse existing event participation logic, survey delivery workflows, reporting structures, and Rep Portal access already built into Speakcore.
Operationally, these users would not behave like standard contracted speakers. But structurally, they could still leverage the same underlying framework—keeping the process clean, reportable, and scalable.
The result was a simpler solution that still satisfied the client’s goals: track MSL participation, deliver surveys only to those who attended, and make the resulting feedback reportable within existing event and speaker reporting structures.
The takeaway? Strong technology partners don’t just implement requests—they help uncover the real operational need behind them. The best solutions come from asking the right questions, challenging assumptions, and designing around how teams actually operate.
