A documentation pilot should answer a practical question: can this workflow produce useful, maintainable content from the material your team already has?
Two weeks can be enough to test that on a defined scope. It is not a sensible blanket promise to complete and approve every document for a complex machine.
The outline below is a proposed ten-working-day pilot. Agree the scope, access, reviewer availability, and commercial terms before starting.
Choose a representative slice
Select one machine configuration or a clearly bounded assembly. Include a real service task and the parts needed for it.
Avoid choosing only the tidiest example. A useful pilot should expose a typical source issue, such as a missing part description or a discrepancy between a recording and a drawing. It should still be small enough for the team to resolve the important questions.
Define the intended output: for example, an approved maintenance procedure, a linked parts view, and a customer access test. Record anything excluded.
Days 1–2: confirm sources and acceptance criteria
Collect the relevant CAD export, parts data, current instructions, supplier information, and any recording that helps explain the task.
Identify which revisions apply. A STEP file may describe geometry without the service information needed to identify an orderable replacement part.
Name the engineer who can resolve technical questions, the reviewer, and the person who can approve publication. Agree their availability during the pilot.
Set acceptance criteria before drafting. A technician should be able to find the correct procedure and identify the applicable part; technical statements should be traceable to approved inputs.
Days 3–5: prepare and draft
Organize the material around the selected machine and task. Draft the procedure and prepare the parts information or illustration needed to use it.
Keep missing information visible. An unknown torque value belongs in the review queue, rather than being filled with a plausible number.
Record preparation and review time as well as drafting time. A fast first draft is useful, but it is only one part of the work.
Days 6–8: review against the machine
Have the responsible engineer check the draft against the applicable design and service information. Resolve discrepancies with the source owner.
Ask an intended reader to work through the information in a suitable review setting. Can they identify the machine, understand prerequisites, locate the part, and recognize when to stop and ask for help?
Where practical work is involved, use the organization’s normal safety controls and competent personnel. A content pilot is not permission to bypass them.
Days 9–10: release the agreed output and test a change
Publish only content that has completed the agreed approval process. Test customer or technician access using the role they will actually have.
Then make a controlled representative revision. Check which related information needs updating and how the previous version remains identifiable.
If unresolved source or approval issues prevent release, record them as findings. The pilot can still show exactly what must be fixed before scaling.
Decide what the result supports
Review the deliverables alongside engineering effort, unresolved gaps, usability, revision handling, and access.
A successful pilot should give the team a credible basis for estimating the next machine family. It should also reveal work the platform does not remove.
Soply can demonstrate a workflow using existing recordings, CAD, and files. Book a pilot-scoping conversation and bring one configuration, one service task, and the people who can confirm the result. Keep the initial commitment specific enough to learn from.
