Designed a control plane to scale AI avatar videos

Each campaign is a reusable setup, the avatar, the script, and the variables, that one person configures once and a whole team can run, either by hand or automatically from their CRM.

I led the design over about a year, working with a small team: a senior product manager, a product director, our VP of product and design, an engineering manager, a staff engineer, a group of developers building the surfaces and the automation underneath, and our CTO. The interesting problem was never generating the video; Vidyard could already do that. It was the human layer around it: turning a one-off into something a whole team could run repeatedly, and keeping the people whose faces it used informed and in control of where their likeness went.

Vidyard could already generate a personalized avatar video from a script. Everything that turned that video into a sent, opened, replied-to message still happened by hand.

In January 2025, we ran concept tests with the heaviest users of the bulk tool. A franchise owner who generated 50 to 100 videos at a time walked me through the part that came after: he built and sent each email himself, hunting for the right video for each recipient in a long, near-identical list. “You might have five people named John,” he said, and the only way to tell them apart was to play each one until he heard the right company. He did it by hand. It didn’t scale.

The same shape showed up everywhere. Reps couldn’t reuse a script they had written, so they reopened old videos and retyped them. To distribute, they pasted links one at a time, forty in a good hour. The bottleneck was never the avatar; it was matching, reuse, and distribution, and most people who started never got a usable batch out the other end.

A second problem appeared the moment the video carried a face. A sales director who happily let a teammate run her email outreach drew a hard line at her avatar: “I don’t want her sending anything out that I haven’t looked at.” Her words on someone else’s send were fine. Her likeness was not. The enterprise accounts circled the same instinct: the larger the team, the more someone wanted a say before an avatar spoke for them.

So the problem was bigger than generation. It was how one person could set up a video system a whole team could run, without the manual matching and reuse, and without anyone losing track of whose face was on which send.

By late 2024 Vidyard had the raw capability but not the habit. It could train an AI avatar on a person’s face and voice, and it had a bulk tool that could turn out many videos at once. Both worked. But using them at any real scale was entirely manual, every step done by hand, so they stayed a trick for power users rather than something a team reached for.

The bet was not another avatar feature. It was a system that made the avatar repeatable: set the script, the look, and the variables once, then generate from that configuration as often as you like. The idea surfaced while I was reworking a bulk-tool flow and saw the bulk feature was the first, narrowest instance of something larger. A campaign was that configuration, set up once and reused.

The idea had a hole in it I wanted to check before we built anything. It had come out of research with people who wanted their manual video recording to be less repetitive, none of whom used AI avatars, and we would be aiming it at a different audience entirely. So rather than assume it would transfer, we tested the hypothesis early, taking the concept to our heaviest avatar users in January. The concept held: what these users wanted was for the manual assembly to disappear.

The bulk tool was a flow: a few screens you pushed through once and abandoned. A campaign had to be an object, one you return to, share, connect, and watch. The first structural decision was to give it surfaces.

A campaign sits as a row in a list and opens into three tabs. Edit is where you author it: the title, the appearance, and the script, with personalization tokens (variables) dropped inline. Videos collects every video the campaign has generated, batched by send and counted by views, so an owner can see what the campaign produced and on whose behalf. Workflow is where you connect it to a trigger. Author it, watch it, wire it up.

Variables carry the personalization, and the system needed two kinds working together. Per-recipient variables like first name and company resolve against whoever receives the video, so each recipient hears their own name and their own company. Sender variables resolve against whoever generates it, so each teammate’s own name and role fill in when they run the campaign. Write a script that opens “Hi {first name}, I’m {sender first name}, {sender job title},” share the campaign, and both halves of the personalization land at once. The two kinds together are what let one person’s setup become many people’s sends.

At launch, the campaign editor started empty. We added three starter examples in the empty state as a deliberate experiment, the fastest way to learn whether seeing a few campaigns helped people build their own. They were a stopgap, disappearing once you made your first campaign, but they helped enough to keep. The next pass made the examples permanent and always reachable, renamed to Inspirations to stop colliding with an existing “templates” feature.

Sharing a campaign with a team raised a question the single-user bulk tool never had to answer: who gets to use whose face? Left unhandled, one person could generate a video with a colleague’s avatar and that colleague might never find out. For a feature whose premise is your face saying words you didn’t record, we had to answer that before we let campaigns be shared.

The obvious answer would be approval: ask the owner before anyone uses their avatar. I argued against it. Inside a workspace the stakes are lower than on the open internet; you can only add people from your own organization, and the admins building these campaigns are wiring them into sales motions their teammates are already part of. Requiring approval would add friction to the exact moment that needs to be fast, and worse, it would break the automation: if the CRM fired a request for a video before the person had clicked approve, the generation would simply fail. So enrolment is open by default. Adding someone enrolls them and notifies them, in the product and by email, instead of waiting on a yes.

What enrolment gives the person whose face is used is transparency and an exit. They can see which campaigns use their avatar, the script those campaigns run, and every video generated for them. They get view-only access to everything except the one thing that is actually theirs, the avatar itself, which defaults to their most recent but which they can swap for any other, including a stock avatar if they would rather not appear at all. And they can leave a campaign at any time, after reading the script or if they were added by mistake. Low friction to set up, enough visibility and control to trust.

For teams that want a checkpoint before anything sends, there is a review gate: a page where a person watches each generated video and chooses Approve, Delete, or Approve All. Declining asks why, with four reasons, unrealistic avatar movement, poor lip sync, poor audio quality, or no longer want to reach out to this contact, so the same step that gives a human veto also hands the model team a clean failure signal. In practice most teams never ask for one; that much oversight turned out to be the exception, not the rule.

This is where the system earned its argument. In the most recent quarter, 94% of videos generated through automated workflows came from someone other than the person who built the campaign. One operator’s setup, a whole team’s sends.

A campaign runs two ways, and both are the same job with a different trigger. You set it up once; then either a person fires it as a manual bulk send, or a CRM fires it as an automated workflow. The clarifying way to see it is that in the manual mode the operator is the trigger, doing by hand the moment-to-moment work an automation would otherwise do on its own. The template never changes. Only what pulls it does.

By hand, it is three steps: choose a campaign, add your recipients, and preview before you generate. The middle step, adding your recipients, used to be a bare “upload a CSV” screen, and it was the single biggest drop-off in the flow: most people who created a campaign never made it through that step, though almost everyone who did went on to generate a video. I replaced it with a table pre-filled with the campaign’s variables, so you can paste a CSV for a long list or just type a couple of rows for a short one, and edit any cell inline. Sending two videos no longer means building a spreadsheet for two. In the three months after the change, the share of people who created a campaign and then made it through that step went from about 3% to 13%, a roughly fourfold jump.

Automatically, a campaign connects to a trigger in a sales platform: a form fill, a new lead, a stage change. The Workflow tab is the setup surface, and most of its design was consolidation. The values you need to wire up an automation, the campaign ID, the webhook URL, the keys to map your variables, used to be scattered across your profile, the integrations page, and the browser address bar. I pulled them into one tab with a per-platform setup guide, so connecting a campaign reads like following assembly instructions instead of a scavenger hunt.

Both modes resolve to one link. Every campaign has a single share URL that carries the recipient’s email as a parameter and, when they open it, resolves to their video. This is what finally answers the “five people named John” problem from the start: you paste one link into a hundred-row sequence, and each recipient opens their own video, with no matching by hand. The automation never writes a specific video back to the CRM; it hands over the campaign link and lets the link do the lookup.

The connection has one real edge. Because a campaign now drives a live automation, editing its variables after it is wired up can break the integration on the CRM side, where nothing signals that the shape changed. So I designed a workflow-health layer for exactly this: when you are about to make a change that could break a connected campaign, it warns you first, explains what will break, and points you to a short guide on what to update on the CRM side to keep it running. Catch the failure before it happens rather than forbid the change. The design is ready, sequenced behind the work that comes next.

In the most recent count, 87% of campaign videos came through automated workflows and 13% through manual sends.