Enough documentation is enough that a competent person can do the task without asking. Not a manual, not a policy, and not a recording of somebody talking through it once.
What a procedure contains
The name of the task and when it happens. The steps, numbered. The decisions the person may take alone and the ones they must escalate. Examples of correct output and of incorrect output. And who to ask when something is not covered.
The two lists of decisions are the part everybody omits and the part that determines how many interruptions you receive in month two.
Who maintains it
The person doing the task. This is the single most useful move in this entry.
Documentation written by a client and never touched again rots within months and is then worse than nothing, because it is trusted and wrong. Documentation maintained by the person doing the work stays current, and the act of maintaining it demonstrates whether they have understood the task.
Review their edits rather than writing the document. It is less work for you and produces a better document.
Recordings
Good for capturing a process quickly and bad as the permanent artefact. Nobody scrubs through eleven minutes of video to check step four, and a recording cannot be corrected without re-recording.
Record once, have the person transcribe it into steps, and keep the steps. The recording can stay as a supplement.
Where it lives
On your systems, in your account. The entry on what to keep onshore explains why: documentation held in a provider's knowledge base has to be rewritten if you ever change provider, which is precisely the moment you will least want to.
How much is too much
Documenting work that changes weekly produces a document that is wrong weekly, and it teaches people that the documentation is unreliable. Where a process is genuinely in flux, write down the principles and the escalation route and leave the steps until it settles.
Documenting the obvious has the same effect by a different route: a forty-page procedure for a ten-minute task will not be read, and the important part in it will not be found.
The test
Could a new person start from this document alone and produce acceptable output within a day, asking no more than a handful of questions?
You can run the test cheaply: give the document to somebody who has never done the task and watch. Every organisation that tries this is surprised by what turns out to have been assumed.
The replacement case
Documentation is what makes the second onboarding cheaper than the first, and the entry on real cost puts that in the model. A team with current procedures survives a resignation with a fortnight of disruption; one without survives it with a quarter.
Since attrition in this industry is not zero, this is not a hypothetical.
Writing the first one
Do it with the person, in the first week, on a task they have just learned. It takes an hour, it produces a template for everything afterwards, and it establishes that maintaining it is part of the job rather than an imposition.
A format that works
One page per task, in a shared document, with the six headings from above and nothing else. Long procedures fragment into several one-pagers rather than growing.
An index listing every task with a link, maintained by the same person, so that a replacement can see the whole role at once.
Reviewing them
Quarterly, in the review meeting: pick two at random and read them against what actually happens. Drift is normal and undetected drift is what makes documentation untrustworthy.
The document you also need
A short one about your business rather than about tasks. What it does, who the customers are, what the words mean. People perform better when they know why, and remote staff receive almost none of this incidentally.
It takes an hour to write and almost nobody writes it.