A personalised renewal-video flow for 3,000 members.

The scenario

A membership organisation has 3,000 eligible members and one renewal message recorded by its president. Each recipient should see their correct name and membership details without turning the campaign into 3,000 separate editing jobs.

The key risk is not visual variation. It is identity mapping. A wrong name, wrong file, or wrong delivery address would damage trust, so data validation and approval matter as much as rendering.

System design

The audience layer: An approved CRM export supplies only the fields required for personalisation and delivery. Duplicate records, missing names, invalid addresses, and opt-out states are checked before a render request is created.

The template layer: One master video leaves controlled zones for the member name and renewal details. Text limits, fallback rules, and sample renders cover long names and missing optional fields.

The delivery layer: Make could coordinate render status and place approved files in a delivery queue. The mapping between recipient ID, render ID, file URL, and email address remains traceable throughout the run.

Proposed pipeline

CRM export -> validation state -> Make -> Shotstack -> approved delivery queue

The under-24-hour batch window is a design target. It would need a volume test using representative records and the chosen renderer before campaign scheduling.

Operating model

Communications staff approve the message and the audience. A reviewer checks boundary cases and a representative sample before delivery is enabled. Failed or ambiguous records move to an exception view instead of being guessed or silently skipped.

Access to member data should be limited to the people and services required for the run. Retention, consent, deletion, and vendor-processing terms must be agreed before real records enter the system.