Web Manuals alternatives:
document control, connected.

See the highlighted block above the contents list. The rest of this article describes what a dedicated document-control tool does well, where the seam shows when documents live apart from the safety and quality work that acts on them, and the simple test for evaluating an alternative.

Start with credit where it is due. Controlling aviation manuals is real work, and a product built specifically for it gets a lot right. Web Manuals is well-regarded for good reasons.

Authoring and revision. A purpose-built editing surface for long, structured manuals is not a small thing. Editing the Operations Manual in a tool that understands chapters, cross-references and revision marks beats editing it in a generic word processor. A dedicated tool does this well.

Versioned, controlled revisions. Every change produces a numbered revision with a clear before-and-after. The current controlled version is unambiguous, and superseded versions are kept for the record. This is the spine of document control and a mature tool gets it right.

A controlled approval route. A manual revision should not go live because one person edited a file. A document-control tool routes a revision through review and approval before it is published, so the controlled copy is the approved copy.

Reliable distribution. The right people see the current revision, with read tracking so the operator can show that the people who must read a document have seen it. For a regulated operator that is load-bearing, and a dedicated tool handles it well.

None of this is in dispute. If the only job were “keep our manuals authored, revised and distributed,” a focused document-control tool is a sound choice. The argument of this article is not that the tool is weak. It is that the job rarely stops at the edge of the document.

A controlled document does not sit still on a shelf. It is constantly acted on by the rest of the safety and quality operation. Watch one revision through its life and the seam appears.

An auditor reads a procedure during an audit and writes a finding: the ground-handling procedure no longer matches how the ramp actually works. That finding is about a specific document — the Ground Operations Manual — and a specific section of it. A corrective action is raised to update the procedure. Someone edits the document, a new revision is approved, and it is published to the ramp crews.

Every step in that story crosses the boundary of the document tool:

• The audit that tested the procedure lives in the safety or quality system, not the document tool.
• The findingthat flagged the procedure as out of date lives there too — and the best it can do is name the document in free text, because the document is in a different system.
• The corrective action that drove the change lives in yet another place, with its own status and its own deadline.
• The revision that resulted lands back in the document tool, with no durable thread back to the finding and the corrective action that produced it.

When documents live in one system and the audits, findings and corrective actions live in another, three things get harder. A finding cannot point at the exact revision that needs to change — it can only describe it. A revision cannot show which corrective action drove it — the connection is in someone's memory or a spreadsheet column. And an auditor asking “show me the corrective action that produced this revision” gets an answer assembled by hand across two systems rather than read straight off the record.

The common fix is an integration project — wire the document tool to the safety system so a finding can store a reference to a document. That helps, but it copies the link rather than being the link. The reference is a pointer between two systems, and pointers drift: a revision lands, a system is upgraded, an export is re-run, and the two sides quietly fall out of step. The seam moves; it does not close.

eAviora's answer is to put the controlled document on the same connected operation as the work that acts on it, rather than in a separate system bridged by an integration. The document-control discipline is fully there; what changes is the neighbourhood it lives in.

A named four-eyes route.Every revision runs a named reviewer to approver to publisher route. The reviewer, the approver and the publisher are named people, not a single signature — so no one person authors, approves and publishes a controlled document alone. The route is a workflow that cannot skip a step: a revision reaches the published state only by passing each stage.

Publish-time read-acknowledgments. When a revision is published, the people who must read it are asked to acknowledge it, and the acknowledgments are recorded against that revision. The operator can show not only that the current revision is controlled, but that the people who needed to read it did.

A review-cadence reminder.A controlled document carries a review cadence, and a reminder fires when a document is due for review — so a manual is never quietly left to go stale between audits. Review is a scheduled obligation on the record, not a calendar entry someone has to remember to keep.

Versioned revisions are the audit trail.Each controlled document carries its full revision history — Operations Manual v3 supersedes v2 supersedes v1 — and that chain is the audit trail. There is no separate log to reconcile; the revisions are the record.

The difference from a standalone tool is what sits next door. Because the audits, findings, corrective actions and occurrences are on the same connected operation as the documents, the links between them are the records themselves, not references copied between systems:

• A findingraised in an audit can point at the exact controlled document and the revision that needs to change — not a name typed into a text box, but the actual document record.
• A document revisionthreads back to the corrective action that drove it, so “why did this revision happen?” is answered by the record, not by recollection.
• An auditor's question— show me the finding, the corrective action and the revision that resulted — is read straight off the connected records, not assembled across two tools.

And because there is no integration in the middle, there is nothing to drift and nothing to maintain. The finding and the document are not two systems agreeing with each other; they are the same operation. That is the half of the job a document-control tool, on its own, cannot do.

The relevant surfaces: Document Control, QMS (audits and findings), Compliance. To discuss your operation, contact us.

When you compare a document-control tool with a connected operation, do not compare on the editing surface alone — a focused tool will usually win that round, and it is the wrong round. Compare on whether the document stays connected to the work that acts on it. Three questions settle it.

One: can a finding point at a revision?Raise a finding against a real procedure in the tool you are evaluating. Can the finding reference the exact controlled document and the specific revision that needs to change — as a record, not a typed-in name? If the document lives in a different system, the honest answer is usually “only by free text.”

Two: can a revision name the corrective action that drove it? Open a published revision and ask the tool why it happened. On a connected operation the answer is the corrective action record threaded to the revision. With a standalone tool and an integration, the answer is a pointer that may or may not still be accurate.

Three: does review happen on schedule without a human remembering? Set a review cadence on a document and check that a reminder fires when it is due — so a manual is not quietly stale between audits. Schedule is cheap to claim and easy to verify; ask to see it fire.

Run those three on Web Manuals, on eAviora, and on any other candidate. If your documents and your findings rarely need to point at each other, a dedicated document-control tool may be exactly right and a connected operation is more than you need. If they point at each other constantly — which is the normal state for a maturing safety and quality function — the connected operation is doing the half of the job the document tool leaves on the table. That is the test, and it is a fair one to put to every vendor in the bake-off, including this one.

For a worked example of evidence and corrective actions running on the same connected operation, see IOSA compliance: ISARPs, evidence and CAPA.