Inside WebinarJam’s Content Knowledge Base

Write one article about a software product and you can keep the details in your head. Write a hundred, at the pace search rewards, and you will eventually quote a price that changed, call one product by a sibling product’s name, or describe a feature that does not exist. WebinarJam has three sibling products, a real price list, and a precise feature set, so before we wrote a single pillar article we built a knowledge base: the brand voice guidelines its parent company maintains, plus a full scrape of the site and everything it has published. This article is the map of that base, the buyer questions it answers, and why accuracy at scale is what actually feeds Google.

WebinarJam is a browser-based webinar platform built by Genesis Digital, the company behind EverWebinar and Kartra. It has hosted more than a million webinars for over seventy-five thousand businesses across forty industries, and it publishes on a domain with the kind of authority most sites never earn. That scale is the reason accuracy matters so much here. When a brand this size publishes something wrong, it ranks, and the mistake travels.

What the knowledge base actually contains

A knowledge base is only useful if it holds the things that are easy to get wrong. For a software product, that is the pricing, the exact product names, the feature set, and the brand’s voice. So the base starts with two inputs: the brand voice guidelines Genesis Digital maintains, and a full scrape of webinarjam.com, every published article and every page, pulled through the site’s own API so nothing is remembered secondhand.

The point is not the size of the pile. It is that there is now one place where the current price lives, one place that knows WebinarJam is the live product and EverWebinar is the automated one, and one place that carries the brand’s actual voice. A writer, human or AI, that checks against it does not guess.

Concretely: the site came through its own WordPress API, all 59 blog articles and 66 pages of it, so nothing had to be paraphrased from memory or half-remembered from a browser tab. The source videos behind the pillar articles were transcribed so the spoken explanations became searchable text. And the whole program runs off a tracker that syncs from a live sheet: 22 pillar articles, each with its target keywords, its source video, its draft state, its reviewer and its published URL. An agent picking the work up always knows what already exists, what is half-built, and what is next, which is the difference between a content program and a pile of drafts.

The accuracy problem the base is built to solve

Three things go wrong when content scales without a single source of truth, and the knowledge base exists to stop each one.

Pricing drifts. Plans and prices change. An article written from last year’s memory quotes a number that is no longer true, and the prospect catches it the moment they open the real pricing page. The base holds the current figures, so every article that mentions cost points at the same source instead of a stale one.

Product names collide. Genesis Digital sells three products that are genuinely easy to confuse. WebinarJam is the live platform, EverWebinar is the automated one, and Kartra is the all-in-one suite. Even source material gets this wrong: a widely viewed tutorial that circulates online as a WebinarJam walkthrough is actually a walkthrough of EverWebinar. The base flagged exactly that, so the mix-up never made it into an article.

Voice slips. A brand that sounds like a helpful expert in one article and a jargon-stuffed sales page in the next reads like two different companies. The voice guidelines live in the base, so every pillar keeps the same register and the same small conventions the brand is careful about.

One wrong price, or one product called by its sibling’s name, published on a domain this strong, ranks first and then travels.

How the knowledge base becomes pillar content

The base is not an archive. It is the input to a pillar-content engine.

From the corpus we derive the voice profile, the product facts, and a map of what buyers actually search. Directed AI agents then write pillar articles, the long, thorough pages that answer one real question completely, each drafted in the brand’s voice and checked against the base before it ships. A few of the pillars, and the buyer question behind each one:

• What does it cost, and does it pay for itself? The pricing pillar.
• How is it different from the tool I already use? WebinarJam versus Zoom.
• Do I need the live tool or the automated one? EverWebinar versus WebinarJam.
• Will it work with the rest of my stack? The integrations guide.
• How do I get people to actually show up? Increasing webinar attendance.
• Can I run my course on it? WebinarJam for online courses.

Each one is the definitive answer to a question a buyer types before they ever type the brand name. The comparison and pricing pillars carry the most weight, because they catch buyers at the exact moment of deciding, which is the moment accuracy is least forgiving. Because the voice profile was built from the brand’s own published work, the articles read like WebinarJam and not like a chatbot, and because every pillar is checked against the base, a hundred of them still agree with each other.

The knowledge base this actually lives in

WebinarJam’s base is not a standalone project. It is one entity inside a single Obsidian vault that holds everything we do, and the vault is the reason any of it compounds instead of evaporating when the program ends.

The bottom layer is the entity knowledge bases: one folder per person or brand, each holding its raw sources, its compiled truth, and its deliverables. WebinarJam is one of them, sitting next to Paul Ryazanov, Cody Jones, Dunkademics and the rest. The scraped articles and pages, the brand voice guidelines, the transcripts, the pillar tracker: all of it lands there rather than in somebody’s downloads folder.

Above that sit the skills and SOPs, the reusable procedures. How to build a knowledge base. How to publish it. How to QA an article against a brand’s voice. How to scrape a site through its own API without missing half of it. They are routed by task, so an agent picks up the right procedure instead of improvising a new one each time.

At the top is the canon: the frameworks that hold no matter whose name is on the folder. The Nine Triangles, the Content Factory, the topic wheel, the entity linking decision tree, and the standing rule that you always boil the ocean rather than settle for good enough.

The part that makes it improve itself

The WebinarJam program did not start from zero, and it does not end when a pillar ships.

It started ahead because the procedure already existed. The knowledge-base publishing skill was written after the first full run, for Paul Ryazanov, then sharpened after Cody Jones, whose review exposed that we were not deep-linking into a subject’s own published work. That fix is precisely why the pillars above are linked here rather than merely described.

And this build put its own lesson back. The accuracy discipline came out of WebinarJam: the rule that a knowledge base must hold the things that are easy to get wrong, and that pricing, product names and terminology get checked against the base before anything ships. Three sibling products that are trivial to confuse turned that from a nice idea into a hard requirement. The publishing mechanics went back too, the unglamorous ones that cost an hour the first time and nothing every time after: encode the article body before posting it, never trust a silent response, always confirm the post actually landed.

The loop runs every time. Do the work. Document the run honestly, including what broke. QA it against what the procedure promised, and flag every place the agent had to guess, because a guess is a missing instruction. Fix the procedure so the next run does not need to guess. Then push whatever is general enough to help anyone into BlitzBase, the distributable version of the vault, scrubbed of every client name. If the lesson cannot be stated without naming a client, it was never general, and it stays put.

Dennis Yu calls this RSI, recursive self-improvement, and it is the whole reason the library gets sharper instead of going stale. It is the same idea behind the task library: one page per task, one URL per page, and every run makes the page better. The documentation is the asset. A shelf of one-off projects rots. A library that rewrites itself compounds, and keeping it current is the work.

What went in, what it cost, and what it would have cost

The ingestion inventory, so the numbers are checkable rather than atmospheric:

• The site pulled through its own WordPress API: 59 blog articles and 66 pages
• The brand voice guidelines ingested as the voice source of truth
• The source videos behind the pillar articles transcribed
• A 22-article pillar tracker synced from a live sheet, with keywords, source video, draft state and published URL per row
• Three sibling products kept distinct in the base, so nothing gets called by the wrong name

The agent column is a list-rate estimate, priced at published API rates for the Opus-class model that did the work, roughly five dollars per million input tokens and twenty-five per million output. In practice these runs happen on a flat-rate plan, where the real marginal cost is a fraction of the list figure, so read that column as an honest worst case rather than a bill. The human column is a blended fifty dollars an hour, sitting between the thirty-five an hour a working digital marketer costs and the seventy-five to a hundred and twenty-five an hour a senior strategist costs. On those numbers the program runs roughly fifty times cheaper and about eight times faster.

The shape of that table is the real lesson. The base is a fixed cost, paid once. Every pillar after it is a variable cost of about ninety agent-minutes against twelve human hours, and the pillars get more accurate rather than less as the base fills in, because each one is checked against a source of truth that keeps getting better. A content program without a knowledge base gets slower and sloppier as it scales. This one gets faster and tighter.

What the agent did, and what still needed a human

The agent handled: pulling the site through its API without missing half of it, ingesting the brand voice guidelines and building the voice profile from them, transcribing the source videos, building and syncing the tracker, drafting each pillar in the brand’s voice, checking the pricing, the product names and the terminology against the base before anything shipped, setting the SEO, interlinking the cluster, and grading its own output against the checklist.

A human was still required for: the brand relationship and the approvals, since a company’s own reviewers decide what its voice is and what claims it will stand behind. The strategic call on which pillars to write and in what order. The things only the company knows, like a price that has not shipped yet. And inspection, which is now the durable skill, because an agent that grades its own high-stakes work will eventually pass something it should have failed. A wrong price on a strong domain ranks, and then it travels.

Why this is worth doing

For WebinarJam: a brand this size already gets found by people searching its name. The pillars get it found by the people searching the problem, who do not know the name yet, and that is the harder and more valuable half of search. And because every article is checked against one source of truth, a hundred of them still agree with each other, which is not true of most content programs at that volume.

For BlitzMetrics: the accuracy discipline came out of this build. Three sibling products that are trivial to confuse turned “check it against the base” from a nice idea into a hard rule, and that rule now protects every other client in the library. The unglamorous publishing mechanics went back too. That is the actual product: not one pillar, but a library of documented procedures that sharpens every time it runs, and that anyone can install as BlitzBase.

Why a structured knowledge base strengthens the entity

A strong brand gets found by the people already searching its name. The harder and more valuable job is being found by the people searching the problem rather than the brand, and being trusted enough to be the answer. A cluster of accurate, interlinked pillar articles is how you earn that. Every pillar covers one buyer question completely, every article links to its neighbors, and the whole set corroborates the same product facts in the same voice. This is the mechanic Dennis Yu lays out in Google entities and trust and in owning your name on Google, applied to a software catalog instead of a person.

The knowledge base is what makes that possible at volume without the errors that usually arrive with volume. It is the same system we run for founders like Paul Ryazanov and Cody Jones and even a whole sport at Dunkademics, pointed at a product catalog instead of a personal brand, and the full engineering of how a base is gathered, structured, and published is in our build, use, and publish guide. Any brand with a real catalog and a reason to be precise can be run the same way.