Trainers are not users, they are colleagues
The framing changes what kind of support you build.
Support documentation for learning platforms is usually written as if for a customer: here is the button, here is what it does. That framing fails with trainers, because a trainer's question is almost never about the button. It is about how to represent something they already know how to do in a system that has opinions about how it should be done.
A trainer who asks how to upload a document is often asking something else: whether the document should be a resource or an assignment, whether learners should be able to see each other's submissions, whether the deadline should be enforced by the software or by them. Answering the literal question produces a correct click sequence and an unhappy colleague, because the underlying decision was left to them without being named.
The support that actually reduces load is a short set of worked patterns rather than a long manual. Here is how we set up a course where learners submit work individually. Here is how we set one up where they present in groups. Here is how we handle a resubmission. Each pattern encodes decisions that would otherwise be made fresh, badly, by somebody under time pressure.
It also gives you consistency, which is what makes the whole system supportable. Twelve courses built on three patterns can be reasoned about. Twelve courses built twelve different ways cannot, and every question about any of them becomes an investigation.
This also changes how a new pattern should be introduced. A pattern that arrives as a policy will be complied with and resented. One that arrives because a respected trainer used it, found it worked, and showed two colleagues, spreads without enforcement and survives a change of administrator. That is slower and it is the only mechanism that produces consistency anybody defends, which matters because a consistency imposed from the administration side lasts exactly as long as the person imposing it stays in the role.