Your customer signed on a Thursday. By the following Wednesday you have sent a welcome email, an implementation guide, a link to the knowledge base, and a calendar invite for a kick-off call that has already been moved twice.
Nothing has been configured. Nobody has logged in except the person who signed.
If you run customer success at a British software company, you know this stretch well enough to predict it. The contract is signed, the enthusiasm is real, and then the customer disappears into their own quarter for three weeks. When they resurface, they have forgotten most of the kick-off call and none of the documentation has been read.
Renewal conversations eleven months later trace back to this fortnight more often than anyone likes to admit.
The material was not missing. Everything the customer needed was in the implementation guide, in a format the people who had to act on it were never going to open.
Time to Value Is Decided in the First Ten Days
Most B2B software teams track time to value, and most measure it as the gap between contract signature and first meaningful use. What that metric hides is where the delay actually sits.
It is almost never the product. Configuration takes an afternoon. The delay is that the customer’s team has not understood what they bought well enough to start, and the people who need to understand it were not on the call.
The person who signed is usually a director. The people who have to make it work are two or three levels down, were not in the sales process, and have inherited a tool nobody asked them about. They received a forwarded email with a PDF attached. Their honest position is that this is extra work landing in a week that was already full.
Your implementation guide assumes a reader who wants to be there. That reader is the exception.
The Implementation Pack Is Written for the Admin, Read by Everyone Else
There is a structural mismatch in nearly every onboarding pack, and rewriting it will not resolve it.
The pack is written for the administrator, because the administrator does the setup, and it is comprehensive because leaving something out generates a support ticket. So it covers permissions, integrations, data import, and user provisioning, in that order, at length.
The end user opening that document has a completely different question. They want to know what changes about their Tuesday. Nothing in the first eight pages addresses that, so they close it, and three weeks later they are still working the old way while your dashboard shows one active seat out of forty.
Both documents cannot be the same document. Most teams know this and produce one anyway, because producing two is twice the work and nobody has the afternoon.
What Document to Video Changes
The realistic constraint is not whether video would help. Everyone in customer success already believes it would. The constraint is that recording, editing, and maintaining a library of videos is a full role, and most UK software companies under a hundred people do not have that role.
That is the part worth revisiting. Tools now generate narrated video directly from a document you already have. Upload the implementation guide as a .docx or .pdf, or paste the text, and the system builds an outline, writes narration from your material, arranges the on-screen content, and produces the video. The document to video route means the work you are adding is editing a script rather than booking a studio afternoon.
It helps to be precise about what this produces. It does not capture your interface. What it produces is explanation: what this thing is for, what order the steps happen in, what people usually get wrong. If your onboarding pack is mostly click-here instructions, generating from it gives you narration reading click-here instructions aloud, which nobody needs. If it contains the conceptual sections that explain why the setup works the way it does, those convert well.
Two fields decide most of the output quality and both get left empty. There is an audience field and an objective field. “End user who did not choose this tool and has no admin rights” produces a genuinely different script from the default. The narrative style options include Explanatory and Structured, both of which suit implementation material better than anything persuasive.
Different Segments Need Different Cuts
This is where generating from documents beats recording, and it is not obvious until you have done it.
Once the source is a document rather than a recording, producing a second version for a different audience costs an edit rather than a reshoot. The administrator gets the version covering permissions and data import. The end user gets four minutes on what changes about their day and nothing about provisioning. The finance stakeholder who asks for a summary in month two gets a short version built from the same material.
Under the old model those three assets never existed, because each one meant another recording session and the CS lead had four onboardings running that week. Under this one they are variations on a file.
Keep them short. The short setting runs roughly one to three minutes, and an end user who did not want this software is not watching twelve.
Building It Once and Reusing It
The failure mode with onboarding content in growing companies is that it exists in five places and none of them are current. There is a version in the shared drive from the last funding round, one in the CS team’s Notion, and a Loom somebody recorded in a hurry that references a feature you deprecated.
There is a knowledge base where source material can be uploaded in batches, up to ten files at a time, and drawn on when generating. The practical value is not storage. It is that pulling your onboarding material into one place before generating anything exposes the contradictions between the five versions, which is an audit nobody was ever going to schedule.
After that, updating means editing the source document and regenerating, rather than finding whoever recorded the original and asking whether they still have the project file.
Watch Data as an Early Health Signal
Shared videos report back. Impressions, unique views, average watch time, and completion rate are all visible.
For customer success this is more useful than it is for marketing, because it arrives before the account is in trouble. An onboarding cohort where the admin watched everything and no end user opened anything is a specific, actionable problem in week two. Under the current process you find that out in month four, when usage is flat and the champion has gone quiet.
Completion rate also tells you which part of your own product story fails to transfer. If viewers consistently stop at the same ninety second mark, and that is where you explain your permissions model, you have learned that your permissions model confuses customers. That is worth knowing regardless of what you do about the video.
There is a chat panel alongside a shared video, so a viewer who is unsure can ask at the point of confusion rather than composing an email to support later, or not composing it. And password protection is available, which matters for implementation material that includes account specifics.
Where This Does Not Help
Nothing here replaces the kick-off call. The call exists so a real person can ask an awkward question and get an answer, and a customer who never speaks to anyone at your company churns whatever else you send them. This is for the thirty-eight people who were not on the call.
If the source document is out of date, so is the video, and the video hides it better. An instruction describing a flow you shipped over eight months ago arrives narrated smoothly and reads as current, which is a worse outcome than the same sentence sitting in a PDF where customers half expect rot. Script review has to sit with a CS lead who knows the product this quarter, rather than with whoever has capacity that week.
Anything genuinely visual belongs in a screen capture. Debugging, error states, and any workflow where the customer has to see your actual interface are better served by recording the interface. Keep both.
Anything carrying a relationship needs a face attached. Executive business reviews, renewal conversations, and pricing changes are relationship work, and putting a generated presenter in front of them signals precisely the opposite of investment in the account.
Maintenance moves rather than disappears. When your onboarding flow changes, the videos become wrong at the same moment the documents do. Regenerating from an updated document is far quicker than rerecording, but somebody still has to notice. Put it in the same release checklist as the docs.
Before this goes into a CS runbook, note that the authoring side is desktop only in any practical sense, and Chrome is the browser it is tuned for. Customers watching the output have no such constraint.
Start With the Step Where Customers Go Quiet
Do not convert the onboarding pack. It is mostly reference material, and reference material makes weak video.
Instead, open your last twenty onboardings and find the step where accounts most often stall. Every CS team has one. It is usually a data import, an integration requiring someone from the customer’s IT team, or the moment end users are supposed to be invited and are not.
Take the section of your documentation covering that step, or write four paragraphs explaining it the way you would explain it on a call, and generate one short video. Send it before the step rather than after the stall, and keep the written guide linked underneath.
Then compare the next twenty onboardings against the last twenty on one number: days from signature to the point where that step is complete.
If it moves at all, you have a repeatable pattern and a business case for the next one. If it does not, you have spent an afternoon and learned that the stall is somewhere else, which is also worth knowing before the renewal conversation.