In-app training for SaaS: how to embed courses in your product

What is in-app training?

Teams reach for the phrase when they want customers to learn the product where they use it: an onboarding course on the first-run screen, a certification track in the partner portal, a short lesson beside a feature that people keep getting wrong. The alternative — a link to an academy on another domain — is what in-app training is defined against.

This guide is about the full end: embedding courses, not just tips. It covers why the location matters, how the options compare, what to check when you choose a tool, and how the embedding is wired together.

Why does training outside the product lose people?

Nobody needs a study to see where the losses happen; you can count the steps. A customer who wants to learn a feature in a separate academy has to:

1. Notice the invitation, usually an email that arrives when they are not thinking about training.
2. Create another account, with another password, on a site that looks nothing like your product.
3. Find the right course in a catalogue that was organised for the academy, not for the task in front of them.
4. Switch back to your product to try what they learned, and switch again when they get stuck.

Every step is a place to stop, and every one of them is a cost the product imposed, not the learner's lack of interest. Training in the product removes all four: the lesson is on the screen they are already looking at, they are already signed in, and the next thing they do after the lesson is the thing it taught.

There is a second loss, on your side. When training lives in another system, so do its results. Customer success cannot see who finished onboarding without an export; the product cannot unlock the next step when a course is passed; and the fact that an account never finished its training is invisible exactly when it would have predicted trouble.

What are the ways to train users inside a product?

Four approaches cover almost every team. They are not rivals so much as tools for different amounts of teaching, and many products use more than one:

The pattern is that tours are good at where, help centres are good at what, and an LMS is good at whether they learned it — but in the wrong place. Embedded courses try to keep the third while living where the first one does.

What should you look for in an in-app training tool?

Plenty of tools say they embed. The difference shows up in five places, and each is worth asking about directly:

• Identity without a second login. The learner should be the user already signed in to your product, passed by your backend — not an account with the vendor, and not an id anyone can type into a URL. Ask whether that identity is signed, and what happens when it isn't.
• It looks native. A course that arrives in someone else's fonts and colours reads as a third-party widget. Check that you can set typography, colours and shape, and that right-to-left languages mirror properly if you sell in them.
• Tracking comes back into your product. Progress, answers and completions should reach you as they happen: in the browser, so your page can react, and on your server, signed, so you can act on them. Reports you have to log in somewhere else to read are the old problem in a new place.
• It works on a phone. If your product runs on tablets and phones, the course has to as well — responsive layout, touch navigation, and a resume point that follows the learner from one device to another.
• Authoring is fast. In-app training goes stale every time the product ships. Whoever owns it needs to update a course in minutes, and ideally to create or change courses programmatically when the product changes.

Two more are easy to forget until they matter: how the price scales with the number of users who could take a course but mostly won't, and whether you can export a course as SCORM when a large customer wants it in their own LMS.

How does embedding a course work technically?

At a high level, three pieces do the work, and none of them needs an SDK in your product:

1. A signed identity. When your server renders the page, it takes the user id it already trusts, adds an expiry, and signs both with a secret shared only with the training platform — an HMAC. The platform checks the signature, not the query string, so nobody can learn as somebody else by editing the URL.
2. An iframe. The course runs in an iframe whose URL carries that identity. The iframe keeps the player's code and styles separate from yours, which is why it drops into any stack — React, server-rendered pages, a mobile web view — without conflicts.
3. Events and webhooks. While the learner works, the player posts messages to your page so the interface can respond at once. When something needs to be recorded — a completion, a score, a certificate — a signed webhook tells your server, which is the only channel to trust for anything that matters.

The browser half looks like this — a listener that unlocks the next step when a course is finished:

window.addEventListener("message", (event) => {
  const msg = event.data;
  if (msg?.source !== "underlayer") return;
  if (msg.event === "course.completed") unlockNextStep();
});

The split matters. Browser messages are for the interface, because anything in the browser can be forged; webhooks are for your records, because they are signed and sent from server to server. The embed docs have the signing code and every event, and the webhook docs show how to verify a delivery.

When is a product-tour tool the better fit?

A course is not always the right tool, and a product-tour or digital-adoption tool is often the better choice:

• When the lesson is one step long — where a setting lives, which button starts an export. A tooltip on the button teaches that faster than any course.
• When you want to guide someone through the live interface itself, highlighting real elements as they click them, rather than teaching the idea first.
• When the goal is nudging behaviour — announcing a feature, prompting an unfinished setup — and you do not need to know whether anyone understood it.
• When product managers want to build and target those flows without touching code, segmenting by user properties.

The two combine well. A tour points someone at a new feature; the tour's last step opens a five-minute course that explains why the feature works the way it does and checks the idea landed. Use tours for navigation and courses for understanding, and keep the evidence of understanding in the system that can prove it.

How does Underlayer embed training in your product?

Underlayer is a training platform built for exactly this. A course embeds in your product with one signed iframe. The learner is your own user id, HMAC-signed by your backend, so there are no learner accounts and no second login; the player keeps its own session once the signature checks out, and a learner who comes back resumes where they left off, even on another device.

The player takes your fonts and colours, or one of 8 built-in themes, and works on desktop, tablet and phone. Courses are built from 39 block types — in the dashboard, over the REST API, or from an AI client through the MCP server — and translate into 22 languages, with right-to-left Arabic. While the course runs, the player posts course.viewed, course.progress, course.answered and course.completed to the host page; completions and certificates also arrive as signed webhooks, and every result can be read back over the API. When a customer wants a course in their own LMS, it exports as SCORM 1.2 or 2004, and existing SCORM packages import.

Pricing is per course view, not per seat, so users who never open a course cost nothing. Paid plans start at $149 a month, every number is on the pricing page, and a free sandbox is available on request. The live demo is the real embedded player — switch its theme, language and device to see how it would sit in your product.