What a Saudi PSP Technology Demo Should Prove in 30 Minutes

What a Saudi PSP Technology Demo Should Prove in 30 Minutes

A patient support program technology demonstration is not a product tour. The purpose of a 30-minute PSP platform demo is to verify specific, Saudi-relevant capabilities under realistic conditions — not to watch a vendor navigate their most polished screens with pre-loaded test data.

Most Saudi PSP platform demos are vendor-designed and vendor-led. The vendor chooses what to show, in what order, and what to skip. A procurement team that accepts this structure will see the platform's strengths and nothing else. A procurement team that arrives with a structured evaluation checklist, specific scenarios to test, and mandatory requirements to verify will see something much more useful: how the platform actually performs against their specific program requirements.

This article provides a 30-minute structured demo script, identifies the five things a demo must prove for a Saudi PSP, and lists the questions that most effectively surface platform weaknesses.

---

Key Takeaways

• A Saudi PSP demo should be structured around your program requirements, not the vendor's standard product tour.
• Five things a Saudi PSP demo must prove: Arabic RTL patient workflow completeness, AE capture at every patient interaction, in-Kingdom hosting capability, PDPL-compliant consent architecture, and coordinators cannot close interactions without completing mandatory clinical steps.
• Demos run on sandbox environments with vendor-prepared test data are acceptable; demos run on live production data are not.
• Keywords are unvalidated editorial hypotheses (H); no search volume claims are made.

---

Why Standard PSP Demos Fail Procurement Teams

The standard 30-minute PSP platform demo follows a predictable structure: company overview (5 minutes), enrollment flow (5 minutes), coordinator workflow (10 minutes), reporting dashboard (5 minutes), Q&A (5 minutes). This structure is designed by vendors to present their platform's strengths. It typically omits:

• Arabic patient workflows entirely, or demonstrates them on a separate Arabic version that is visibly less complete than the English version
• Adverse event capture workflow — either shown as a simple text field rather than a structured workflow, or not shown at all
• Data hosting architecture — mentioned verbally but never verified in the demo
• Consent versioning and withdrawal — not shown because most platforms do not have this built out properly
• Error handling and mandatory step enforcement — not demonstrated because vendors prefer to show smooth, uninterrupted flows

A procurement team that accepts the vendor-designed demo structure is investing 30 minutes in a sales presentation rather than a technical evaluation.

---

The 30-Minute Structured Demo Script

Minutes 0–5: Setup and Requirements Statement

Before the demo begins, the procurement lead states requirements rather than accepts an agenda:

"We need to see five specific things in this demonstration. We'll direct the demo to these areas. Please have your sandbox environment open with a test patient in an enrolled but not yet activated state, and a second test patient mid-therapy at approximately month three."

The five requirements to state:

1. Complete Arabic RTL patient-facing workflow, end-to-end, on a mobile device
2. AE capture at a routine check-in — not enrollment, not a reported symptom, a routine scheduled contact
3. What happens when a coordinator attempts to close an interaction without completing the AE prompt
4. Data hosting location — in the platform configuration, not in a verbal response
5. Consent record for the enrolled test patient — the actual consent record showing what was consented to and when

This framing removes vendor agenda-setting for the first 5 minutes of the demo.

Minutes 5–15: Arabic Patient Workflow

Request the vendor to demonstrate the complete patient-facing Arabic workflow on a mobile device (phone, not desktop). The workflow should include:

Enrollment flow in Arabic:

• Patient receives enrollment invitation — in Arabic, as they would receive it in a Saudi program
• Patient completes enrollment steps — all steps, in Arabic, with RTL layout functioning throughout
• Patient completes consent — the consent notice in Arabic, with specific consent items visible

Watch for: Switching to English at any point in the enrollment flow; consent notice presented only in English; Arabic text that overflows, truncates, or displays incorrectly in RTL layout; steps that require the patient to interact with English-only interface elements.

Routine check-in flow in Arabic:

• Patient receives and opens a check-in notification
• Patient completes the check-in, including the health status question
• The session concludes

Watch for: AE prompt absent from the patient-facing check-in; health status question that cannot trigger AE capture; check-in that completes without asking any clinical question.

Minutes 15–22: Coordinator Workflow and AE Capture

Switch to the coordinator view. Request the vendor to simulate a routine scheduled phone contact with the mid-therapy test patient.

Step 1: Demonstrate the structured AE prompt

Ask the vendor to show exactly how a coordinator is prompted to ask about adverse events during a routine contact. Watch for:

• Is the AE prompt a mandatory step in the contact workflow, or an optional field the coordinator can skip?
• Does the prompt use clinical language that helps coordinators recognize AE expressions (not just "did the patient report a side effect" but a structured prompt that covers unexpected health changes, hospital visits, dose modifications, etc.)?
• What happens to the interaction if the coordinator enters only "no AE" without documenting the conversation? Can the coordinator close the contact?

Step 2: Demonstrate mandatory step enforcement

Ask the vendor to deliberately attempt to close the interaction without completing the AE documentation step.

This is the most revealing demonstration in the entire 30-minute session. Platforms with well-designed PV workflows prevent closure without AE documentation. Platforms where AE documentation is optional — or where the platform's data model treats the AE prompt as a text field rather than a structured step — will allow closure. The behavior in this test is a direct proxy for how the platform will perform during actual program operation.

Step 3: Demonstrate AE escalation

Enter a potential AE in the interaction (the vendor's sandbox should allow this). Ask the vendor to show:

• How the AE is captured with the minimum valid dataset
• How the AE escalation workflow is triggered
• What documentation the system generates for the sponsor's safety contact

Minutes 22–27: Data Hosting and Consent Architecture

Data hosting: Ask the vendor to show, in the platform's configuration or admin view, where patient data is hosted. A verbal answer ("our data is hosted in [country]") is insufficient — ask to see it documented in the platform.

If the vendor cannot show data hosting location in the platform interface, note this as an unverified capability.

Consent record: Ask to see the consent record for the enrolled test patient. This should show:

• When consent was given
• What specific processing activities the patient consented to (not a single "agreed" flag)
• In what language consent was presented

If the consent record is a single timestamp with no breakdown by consent item, the platform does not have purpose-specific consent capture.

Minutes 27–30: Q&A and Red-Flag Identification

Reserve the final 3 minutes for two specific questions:

1. "Show us an example of a reporting export for adverse event reconciliation — the data we would use to reconcile against our global safety database." If the vendor cannot produce this in the demo or describes it as a custom development item, AE reconciliation reporting is not a standard platform feature.

2. "What does the coordinator see if they receive a potential AE report outside of a scheduled interaction — for example, a patient calls the coordinator directly?" This tests whether AE capture is embedded only in scheduled interaction workflows or is accessible from any coordinator contact type.

---

Five Non-Negotiable Demo Requirements for Saudi PSPs

If a platform demo does not demonstrate these five capabilities, the platform should not proceed to shortlisting regardless of its performance on other dimensions:

1. Complete Arabic RTL patient workflow — enrollment through ongoing check-in, in Arabic, on a mobile device, with no English-only steps and no layout failures.

2. Mandatory AE prompt at every interaction — the platform enforces AE capture at every patient contact, including routine check-ins, and prevents coordinator closure without documented AE status.

3. Data hosting documentation — in-Kingdom hosting capability can be verified in platform configuration or admin documentation, not only verbally.

4. Purpose-specific consent records — the consent record shows specific processing activities consented to, with timestamps and version tracking.

5. AE reconciliation reporting — the platform generates structured, exportable AE reports in a format that supports reconciliation with the sponsor's global safety database. [HOLD — expert review: specific AE reconciliation format requirements require PV professional guidance]

---

FAQ

Can we demand a demo on live production data? You should not. Demos on live production data risk exposing other sponsors' patients' data to your evaluation team, which creates PDPL and confidentiality issues. A well-prepared sandbox with realistic test scenarios is the appropriate demo environment. What you can demand is that the sandbox demo uses the same platform code that runs in production — not a specially prepared demo version.

What if the vendor says the Arabic workflow requires a separate demo session? This is a red flag. Platforms that cannot demonstrate their Arabic patient workflow in the same demo session as their English coordinator workflow are signaling that the Arabic version is a secondary product, not an equal capability. A Saudi PSP requires full Arabic capability; a platform that separates Arabic from its standard demo does not meet this standard.

How should we score a demo that is smooth overall but fails on AE enforcement? AE workflow enforcement is a mandatory requirement, not a scored dimension. A platform that demonstrates a beautiful enrollment flow, excellent Arabic UX, and a clean reporting dashboard but cannot prevent coordinator closure without AE documentation should be eliminated from consideration. Pharmacovigilance workflow integrity is not a weighting-system input — it is a threshold. [HOLD — expert review: specific PV workflow requirements require PV professional guidance]

Can we ask vendors to run the demo script themselves without procurement team direction? The 5-minute requirements statement at the start of the demo — where your team specifies exactly what must be demonstrated — is not negotiable. Without it, the demo defaults to a vendor product tour. The purpose of the scripted requirements is to shift control of the demo agenda to the procurement team. Vendors who object to demonstrating the five mandatory requirements are signaling an inability to meet them.

What if the vendor's sandbox does not have all the required test scenarios set up? A vendor who arrives to a sales demo without a sandbox environment configured for their target market's specific requirements — Arabic workflows, AE capture, Saudi-relevant therapy scenarios — has not prepared adequately for a Saudi PSP procurement process. This preparation gap is itself evaluable information.

---

Published: 2026-11-05 · Author: CareSync Team · This article provides general guidance on evaluating PSP platform technology demonstrations for Saudi patient support programs. It does not constitute legal, regulatory, or medical advice. All pharmacovigilance requirements should be evaluated with qualified PV professionals.

---

Prepare your PSP demo evaluation with CareSync's checklist. Download the demo evaluation guide →