Most companies have a quiet but expensive pattern. The things that get done excellently get done by specific people. Those people’s excellence is locked in their heads. The senior CSM runs a customer onboarding that customers rave about; her colleagues run the same session and the response is muted. The founder gives a sales demo that wins deals; the AE giving the same demo loses them. The head of product runs research interviews that surface real insight; the PM running the next round gets surface-level answers. The cost is invisible because nobody connects it to the right cause. The team thinks the senior people are “naturally better.” Sometimes that’s true. Far more often, the senior people have built up a tacit script — a sequence of beats, transitions, questions, recovery moves — that they don’t think of as a script at all, because they’ve internalized it. The script exists; it’s not written down. This guide is a specific instance of the workflows pattern, applied to the conversion of tacit execution excellence into transferable written form. Done well, it’s how “Sarah always crushes the demo” becomes “everyone runs Sarah’s demo” — without Sarah having to shadow every new hire for six months. The workflow is unusually tractable today: each script comes from a single source session captured in a normal Earmark recording. No cross-meeting synthesis required for the core flow. The “cross-team synthesis” enhancement (combining moves from multiple sources) is covered as an optional manual step toward the end.Documentation Index
Fetch the complete documentation index at: https://docs.tryearmark.com/llms.txt
Use this file to discover all available pages before exploring further.
Foundation
Pick the source session carefully
The most important variable in script quality is which session you capture from. The principle: capture from a session that went well, run by someone who runs it well. Capture options:- A senior team member running the activity — most common; the script encodes their excellence
- You running the activity yourself — for capturing your own pattern to give to others
- Multiple sessions across the team — synthesize the best moves from each (manual workaround, see the iteration section)
- A session that didn’t go well, deliberately — to capture what not to do as an “avoid” companion script
If the source session is not normally recorded (internal workshops, research sessions where recording would change dynamics), get consent explicitly before running the workflow. For sessions where recording isn’t appropriate, use temporary meetings.
Identify who will use the script
Different audiences need different shapes:| Audience | What they need |
|---|---|
| New hire learning the activity | Detailed script; verbatim phrasing; timing markers; facilitator notes; “watch out for” moments |
| Experienced team member needing a refresher | Lighter script; key beats; transitions; the parts that get forgotten |
| Peer running the activity for the first time | Full script plus context on why each move matters |
| You yourself, mid-execution | A glanceable artifact — beats, transitions, key questions, but nothing to read in full |
| Team you’re handing off to | Script plus rationale plus common pitfalls — they need to maintain and evolve it |
Pick the artifact type
Four shapes cover most cases:| Type | When to use |
|---|---|
| Demo script | Repeatable product / sales / CS demos; structured around showing capabilities and landing specific points |
| Facilitator guide | Group sessions — workshops, training, research, retros — where the facilitator is leading others through a process |
| Step-by-step process (SOP) | Linear processes that need to be executed in order — “how to demo product X end-to-end,” “how to run weekly business review prep” |
| Presentation / webinar prep | One-time event delivery — talks, webinars, panel discussions |
Destination and ownership
Scripts live somewhere durable. Common patterns: Notion or Confluence wiki for team-wide scripts; sales enablement platforms (Highspot, Showpad, Seismic) for sales-specific work; LMS (Lessonly, Workramp, Sana) for training-specific. Pick one and stick with it. Scripts in three places drift and the team stops trusting which version is canonical. Each script has one owner — the sales enablement lead for demo scripts, the head of CS or training lead for trainings, the head of research or senior PM for research scripts, the function lead for internal facilitator guides. Single owner; quarterly review. Shared ownership produces drift; no ownership produces staleness within a quarter.The four templates
Template A — Demo script
For repeatable product demos. The workhorse for sales and CS teams.Template B — Facilitator guide
For group sessions — workshops, trainings, research interviews, retros, design sprints. Different from a demo: the facilitator is leading the audience through an activity, not showing them something.Template C — Step-by-step process / SOP
For linear processes that need to be done the same way every time. Less about delivery, more about execution.Template D — Presentation or webinar prep
For one-time event delivery — a talk, a webinar, a panel, an exec presentation. Different from a demo: less repeatable, more about polish for a specific audience.Save them as workspace templates
Identify the most common activity first
Most teams start with one template. Demo script for sales teams; facilitator guide for CS or research teams; SOP for ops teams. Save the most-used one first.
Tune to your team's activities
Adjust the section headers to match what you actually do. If your demos don’t have a “Closing” section because the close happens in a separate call, drop it. Don’t force your work into a generic shape.
Save with Workspace visibility
Scripts are team standards. Workspace visibility means anyone on the team can produce the same shape. See Custom templates.
Capture mode: running the workflow on a single source session
Confirm the source is worth capturing
Did the session go well? Will this activity recur? Is the facilitator’s pattern actually distinctive? Is the facilitator willing to share? If all four are yes, the session is a capture candidate. Capturing from mediocre sessions produces mediocre scripts.
Pre-seed the source session with the right template
Demo → Template A. Workshop / training / research / retro → Template B. SOP / process → Template C. Presentation → Template D. See Before a meeting.
Run the source session as it would normally be run
Don’t change anything about how the session happens. The point is to capture what actually works, not what the source person thinks they do.
The 20-minute curation pass
Heavier than for most workflows because the output is meant to be used by other people who weren’t in the source session.
- Read it as someone who wasn’t there. Is the flow clear? Are the transitions logical? If something seems to skip a beat, fill it in.
- Confirm the verbatim phrasings. The model extracts specific language from the source; verify these landed because the language was good, not because the audience was polite.
- Add facilitator notes the model couldn’t capture. Things the source person knows about why a particular move works. The “watch for this” notes. These aren’t in the transcript; they’re in the source person’s head. Get them out.
- Confirm timing markers are realistic. Source sessions sometimes run long or short due to specific audience dynamics; the script’s timings should reflect what the activity should take.
- Add the “what NOT to do” section. This comes from the source person’s accumulated experience, not the transcript. Sit with them for 10 minutes and capture the anti-patterns.
- Verify prerequisites and setup. The source person did this without thinking; the script needs to make it explicit.
Test the script
Before publishing as canonical, have someone else use it. The first user is the highest-fidelity quality check you’ll get. They’ll find steps the source person skipped because they were obvious; transitions that aren’t actually transitions for someone new; phrasings that work in the source person’s voice but feel wrong for someone else. Iterate based on the first use.
Use mode: the script during execution
A unique aspect of this workflow versus others in the series: the artifact gets used during the activity, not only before it. The script is a live tool. Pre-session reading. Before running a session, the user reads the script. For a familiar activity, a five-minute refresher. For a new activity, thirty minutes of prep, ideally combined with watching the source recording. The glanceable artifact during execution. Live, the script should be glanceable — not read in full. A demo script should fit on one screen so the presenter can scan it between beats. A facilitator guide can be longer but should be navigable. The bold beats, section headers, and short bullets in the templates above support this — mid-demo, scanning a wall of text is impossible; scanning bolded section names and beat numbers is easy. For some teams, a compressed version of the script — beats and transitions only, no detail — is worth maintaining alongside the full version. Full for pre-session prep; compressed for live use. The “where am I” recovery pattern. A presenter loses their place mid-demo or mid-workshop. They glance at the script, find their location, and recover. This is only possible if the script is open on a second screen, on paper, or in a pinned tab; the beats are clearly labeled; the current section is unambiguously identifiable. The template’s structure supports this by default; the user’s habit of keeping the script open during the activity makes recovery possible. Note-taking during live use. While running the activity, the user notes what they wished the script said. After the activity, those notes feed the next revision. A few jots in the margin or a Slack DM to yourself. The discipline is capturing friction in the moment, when it’s clear what the script missed, rather than trying to remember later.The iteration loop
Scripts that don’t get updated decay. Scripts that get updated every time they’re used improve continuously. The post-session note. After running an activity from a script, the user spends two minutes noting: what worked from the script (which beats landed, which phrasings drew engagement); what didn’t work (what felt off, what got skipped, what the audience reacted poorly to); what was missing (what came up that the script didn’t address); what’s worth adding (moves the user made that worked and should be in the script). The monthly refresh. Once a month, the script owner reviews accumulated notes and updates the script. Adds the new beats that have been working. Refines the phrasings. Cuts sections nobody uses. Updates timing markers based on real session durations. The monthly cadence is what keeps the script alive. Cross-team synthesis. When multiple team members are running the same activity from the same script, the script becomes a substrate for cross-team learning. Quarterly, the script owner runs a 30-minute session where everyone shares what’s been working. The notes feed a major revision. The team converges on a best version that’s sometimes meaningfully better than what the original source person was doing. This cross-team synthesis is the part of the workflow that benefits from cross-meeting context. Earmark refines artifacts within a single meeting today; combining moves from multiple sources is a manual workaround — paste the relevant sections from each source artifact into Customize context, then run a synthesis pass against the assembled document. Versioning. Treat scripts as living documents, not sacred texts. Major versions when the activity structure changes; minor versions for refinements; date the last update so users can see how fresh the script is. Keep old versions accessible but mark them as historical.Routing and the paired recording archive
The destinations and how they fit together. The script library. A single central location organized by activity type (sales demos, customer success workshops, internal trainings, research methods, facilitation playbooks, process SOPs). Scripts get found via search and navigation. Cross-link related scripts. The onboarding curriculum. Scripts are the backbone of any structured onboarding. A natural progression: week one — read scripts for activities you’ll be doing, watch source recordings. Week two — run the activity once with the script open and a senior person observing. Week three — run twice with the script open but no observer. Week four — run from the script with no support. Month two — start contributing to the iteration loop. This compresses ramp time materially compared to “shadow Sarah for six months.” Sales enablement platforms (Highspot, Showpad, Seismic): the demo scripts and presentation prep docs go in. The platform handles version control and viewer analytics. The Earmark capture is the input; the platform is the distribution. Don’t duplicate. LMS / training platforms (Lessonly, Workramp, Sana): for customer-facing training scripts. New CSMs and implementation engineers read them as part of their training. The paired recording archive. Whatever the destination, the source recording stays in Earmark. Scripts link back. When a user reads a script and wants to see the original — to understand a beat that doesn’t quite make sense in writing — the link is one click away. This is the part of the workflow that compounds most over time. The team accumulates not only a script library but a paired recording library. New hires learn by reading scripts and watching the source.Common pitfalls
- Capturing from mediocre sessions. Garbage in, garbage out. Capture from sessions that actually went well.
- Skipping the curation pass. The template output is a draft, not a script. Without curation, the script reads as transcript-y outline rather than executable artifact.
- Skipping the “what NOT to do” section. The anti-patterns are often more valuable than the patterns. Force the section.
- Source person not in the loop. Capturing from someone else’s session without involving them in the curation produces a script missing the why behind the moves. Get the source person in for the curation pass.
- Scripts that are too long. A 12-page demo script doesn’t get used live. Compress. The full version can be long for prep; the live version should be glanceable.
- Scripts that are too short. A one-paragraph “demo outline” isn’t a script. It’s an outline. Detail is the point.
- No timing markers. Sections without target durations produce demos that run long.
- Treating the script as sacred. A script is a working document; it should change every month. Teams that treat scripts as immutable end up with playbooks nobody trusts.
- No owner. Shared ownership produces drift. Single owner per script.
- No iteration loop. Scripts that don’t get refined after each use decay. The post-session note is the cheap habit that keeps them alive.
- Library bloat. Scripts accumulate; they don’t get pruned. Audit quarterly; retire ruthlessly.
- Forgetting the source recording. The script and the recording together are more valuable than either alone. Always cross-link.
- Senior people resisting scripting their work. Sometimes senior people feel that writing down their pattern commoditizes them. Reframe: the script makes their excellence transferable, which makes them more valuable as the team scales, not less.
Where to go next
- Workflows — the general shape this is an instance of
- Custom templates — visibility, sharing, and edit permissions
- Composer — for tuning the prompt before saving as a workspace template
- Before a meeting — pre-seeding the template on the source session
- Sales calls workflow — for the deal-context that informs demo scripts
- People and team meetings workflow — for the candidate-interview script that’s the same shape applied to hiring
- Hiring workflow — the systematic hiring-loop version where interview scripts compound
- Structured meeting notes workflow — for capturing the iteration notes from each script use

