Implementation is where a client’s SOP becomes checks: a lead time becomes a date limit, a cap becomes a block, an approval path becomes routing. Map the SOP rule by rule, name an owner for each decision, then connect the systems and test real scenarios. The clearer those inputs are, the easier the setup is to approve.
Start with the client’s SOP, rule by rule
Take each rule in the SOP and write down three things: what it checks, when it should be checked, and how strict it is. A rule can block the step, warn the planner, add an approver, ask for proof, or monitor across programs. The SOP checklist lists the common rules agencies are asked to apply most often.
Pharmagin’s assistant can draft this map from the SOP document. Our team and yours confirm each rule before it goes live.
How the SOP becomes checks, on the AI page.
For each client and program type, document the information and documents teams must capture, the decisions that require approval, the responsible people or roles, participant-facing requirements, reports, source systems, approved data, mappings, and outbound activity.
Name the responsibilities
| Workstream | Client and agency inputs | Pharmagin implementation work |
|---|---|---|
| SOP rules | The client's SOP, in any format, and someone who can answer questions about it. | Map each rule to the moment it is checked and how strict it is, then confirm the map with you. |
| Event model | Event types, services, brands, lifecycle decisions, and required information. | Set up the program types and confirm what is in scope. |
| Roles and access | Users, organizations, territories, responsibilities, and approval owners. | Set up roles, permissions, and access. |
| Participant experience | Approved fields, copy, branding, domains, and communication requirements. | Set up registration, emails, surveys, and documents. |
| HCP data | The client's HCP sources, such as its CRM and target lists, the matches it accepts, and who confirms them. | Set up where HCPs are looked up, import the target lists, and agree how CRM changes are reviewed. |
| Data and integrations | Approved source objects, fields, credentials, mappings, and outbound permissions. | Find the fields, map them, test, and monitor each connection. |
| Spend and reporting | Budget context, expense choices, allocation rules, required views, and exports. | Set up budgets, reports, exports, and close requirements. |
| Testing and launch | Test users, sample scenarios, acceptance owners, and support contacts. | Prepare the environment, support testing, resolve agreed issues, and document launch scope. |
Six steps to launch
- Discover: map each client's SOP, then confirm program types, roles, HCP paths, data sources, reports, and decision owners.
- Configure: set up fields, approvals, templates, roles, financial context, and close requirements.
- Connect: review authentication, source schemas, mappings, allowed outbound activity, and virtual-attendance needs.
- Test: run real scenarios with sample or approved test data, including permission and exception cases.
- Prepare launch: confirm users, responsibilities, known boundaries, support paths, and the approved configuration.
- Review after launch: use feedback and monitoring to decide what to change in the setup.
The length of the plan depends on the number of clients, program types, and connected systems. We agree it with you before setup starts.
Test scenarios, not screens
Test each rule’s failure, not only its success: a date inside the lead time, a speaker over the cap, an HCP at the limit. Test the HCP data the same way: one HCP registered twice, a walk-in, and a correction that has to reach the client’s CRM. Include the expected approval path, missing information, speaker and attendee decisions, participant-facing journeys, in-person or virtual attendance, estimated and actual spend, role and organization access, integration dry runs, recovery, reconciliation, and the reports named in the acceptance criteria.
Settle the approval questions
- Who owns each program type and approval decision?
- Which choices are shared, and which remain client-, brand-, service-, or event-specific?
- Which data may enter or leave each connected system?
- Who can see financial, participant, speaker, and cross-organization information?
- Which exception scenarios must be demonstrated before launch?
- Which reports and exports constitute acceptance for each role?
- Who approves participant-facing copy, branding, domains, and messages?
- When the client’s SOP changes, who approves the change, and how do open programs follow it? SOP changes
Common questions
What do you need from a client to start?
The client's speaker-program SOP, its program types, the people who approve, and the systems to connect. The SOP can arrive in any format.
What happens to open programs when the SOP changes?
The change is made once. Open programs follow the new rules, and dates already approved stay as they are.