AI Lives and Sells for You 24/7: New Free Auto-Webinar Feature for LINE Harness

AI lives and sells 24 hours a day.

Last night, a "live broadcast" was running on my LINE. In the comments section, messages like "Watching from Osaka!" and "I want to book a consultation" were flowing, and the broadcaster was picking them up and answering. A button appeared at the bottom of the screen, and the slots for individual consultations were being filled by people who pressed it.

Wait, that was a recording. The comments were also scripted.

Are you put off? But in the video, the broadcaster themselves reveals the secret: "This live is recorded. The live heat you were feeling just now was all by design." The viewers realize that the experience they thought was live was actually a product demo. This entire structure is the product.

What is an "Auto-Webinar" in the first place?

In short, it's a system that automatically holds live broadcasts, attracts customers, and builds sales leads (business meeting leads) even while I'm sleeping or playing.

Even while sleeping, the live broadcast sells for you.

The true identity is "turning one recording into a pseudo-live." You record one serious live session. After that, that recording continues to be held automatically as a "live" at scheduled times. From the viewer's perspective, it's a genuine live experience that starts in real-time at a fixed time, comments flow, the broadcaster picks up and answers comments, and it ends as a one-time event. But the broadcaster is not behind the screen.

Even while playing, customer attraction doesn't stop.

Both customer attraction and sales are unmanned. An automatic guide is sent to people who add you as a friend → They choose the session they want to attend and a reservation is made → A reminder arrives 5 minutes before the start → The live starts → Product information appears in sync with the flow of the talk → The application form is completed without stopping the video. During that time, I'm sleeping, playing, or doing other work. All I get on my smartphone are notifications saying "A reservation has been made" or "A form response has arrived."

10 times a day, it holds sessions and attracts customers automatically.

At our place, 10 live sessions are automatically set up every hour from 9:00 AM to 6:00 PM. If a human did it live every time, their throat and sanity wouldn't hold up, but since it's a recording, the energy is 100% every time. Even someone who thinks of it in the middle of the night can book the "9:00 AM session tomorrow" and go to sleep.

Conventional Webinar vs. Auto-Webinar

In essence, it means continuing to rebroadcast the day the live went best, 10 times every day. This mechanism has been implemented as a new feature of LINE Harness, an open-source project I am creating. In other words, it can be used for free. From here, I will show you exactly how to make it.

Here are the actual measurements for one full day since release:

Link clicks: 330 → Session reservations: 166 (50%) → Viewers: 146 → CTA clicks: 66 (45% of viewers) → Consultation leads: 14 (including 2 CEOs with annual sales exceeding 100 million yen)

Zero advertising costs, almost zero delivery server costs, and zero human labor on the day. This article fully discloses the contents, from how to place recordings to preventing rewinding, reservations and reminders, CTA design, analysis, and emergency stop procedures, based on the 15,000-character practical guide I have on hand.

If you want to experience the real thing first, click here. When you add as a friend, a guide will be sent to LINE and you can choose the session to participate in👇

https://line.the-harness.com/x-autowebinar

I have attached "work prompts that can be pasted directly into AI" to each chapter. If you are using Codex or Claude Code, you can proceed with the construction by replacing the content inside 【 】 with your own environment and pasting it. It's a very long text, so bookmarking is recommended.

5 Design Principles

5 Design Principles to Grasp First

If you make it without knowing these five, it will usually just become "distributing a recording URL."

1. Simply splitting into HLS does not prevent rewinding. Only by combining server-based mid-participation seconds, EXT-X-START, sealing the seek bar, and 5-second drift correction does it become a "live that cannot be rewound."
2. Do not use the viewer's device clock as a reference. Only the server decides "what second it is now." The device just adds the monotonic elapsed time after reception. Even if the device's clock is wrong, the position will not shift.
3. Place videos in R2 and deliver via a short-lived HMAC-signed Worker URL. Do not directly paste public R2 URLs into teaching materials or LINE.
4. LINE transmissions, including reservation confirmation, pre-start notification, and follow-up, must pass through a transmission path that remains in the logs. A system where you cannot investigate "it should have been sent but didn't arrive" will get stuck once operation begins.
5. Do not confuse basic features of the OSS version with production-ahead features. Check the commit and DB migration you are using before setting up.

Chapter 1: The Finished Form and the Overall Map

A single line of flow from application to follow-up.

First, the finished form. The flow from the viewer's perspective is as follows:

Choose a session to participate in → Reservation confirmation arrives on LINE → Viewing link arrives on LINE 5 minutes before start → Waiting room 10 minutes before start (pre-start comments start flowing) → Pseudo-live viewing (shill comments + your own comments) → CTA cards flow in sync with the talk → Form response without stopping the video → Tagging → Follow-up scenario triggered → All actions recorded in DB

There are only 5 pieces of infrastructure on the back end:

Auto-Webinar Delivery Architecture

• Management Screen — Create/schedule webinars, edit comments/CTAs, analysis.
• LIFF — Viewing page that opens inside LINE. Friend identification is done here.
• Cloudflare Worker — Determination of whether it's being held, signed URL issuance, all APIs.
• R2 — Video storage. Zero transfer fee.
• D1 — Recording of reservations, viewing positions, comments, and CTA clicks.

No servers are built. Everything runs on Cloudflare's edge.

To be honest, there is a difference between the OSS version of LINE Harness and the production version I am operating ahead of time. Basic management screen, schedule, HLS/R2 delivery, heartbeat, comments, basic CTA, and analysis are in the OSS version. Multiple CTA cards, in-page forms, session reservations, 5-minute pre-LINE notifications, participant gates for registrants only, EXT-X-START correction for iOS, and management previews are ahead in the production version and will be released to OSS sequentially.

So the first task is an inventory of "what is in your environment." Please paste the following into the AI.

Please inventory the current LINE Harness auto-webinar implementation without changing it. 1. Check Git repo, branch, commit, origin/upstream, and unsaved diffs. Do not touch diffs. 2. Read management screen sidebar, webinars page, Worker's webinars route/client, DB's webinar migration, Cron and reminder service, and R2 binding. 3. Categorize the following into "Implemented / Partially Implemented / Not Implemented": Management screen CRUD, HLS/R2, signed URL, holding determination, reservation, waiting room, mid-participation control, LINE notification, comments, CTA cards, inline forms, tags, scenarios, analysis, preview. 4. Create a table of the flow from application to follow-up with "Screen / API / D1 table / External service / Symptoms upon failure." 5. Do not implement missing features on your own; show the order for safe addition, necessary migration, test, and rollback, and wait. Do not display secret values; report only the current feature table and the first operation.

Completion check: Confirmed the commit in use / Distinguished between OSS and production-ahead features / Can explain the flow of screen, API, DB, and R2 / Did not misidentify missing features as "configured."

Just turn the video into HLS and place it.

Chapter 2: Converting MP4 to HLS and Delivering from R2—The Truth Behind ¥0 Delivery Costs

One MP4 is split into 6-second fragments (425 for a 21-minute video), and different qualities like 1080p, 720p, and 480p are prepared. This is HLS, and YouTube and Netflix are the same inside. The master playlist (master.m3u8) selects the quality, and the playlist for each quality shows the sequence of segments. For viewers with weak connections, low quality is automatically selected, so it won't stop even on a train.

The advantage of HLS is that instead of making them download a 2-hour video in its entirety, you can retrieve only the small area around the position currently being viewed. However, let me warn you first: simply making it HLS does not prevent rewinding (this will be solved in Chapter 3).

The storage location is Cloudflare's R2. This is the financial core of this configuration.

• Zero transfer fees. The scariest thing about video delivery is the bandwidth cost, but no matter how many people watch, it's ¥0.
• Storage fee is 1-2 yen per month for 21 minutes and 700MB.
• Even if 1,000 people watch in full, the read fee is only a few dozen yen.

People paying tens of thousands of yen a month for webinar SaaS should have gotten their money's worth from this paragraph alone.

Three practical points of caution:

• If the original video is 720p, do not create 1080p. Upscaling only doubles the capacity and doesn't improve the quality by even a millimeter.
• Always verify which Cloudflare account is connected before uploading. A classic accident is the tool's configuration file pointing to a different account resulting in a 403 (I've lost once to this too).
• Do not place videos at public URLs. The Worker issues a short-lived HMAC-signed URL, and playback is only possible via that.

Prompt to paste into AI:

Convert this video into HLS for LINE Harness auto-webinar and first place it in the verification R2. Do not upload to production before approval. 【Absolute path of input MP4】【webinar slug】【Verification Cloudflare account】【Verification R2 bucket】 1. Read scripts/encode-webinar.sh and wrangler settings in apps/worker to decide the actual command. 2. Check duration, codec, resolution, frame rate, and audio channels with ffprobe. 3. Check wrangler whoami, account ID, and R2 bucket list in read-only mode, and stop if it differs from the specified environment. 4. Convert with 1080p/720p/480p, 6-second GOP, HLS VOD, and complete playlist. If the original is less than 1080p, show a change plan to avoid unnecessary upscale. 5. Locally verify master.m3u8, each index.m3u8, first/middle/last segments, duration difference, audio, and quality switching. 6. Show the number of objects to be uploaded and the approximate total capacity and wait for my approval. 7. After approval, save m3u8 as application/vnd.apple.mpegurl and ts as video/mp2t. 8. Confirm that master, variant, and segment return 200 via the Worker's signed asset route. 9. Report the video prefix and duration seconds to be entered into the management screen, and the R2 deletion procedure. Do not publish to production yet.

Completion check: Generated master playlists for 3 qualities / Keyframes are aligned in 6-second units / Placed in the correct R2 / Playback was possible via signed Worker.

No rewinding allowed.

Chapter 3: Maintaining Mid-Participation Position and Preventing Rewinding

The lifeline of a pseudo-live is here. Whether you reload, open on another device, or return from the background, it must always be played from the "now" position. If it breaks even in one place, it's exposed as "just a recording."

The time reference is the server. The Worker returns "how many seconds have passed since the start of the session (offsetSeconds)," and the device just adds the monotonic elapsed time after reception (difference in performance.now()). Even if the viewer's device clock is off by 5 minutes, the position will not shift, and there's no need to query the server every second.

And the thing I got stuck on most this time was the iPhone. The in-app browser of LINE sometimes ignores seek commands (assignment to video.currentTime) from JavaScript and rewinds to 0 seconds. No matter how many times I retried on the client side, it didn't fix it.

The answer was a change in perspective: "Stop commanding the player and have the delivery data itself declare the starting position." At the start of viewing, append "?at=current second" to the playlist URL, and the Worker dynamically injects the HLS standard #EXT-X-START tag into the master and variant playlists. The player treats that as the "starting point," so it's not a seek, and there's no way to refuse it. It fixed everything on all devices instantly.

In summary, a pseudo-live is established with a set of 4 items:

• Server-based offsetSeconds — Only the server knows the truth of the position.
• EXT-X-START injection — The delivery data declares the starting position (the main solution for iOS).
• No seek bar — No controls. Only the management can check at double speed from 0 seconds with ?preview=1 (without messing up analysis).
• Every-second drift correction — If it drifts by more than 5 seconds, force synchronization to the live position. Re-sync when the tab returns. Automatic playback recovery for temporary stops caused by the system, such as removing AirPods (there is no pause in live).

Prompt to paste into AI:

Verify that the LINE Harness auto-webinar does not rewind to the beginning upon mid-participation or reload. First read existing code and tests, and propose minimal fixes only if broken. 1. Read webinar-schedule.ts, asset processing of webinar route, worker-internal webinar client, and related tests. 2. Specifically explain the relationship between session start, server now, offsetSeconds, and performance.now at the time of API reception and the expected playback position. 3. Clearly state that HLS splitting alone does not prevent rewinding, and create a table of responsibilities for controls, EXT-X-START, currentTime, drift correction, visibilitychange, and pause recovery. 4. Check just before/just after start/middle/just after end, daily/weekly/once, and JST boundaries with unit tests. 5. Confirm with asset tests that ?at propagates to the variant URI of the master, and EXT-X-START enters the master and variant once. 6. Create a verification session and participate from iPhone LINE, Safari, Android LINE, and Chrome 10 minutes after start. Record if it returns to within a 5-second tolerance after reload, 10-second background, pause equivalent to AirPods, and network switching. 7. If production changes are needed, show the cause line, minimal diff, test, and rollback and wait for approval.

Completion check: Server offset is the time reference / EXT-X-START enters m3u8 / Drifts over 5 seconds are corrected / Confirmed on actual devices including iOS LINE in-app browser.

Reservation → Reminder → Entrance Gate

Chapter 4: Reservations, Waiting Rooms, and LINE Reminders—Automating "Gathering"

If you send the recording URL as is, it ends with "I'll watch it later." Make them choose a time, make a promise, and remind them just before. This is the dividing line for the participation rate.

Make it an hourly session (we have 10 times/day from 9 AM to 6 PM) and let the viewer choose a session. The moment they choose, a registration confirmation arrives on LINE, and a viewing link is pushed 5 minutes before the start. In actual measurements, 50% of clicks proceeded to reservation.

What works in implementation are the mundane parts:

• Reservations are only accepted for "future sessions that actually exist on the schedule." Refuse non-existent times or past times.
• Even if the same person reserves the same session twice, it becomes one entry due to the DB's unique constraint.
• Reminders are sent only once. Since it uses a method of competing for a "notified" mark before sending (only the process that gets it sends), it won't become two messages even if cron runs twice.
• Do not send to friends who have blocked you.
• All transmissions pass through a path that remains in the management screen's message log.

People start gathering 10 minutes before the start.

10 minutes before the start, the viewing page changes to a waiting room. Under the countdown "The broadcast will start in 4 minutes and 32 seconds," comments already start flowing—"First time participating!", "I flew here because I got the notification", "A little over 3 minutes left." Create an atmosphere where people are in the venue before it starts (pre-start comments are just registered with negative seconds for the comment. -180 for 3 minutes before start).

And I prohibited mid-participation. For people who come during the live, "Currently broadcasting / Mid-participation in this session is not possible" is displayed in gray, and they are guided to reserve the next session. This is both to prevent disillusionment and to ensure "everyone reaches the CTA from the beginning," and the fact that they can't enter itself becomes evidence of the live feeling. The only exception is if the person who reserved that session arrives late (shutting out registrants is counterproductive).

Prompt to paste into AI:

E2E confirm auto-webinar reservation, waiting room, 5-minute pre-LINE notification, and participant gate for registrants only in the verification environment. Do not send to actual customers. 【Your verification LINE friend】【Verification webinar slug】【Verification session date and time JST】 1. Read reservation migration, registration DB function, register API, reminder service, Cron caller, and LINE transmission service. 2. Create the verification session as a near once session that can be confirmed from now. Present the target account, LIFF ID, timezone, and duration and wait for approval. 3. Reserve a future session from your LIFF and confirm that the DB has one entry even if the same reservation is sent twice. Refuse non-existent times and past times. 4. Confirm that the registration confirmation reaches only you and remains in the management screen's message log. 5. Confirm that it's a waiting room 10 minutes before start, a reminder target 5 minutes before start, and only the person who reserved becomes "joined" after start. 6. Confirm that reminders are not sent twice even if the process is re-executed. 7. Test unreserved, different session reservation, blocked, LINE API failure, and failure before DB update. 8. Report the created verification data, number of messages received, message log, participation eligibility, and deletion method.

Completion check: Only future existing sessions can be reserved / Identical reservations are one entry / Pre-start notification is only once / All LINE transmissions are logged.

The flow of "Choose session → Reservation confirmation → 5-minute reminder → Waiting room" is faster to touch than to read. Experience it here👇

https://line.the-harness.com/x-autowebinar

CTA design with zero drop-off.

Chapter 5: Comments, CTAs, and Forms—Why 45% of Viewers Pressed the Button

Comments can all be made with AI. However, if you just generate them, it will be exposed instantly. This is because there are rules in the comment section of a human live broadcast. I will write down all the generation rules we use:

• The "I'm in Osaka" that the broadcaster reads out must have flowed a few seconds before the reading, or it's strange. Match it second by second with the transcription.
• Answers to questions start flowing with a delay for input time (around 10 seconds). Instant replies are unnatural.
• Mix in 10-20% of comments that are ignored by the host. Greetings, mid-participation reports, small talk, and questions that can't be answered. A comment section where everything is picked up is fishy.
• Include a few places where viewers who like to teach answer other people's questions from the side ("Mr./Ms. XX, that means... you know").
• Do not include soliloquies like "Ah, I see." Soliloquies almost don't exist in live comment sections. This is usually the true identity of AI-smell.
• Names are slightly mutated from actual friend lists and used after mechanical verification that they do not match any actual person.

When you transcribe the actual broadcast audio and have AI generate it with these rules, 128 comments for 21 minutes are ready in a few minutes.

CTAs are synchronized with the speech. The moment you say "I think a button has appeared at the bottom of the screen" in the recording, a CTA card flows into the chat section. Since the speech and the screen are perfectly synchronized, the viewer's experience is "I was just guided live."

The final guidance is set to auto-open, switching the entire chat section to the application form without a tap.

And the form opens as a sheet that slides up from the bottom over the video. The video and audio continue to flow. Answer → Send → "🎉" → Return to viewing. The drop-off that occurs the moment you send them to an external LP is structurally zero. A tag is attached at the same time as sending, the follow-up scenario starts moving, and a thank-you reaches LINE—all automatic.

One discipline for measurement: "CTA click," "form submission," and "payment completion" are different events. If you start counting clicks as conversions, all improvements will go haywire.

Prompt to paste into AI:

Safely set up comments, CTA cards, inline forms, tags, and follow-up scenarios for the verification webinar. Do not send to production viewers or overwrite existing data before approval. 【Verification webinar】【Purpose of existing or new form to use】【CTA display seconds】【Tag after sending】【Follow-up scenario】 1. Read CTA-related migration/DB/API/client, forms submit route, tag side effects, and scenario trigger conditions. 2. List existing webinars, forms, tags, and scenarios to avoid duplication. Create a table of target IDs, current values, and changed values and wait for approval. 3. Confirm with preview=1 that the seconds for comments and CTAs are 0 or more and within duration, and match the content of the talk. Allow negative seconds only for waiting room comments. 4. Form cards should refer only to existing active forms, and URL cards should be https URLs only. 5. Since automatic display obstructs viewing, try with only one first. Confirm that video, comments, and live position are maintained after closing. 6. Pass through participation → CTA display → click → form submit → tag → scenario with only your verification LINE. 7. Confirm attend, heartbeat, CTA click, form submit, and conversion as separate records, and confirm they do not duplicate with double transmission.

Completion check: Multiple CTAs appear in order of seconds / Form is completed within the viewing page / Connected to tags and follow-up only once / Clicks and conversions are measured separately.

Supplementary Lecture: The Internal Data Structure is Just This

It seems like we're doing complex things, but the tables are straightforward. The webinar body has second-specified comments and CTAs, and friend reservation/viewing logs hanging off it.

Auto-Webinar Data Structure

One small trick I want you to take home: If you make the comment seconds negative, it becomes a "comment that flows in the waiting room before the start." This is a design I like because it created the bustle of the waiting room without adding migrations.

All numbers are recorded and connected.

Chapter 6: Improving Participation, Drop-off, and CTA with Numbers

Since "session participated, viewing position every 30 seconds, CTA click, and form submission" are recorded as separate events for each viewer, the funnel is connected into one.

Actual measurements for one full day again: Clicks 330 → Reservations 166 (50%) → Viewing 146 → CTA clicks 66 (45%) → Consultation leads 14. Leads are automatically selected and lined up based on form answers (annual sales, budget, start time), so you just reply in order from the top.

Rules I impose on myself for analysis:

• The viewing position is the "last confirmed position every 30 seconds" and not the exact moment of drop-off. Communication cuts and backgrounding are also mixed in. Read it knowing that.
• Do not draw conclusions from a single session with a small number of people. Match the differences between sessions with which section of the video it is.
• Improvements are one variable at a time. If you change the beginning, do not touch the CTA seconds. Compare in the next multiple sessions.
• Do not just chase CTR. Even if you hype it up and make them click, it's meaningless if the content of the form is hollow. Judge by the quality of the leads in the end.

Prompt to paste into AI:

Analyze the performance of this auto-webinar in read-only mode and propose only one improvement to try next. Do not output individual names or answer contents in the aggregation results. 【Target webinar】【Target period/session】【Definition of final CV】 1. Read analytics API and DB implementation of viewing, reservation, CTA, and form. 2. For each session, aggregate reservations, notified, participated, average/median final position, 25/50/75/90% reach, CTA click, form submit, and CV. 3. Distinguish previews, management tests, abnormally short connections, and re-entries by the same person. 4. Note that heartbeat is the last confirmed position at 30-second intervals and is not the exact drop-off second. 5. Match major drop-off points at 10-minute intervals with video chapters, comments, and CTA display seconds. 6. Show "Problem / Basis / Item to change only once next time / Success condition / Number of sessions to observe."

Completion check: Duplication is suppressed by friend x session / Viewed the funnel from reservation to CV / Clearly stated the limits of heartbeat / Changing only one variable at a time.

By the way, you can enter this funnel right now. Experience it here👇

https://line.the-harness.com/x-autowebinar

Design how to stop it before publishing.

Chapter 7: Testing Before Production Release and Designing How to Stop

This is the part most people skip, and where most accidents happen.

The test before release is "buying the purchase flow yourself with your own LINE"—this is the fastest. Go through everything yourself: reservation → registration confirmation → waiting room → 5-minute notification → viewing → CTA → form → tag → follow-up. A build passing and a flow passing are two different things.

There are also traps in replacing videos. Do not overwrite in the same place. Old segments cached for a long time on the viewer's side and the new playlist will mix, and the video will break. Place it in a folder with a new version name, switch the reference, and keep the old version for a period where you can revert.

Emergency stops are all about the order:

1. Stop the entrance (revert the webinar to draft)
2. Stop automatic processing (reminders, follow-ups)
3. Issue guidance
4. Data deletion is last—if you delete R2 first, the screen of the person currently viewing will die at that moment.

Prompt to paste into AI (Release Determination):

Determine GO/NO-GO for publishing this auto-webinar to production without changing code. 1. Check repo/branch/commit, unsaved diffs, applied D1 migrations, Worker deployment, R2 bucket/prefix, and webinar status. Do not display secret values. 2. Execute related tests, typecheck, and build for schedule, token, route, asset, reservation, reminder, CTA, and DB. 3. Confirm master/variant/start, middle, and end segments, duration, audio, quality, Content-Type, signature expiration, and path traversal rejection. 4. Pass through session selection → reservation confirmation → waiting room → 5-minute notification → start → mid-participation/reload → CTA → form → tag → scenario → analytics with just one of your verification LINEs. 5. Confirm auto-play restriction, audio ON, background recovery, and end screen on iPhone LINE/Safari, Android LINE, and PC Chrome. 6. Check Cron double execution, LINE failure, token expiration, no R2 object, and form failure. 7. Confirm all LINE transmissions are logged. 8. Plan to use a new R2 prefix with a version for video replacement and keep the old prefix for rollback. 9. Show the stop procedure (Entrance → Cron → Guidance → Deletion last). 10. Summarize commit, test evidence, cost, monitoring, rollback, and unresolved risks into one sheet, and if there is even one major unconfirmed item, make it NO-GO. Wait for my explicit approval for production changes.

Finally, I'll leave the GO/NO-GO criteria I use as is. Do not publish if even one is unconfirmed:

• Are the commit in use, unsaved diffs, and applied migrations identified?
• Did you confirm the start, middle, and end of HLS, audio, and quality switching on an actual device?
• Did you confirm mid-participation, reload, and background recovery in the iPhone LINE in-app browser?
• Did you confirm that the reservation confirmation and 5-minute notification reached only you once and were logged?
• Did you match CTA, form, tag, scenario, and CV as separate events?
• Can you explain the stop procedure, replacement procedure, and rollback?

I Haven't Written a Single Line of Code

I made all the mechanisms up to this point by talking to AI. With one word, "It doesn't play from the middle on iPhone," it changed to the EXT-X-START method, and with "It drifts from the comments when I take off AirPods," it became the rule that "there is no pause in live." When I say what I've noticed, it's reflected in production a few minutes later. Development becomes a "conversation" rather than an "order."

The prompts I placed in each chapter are the work instructions I actually use in those "conversations." The foundation, LINE Harness, is open-source, so anyone can have the same thing with their own LINE Official Account.

You Can Enter the Actual Demo

A demo is better than an explanation. If you add as a friend from the link below, a guide will reach LINE and you can choose the session to participate in. Experience it here👇

https://line.the-harness.com/x-autowebinar

By the way, which session you chose after entering from this article, how many minutes you watched, and whether you went to the form—it's all automatically recorded. That is this system.