TL;DR
- Document the inputs, decisions, owners, credentials reference and recovery path, then ask the receiving operator to run a failure drill. Screenshots alone describe a happy path.
- Process Street suits repeatable operational checklists and approvals. Scribe and Tango suit visual instructions for interface work. Git-backed documentation suits versioned code, schemas and runbooks. Combine them only where each serves a distinct need.
- Store secrets in the authorised manager and link ownership/access procedures. Do not make a handover document another credential archive.
- Judge completeness by whether a new operator can explain and recover the workflow. Price authoring, maintenance and drills as well as software seats.
Hand over a contract, not a tour
A workflow can keep running after its builder leaves while becoming impossible to change safely. The replacement operator sees a diagram and screenshots but does not know why a field is required, which client owns a key or how to recover a partially completed paid enrichment job.
The handover contract should say what starts the workflow, which inputs are valid, which decision it makes, where outputs go and what counts as success. Record failure states, the last safe restart point and who can authorise a change. A screenshot helps someone find a button; it rarely explains those semantics.
Our GTM coding-agent guide covers development environments. Here the focus is knowledge transfer for an already-defined process. The agent framework comparison provides architecture context, not a substitute for the particular workflow's operating contract.
Choose the documentation layer
| Layer | Best use | Useful capability | Limitation |
|---|---|---|---|
| Process Street | Repeated human operations | Workflow runs, logic and approvals | Checklist completion does not prove external system correctness |
| Scribe | Capturing interface instructions | Screenshot editing/redaction | A guide needs decision and recovery context added |
| Tango | Visual guides and in-app guidance | Recorded steps, sharing and guidance | Plan controls and UI drift need maintenance |
| Git/GitBook | Technical contracts and runbooks | Version history and code-adjacent review | Nontechnical operators need a usable reading surface |
Process Street
Process Street documents conditional logic and approval tasks. That makes it relevant when the handover includes repeated human work such as approving a list, checking a reconciliation or signing off a cutover.
Choose it when responsibility and repeated execution need to be visible. Design steps around actual evidence: a link to the reconciliation report, destination receipt or exception decision. A checked box without a supporting result can hide an incomplete operation.
Its pricing describes paid members who create, edit and run workflows, with commercial plan conditions. Obtain the current seat, run and feature scope. Avoid buying it merely to store prose that rarely becomes a workflow; a simpler runbook may be sufficient.
Scribe
Scribe's screenshot-redaction guidance describes pre-capture and manual controls. Its Smart Privacy Screen page identifies enterprise packaging. Check the actual feature/plan before recording client data; do not assume every capture tier protects every sensitive value automatically.
This is useful for showing where an operator clicks in a CRM or outreach tool. Capture a representative safe environment, then add the reason for the step and what to do when the expected screen differs. Keep credentials and personal data out of the guide.
Choose it for interface-heavy handovers where capture reduces authoring effort. Avoid treating the generated sequence as complete recovery documentation. Price required editors, desktop/browser coverage, exports, redaction and access controls from the current offer rather than an unverified per-user figure.
Tango
Tango's current site describes recording workflows into guides with screenshots and descriptions, plus sharing and in-app guidance. Its pricing distinguishes plans and limits; the free card currently lists five shared workflows, browser capture and up to ten workspace users.
This fits teams wanting a visual explanation near the interface where work happens. Evaluate one ordinary path and one exception path. A guide that works only for the author's administrator permissions may confuse a receiving operator with a restricted role.
Choose it when the capture/guidance experience is useful and the commercial tier supports the intended audience. Avoid buying more guide capacity while leaving the decisions and ownership undocumented. Check paid plan billing, guidance features, export, privacy and workspace access before procurement.
Git-backed documentation
For code-driven workflows, keep schemas, mapping definitions, run commands and change notes beside the code where practical. A reviewed change can update the implementation and operating contract together. Use synthetic fixtures rather than copying live client records into the repository.
GitBook's pricing page describes GitHub/GitLab synchronisation and separates site plans from user pricing. The Essential site tier is $65 monthly on annual billing, with users priced separately at $12 per user monthly. Confirm the current entitlement in the order.
Choose a Git-backed route when versioning and technical review matter. Avoid it as the sole handover surface if the operator cannot find or understand the runbook. A simple internal documentation site can connect the technical contract with visual guides without duplicating the source of truth.
Build the operational pack
Include purpose, trigger, input schema, acceptance rules, provider dependencies, destination mapping, owner and last verified date. Explain why a rule exists where that knowledge prevents a future mistake. A headcount threshold without its commercial rationale is likely to be changed casually.
Reference the credential store and provider owner. Describe scopes, rotation and revocation without storing values. Record whether the workflow acts under a user delegation or a client service account. Include subscriptions and expiry/renewal responsibilities so a payment failure does not become a mysterious integration outage.
For recovery, state the stage boundary and what can be safely repeated. A paid data response already saved should not be purchased again just because the CRM write failed. A timed-out write may require checking the destination before retrying. Keep the operation ID and last confirmed output.
Use the ABM Account Scoring Template to preserve the evidence and judgement behind account prioritisation. The agent monitoring guide covers the diagnostic layer; link the actual dashboard/query and explain which symptom requires intervention.
Drill twenty workflows with three operators
For a hypothetical handover of 20 workflows, assign a primary and backup among three operators. Have the receiving operator run a normal fixture, explain a rejected input and recover one simulated failure without the author narrating the answer. The author observes and records gaps.
Choose failures that expose meaning: revoked token, missing mandatory field, provider quota exhaustion, partial destination write and stale trigger. A drill should establish what the operator should stop, what can resume and whom to contact. Do not test by creating unauthorised live customer actions.
Suppose each workflow needs 45 minutes to document and 30 minutes to drill. That is 25 hours total. At an assumed loaded $60 per hour, initial work costs $1,500. If five workflows fail the drill and require an additional hour each, the cost rises to $1,800. These are planning assumptions, not measured completion times.
The acceptance result is per workflow. If 15 pass and five need repair, report 15 ready rather than declaring the whole handover complete. Retain the gap and retest the repaired operation. A confident new operator is useful evidence, but the fixture's actual outcome still matters.
Cost documentation that stays current
Assume the 20 workflows each need 15 minutes of monthly review. Maintenance is five hours, or $300 monthly at the assumed rate. Add the selected software plan. A document that drifts after a schema change is cheap to store and expensive to rely on.
For an illustrative GitBook $65 site tier with three billed users under the observed annual-billing basis, software is $101 monthly equivalent: $65 plus three times $12. That reference does not establish private-site visitor access: confirm the audience-authentication tier separately, as well as additional sites/users. Annual commitment and implementation remain separate.
Do not buy every documentation product by default. Use a versioned runbook for the contract, visual capture for difficult interface steps and an operational checklist where repeated human sign-off matters. Assign one authoritative home for each fact, then link rather than copy.
The best purchase is the smallest combination that makes recovery and change possible without the original builder. Prove that with a receiving operator's drill, then maintain the pack when implementation changes.
FAQ
Are screenshots enough for a handover?
They explain interface steps but rarely capture inputs, decisions, side effects and recovery. Add the operational contract and exception paths. Keep screenshots only where they help the receiving operator find or understand a specific action.
Who should own the documentation?
The workflow owner should remain accountable, with updates attached to implementation changes. The author can move on, but a named primary and backup need access and responsibility. Review the pack after incidents and dependency changes.
Should secrets appear in the runbook?
Use store references, owners and access procedures instead of values. The receiving operator should obtain access through the authorised identity process. That keeps retrieval, revocation and auditing separate from ordinary document sharing.
How do we know a handover is complete?
Have the receiving operator run an agreed normal and failure fixture, explain the result and recover within the written policy. Record gaps and retest them. Reading the document or attending a walkthrough alone does not prove operational readiness.
