PYLO Webinars
Webinar runs
A webinar planned end to end from your agent, with its timeline, its tests and the live board.
A webinar run is "a webinar for this client in five days" as one plan. Your agent asks the questions, PYLO checks each answer and dates every step from the start, and the whole build is approved once. Then each step is done by PYLO, by a step pack in your own browser, by the copy you approved, by a sequence, or by a person, and nothing counts as done until PYLO has read that it happened.
Starting one
Only an owner or an admin can start a run, and the workspace must be on the Pro plan. Ask your agent, for example "a webinar on Friday at 7pm London time on WebinarJam". It starts the run with plan_webinar_run and asks the intake a few questions at a time:
| Group | What it asks |
|---|---|
| When | The start, the time zone the copy uses, the zones you advertise, the audience's countries, how long it runs, and whether it is a new session of an earlier webinar |
| Who | The presenter and the moderator (two different people), and whether both have host access |
| Host | WebinarJam, Zoom, or Zoom with aEvent for evergreen |
| Offer | The promise, the mechanisms, the price and how it is said, the call to action, the guarantee, the real scarcity, the deliverables, and each bonus with the objection it kills |
| Proof | Case studies, each with the person's permission, and the lead magnet |
| Traffic | Organic, warm, cold or blended, and for paid traffic the budget, whether the ad account is warmed, and the creatives |
| Channels | The sending domain and its age, the WhatsApp number, SMS, and the DM tool |
| Sales | The CRM, the booking link and window, same-day slots, the qualification floor and the setters |
| Replay, bump, assets | A 72-hour replay room or none, a VIP bump, and which assets are made and by whom |
PYLO refuses what cannot be right (the same person presenting and moderating, a named result without permission, money in another currency) and says what each answer changes: a bank holiday in the audience's countries, sales calls on a weekend, a promotion window too short for the traffic, a booking window over three days.
The five-day substitutions
A webinar five days out cannot do everything a longer launch does, so PYLO applies these automatically and lists them. You can overrule any one, and your agent restores it when you change your mind.
- A new sending domain is not used: the host's own emails and an already warm platform send instead.
- A new WhatsApp number cannot be warmed in time: reuse a warm number or group, or run a thin flow.
- An unwarmed ad account runs no paid traffic.
- While WebinarJam has not approved API access, registration goes through your page and PYLO's registration flow.
- The YouTube runway, UGC videos, the order bump for organic or a one-off, and wallet passes are dropped; WhatsApp Phase 1 and the story calendar are shortened; the course emails are written after the event from its transcript.
The run page
Webinars, Webinar runs, then a run. It shows:
- Next: the one thing to do now, and who does it.
- Blocking: overdue steps that block the webinar, and failed guards.
- Timeline: every step with its due time in the copy's time zone, who owns it, how it happens and the read that proves it. A step ticked by a person but not yet proved shows as claimed. In a workspace in parallel mode, steps that would write to a client's tool show as held.
- Guards: the checks from real failures, such as the presenter link in anything a lead reads, a changed join link on a recurring webinar, tags without the date, missing SPF, DKIM or DMARC on the sending domain, the purchase pixel on the thank-you page, and stale links.
- Tech tests: each hop of the latest test, passed or failed with the evidence.
- Intake answers and the copy and sequences the run needs.
An owner or admin confirms a step only a person can do (rehearsing, going live, posting in the WhatsApp group). Steps due in the next day also open in your inbox and close themselves when they are done.
The registration flow
Sign-ups go through PYLO's registration flow: WebinarJam's registration, PYLO's own record, the GoHighLevel contact with its dated tag and the Close lead, each retried until it lands. Your agent sets it up from the chat with set_up_registration_flow once the WebinarJam session exists. PYLO finds the webinar by its name through WebinarJam's API, uses the dated tag, turns on the CRM steps the intake chose, and lets only your registration page post to it. It starts in shadow, where each step records what it would have written. Taking it live is hard to reverse, so a person approves it by code, and parallel mode still holds its writes.
There is no address to paste. The registration page already carries PYLO's capture snippet, so its form only needs the attribute the agent is given (data-pylo-registration with the flow's id), and the snippet posts each sign-up to the flow. There is no secret in the page. PYLO takes the post only from the flow's own pages, limits how many sign-ups one visitor can send, and counts the same email once a day. The post can do nothing beyond the flow's own steps. Once the plan is applied, PYLO sends one test registration down the snippet's path, in shadow, and reads it back. That is the step's proof.
A flow made by hand on the Webinar registration screen still uses its own address, minted there and shown once.
Testing
Your agent runs the tech test with run_webinar_test. A simulated test runs your registration flow in shadow and writes nothing. A live test needs a code sent to your own phone or inbox, and the test registrant is always you, with your own name and email: it cannot be pointed at anyone else. PYLO never makes a test booking in the client's calendar; it reads whether bookings arrive from integration health. The test registrant is left out of every count.
On the day and after
The live board (from the webinar's page) shows registrations, bookings since the start, applications, failed payments and whether each booking was triaged within 5 minutes, with the "NAME has booked" lines for the moderator. Every count comes from PYLO's own records.
After the event, Reconciliation checks every registrant across PYLO, the CRM and its pipeline stage, and the SMS platform. The tech test's registrant is left out, even a live test with your own email. Link audit reads every page and link for the session. The GoHighLevel workflow and the host's emails have no API PYLO can read, so a step pack in your own browser opens them and reads every link back, and the audit checks what it saw; until that run has happened, they are listed as not read, never as clean. Relaunch shows the next session's plan: each item is done by PYLO, a step pack in your browser, your approved copy, or a person, with the exact values.
The report
The Report (from the webinar's page, or get_webinar_report from your agent) is written without a spreadsheet. It reads thirteen figures top down, in the order a webinar is diagnosed: link CTR, opt-in rate, cost per registrant, the real paid show rate, retention to the pitch, the book rate on the pitch room, cost per booked call from paid direct bookings, booked to call taken, close rate, cost per close, cash return on ad spend, each ad's return, and the VIP take rate. Each figure shows what it was divided by. A figure PYLO cannot produce says why (attendance not imported yet, no pitch time set, spend in another currency) and never shows as zero.
Every booking since the start is tagged: paid direct, organic direct, a replay of the session before, a replay of an older one, or cold. Only paid direct and organic direct count for this session, and a booking three or more days after the start counts for the next one. Registrants, attendees, the show rate and bookings are split by organic, warm and cold traffic, read from each registration's UTMs.
The benchmarks and the "where to look first" line come from your agency's own template (its webinar section's report_benchmarks); with none set, the figures stand without a verdict. A paid show rate above 80% is flagged as a likely tracking fault whatever the benchmarks say. The words are your agent's: it drafts the narrative in the chat as a report, you approve it like any copy, and the report shows the approved version.