Automation Handover: What to Document for a Client
Good WordPress automation documentation is not a nice-to-have. It is the difference between a client who can operate a site independently and one who calls you every time a workflow stops firing. If you are handing over a site built on Krom Automation, this guide covers exactly what to capture, what to abstract for non-technical clients, and how to use the built-in notes field and export features as a documentation layer that travels with the site.
Most automation documentation fails because it describes what a workflow does, not why it exists or what happens when it stops. A client reading “Send Email on User Registered” learns nothing useful.
A client reading “Sends the welcome email with the login link. If this fails, new users see no confirmation and email support volume spikes” knows what to watch and when to panic.
The guide below is written for agency owners and developers handing off client sites. The same principles apply if you are building internal tooling and documenting for a team rather than a client.
Browse the full Krom Automation feature list to see what is available before you decide what needs documenting.
Why Automation Documentation Fails at Handover
The standard handover document covers credentials, hosting details, and plugin licences. It almost never covers the automation layer. That gap matters because automations are invisible when they work and catastrophic when they do not.
A silent automation failure on a WooCommerce site can mean hundreds of orders processed without fulfilment notifications. On a membership site it can mean new subscribers who never receive their access email.
Neither failure throws an error the client sees. They only surface when a customer complains, and by then the damage is done.
An undocumented automation is a liability that transfers with the site. The client inherits the risk but none of the context needed to manage it.
There are three failure modes that handover documentation must prevent:
- The trigger changes and nobody knows the workflow depended on it. A form is renamed or a post type is removed. The workflow still shows as active. Nothing fires.
- A plugin that a workflow depends on gets deactivated or updated. WooCommerce, a CRM plugin, or a forms plugin changes its hook structure. The workflow breaks silently.
- The client edits a workflow without understanding the downstream effects. They change a delay from 24 hours to 0 hours because they want emails faster. Three actions that depended on that delay window now fire simultaneously.
Good documentation does not prevent all of these. It makes each one diagnosable in under 10 minutes rather than 3 hours.
What to Document: The Non-Negotiable List
For each workflow on the site, capture the following. This is the minimum. Anything below this and the handover is incomplete.
- Business purpose in one sentence. Not a technical description. What happens in the business if this workflow stops running?
- Trigger: what fires it, and under what conditions. Name the exact trigger, any conditions on the trigger, and what the source is (a specific form, a specific post type, a specific user role).
- Actions in sequence. List every action in order. Include delays as part of the sequence, not as an afterthought.
- Dependencies. Which plugins must be active for this workflow to run? If the FluentCRM integration powers a contact tagging step, note that FluentCRM must stay active and at a minimum version.
- Owner. Who is responsible for this workflow? Whose job breaks if it fails?
- Last tested date and tester. A workflow that has never been tested in production is an assumption, not a fact.
- Failure behaviour. What does the client see or not see when this fails? How do they check the execution log?
Seven fields per workflow. On a site with 12 active workflows, that is roughly 4 hours of documentation work.
A developer billing at $120/hour should charge for it, and most should. The alternative is a support ticket backlog that costs more.
Using the Krom Automation Notes Field
Krom Automation includes a notes field on every workflow, visible inside the workflow settings panel. This is not a hidden feature. It is the right place to store the business purpose and dependency information for each workflow, because it travels with the workflow when the site is handed over.
The notes field renders inside the canvas view. A client or future developer opening a workflow sees the note before they see anything else. That means documentation that lives in a separate Google Doc or Notion page, where nobody will look, becomes documentation that is impossible to miss.
The workflow settings documentation covers the notes field alongside the run-once setting, pause controls, and import/export. Read that before you build your first client workflow so the notes habit is built in from the start, not retrofitted at handover.
Our recommended note format for each workflow:
- Purpose: [one sentence business reason]
- Trigger source: [form name, post type, or event]
- Depends on: [plugin names and minimum versions]
- Owner: [name or role]
- Last tested: [date]
Paste this as plain text into the notes field on every workflow before you hand over. It takes 3 minutes per workflow and eliminates the most common support call: “We changed something and now the emails stopped. Can you look at it?”
Export as Portable Documentation
Krom Automation supports workflow export as JSON. Each exported file contains the complete workflow structure: trigger configuration, all actions, delays, conditions, merge tags, and settings. The notes field travels with the export.
For a client handover, export every active workflow and include the JSON files in the handover package alongside credentials and hosting details. This gives you three things:
- A point-in-time snapshot of every workflow as it was at handover
- A restore path if a workflow is accidentally deleted or corrupted
- A portable copy that can be imported to a staging or development environment for testing
The JSON export is also your migration safety net if the client ever moves hosts. Importing 12 workflows from JSON takes under 10 minutes. Rebuilding 12 workflows from memory takes a day.
The export file is the closest thing to version control that most WordPress automation setups will ever have. Treat it like a build artefact, not an afterthought.
Store the exports in the same place as the site backup. If the client uses a project management tool, attach the JSON files to the project closeout ticket so they are searchable later.
What to Abstract for Non-Technical Clients
Not every client needs to understand conditional branching or merge tags. Most need to understand three things: what the workflow does, what it costs them if it stops, and how to tell if it has stopped.
Build a separate one-page summary for the client. This is distinct from the technical documentation above, which is for the next developer. The client summary covers:
- Workflow name (match the name in Krom Automation exactly, so they can find it)
- What it does in plain English (two sentences maximum)
- How often it should run (on every order, daily, on new user registration)
- How to check if it is running (point them to the execution log in the analytics dashboard)
- Who to call if it stops (your support contact or their internal team)
The analytics dashboard in Krom Automation shows total executions, success rate, failed execution count, and an execution trend chart. A client who checks this once a week will catch a silent failure within 7 days. A client who has never been shown the dashboard will call you 6 weeks later wondering why conversion rates dropped.
Documenting Integrations Separately
Integrations deserve their own section in the handover document because they carry external dependencies the client controls, and those dependencies can change without warning.
For each external integration in use, document:
- Which service it connects to (Mailchimp, FluentCRM, Google Sheets, Slack)
- What credential or API key is stored in WordPress
- Who owns that credential (the agency or the client)
- What happens to the workflow if the API key is revoked or the account is closed
- Where to regenerate the credential if needed
If the site sends data to Google Sheets or Google Calendar, note which Google account owns the connection and what happens if that account loses access. If the site posts to social media via the social media integration, note the connected page, the connected account, and the token expiry behaviour.
Messaging integrations to Slack, Discord, Twilio or Telegram are particularly fragile at handover because they use workspace-level credentials the client may rotate during an internal IT change. A single paragraph in the handover document explaining this saves a support call.
For form-triggered workflows, link the integration doc so the next developer can verify the setup. For example, a workflow triggered by Gravity Forms or WPForms will break if the form is renamed or the field mapping changes. That is worth one sentence in the handover notes.
The Handover Documentation Structure
A complete handover documentation package for a site running Krom Automation has four parts. The table below shows who reads each part and what they do with it.
| Document | Audience | Format | Lives Where |
|---|---|---|---|
| Workflow notes (per workflow) | Next developer | Plain text in Krom Automation notes field | Inside the plugin, travels with export |
| Technical handover document | Next developer or internal team | Markdown or PDF | Project folder, handover package |
| Client summary (one page) | Client or site owner | PDF or shared doc | Client’s preferred tool (Notion, Google Drive, email) |
| Workflow JSON exports | Next developer, disaster recovery | JSON files | Site backup folder, project archive |
The technical handover document should list every active workflow, its dependencies, the credential owner for each integration, and the support contact. It does not need to explain how Krom Automation works. It needs to explain how this specific site’s workflows work.
Cost of Getting This Wrong
Skipping automation documentation is a pricing decision, even if it does not feel like one. The cost lands somewhere. The question is whether it lands on your support hours or on the client’s operations.
| Scenario | Without documentation | With documentation |
|---|---|---|
| Workflow breaks 3 months post-handover | 2 to 4 hours to diagnose without context. $240 to $480 in unbilled support at $120/hr | Client checks execution log, finds the failed step, calls you with the error. 30 minutes to fix |
| Client changes a plugin and breaks an integration | Root cause unclear. Developer rebuilds from memory. 3 to 6 hours | Dependency listed in notes. Developer restores from JSON export. Under 1 hour |
| New developer takes over the site | Discovery audit needed. 4 to 8 hours billed to client | Technical handover document covers it. 1 hour onboarding |
| API key rotated, integration breaks | Unknown which workflows are affected. Full audit required | Integration doc lists credential owner and regeneration steps. Fixed in 20 minutes |
Across an agency running 20 client sites with automation, the difference between documented and undocumented handovers is realistically 40 to 80 support hours per year. At $120/hour, that is $4,800 to $9,600 in unrecoverable time.
Charging $300 to $500 per site for a documentation package at handover is not overhead. It is margin recovery.
Charging for handover documentation is not adding a line item. It is pricing the risk correctly instead of absorbing it silently in your support queue.
Testing Before You Hand Over
Documentation of an untested workflow is documentation of an assumption. Before any handover, run every workflow through the simulator.
Krom Automation includes a workflow simulator for dry-run testing with zero side effects. It runs the workflow logic without sending emails, creating posts, or firing HTTP requests. Use it to verify that every branch executes as expected and that merge tags resolve correctly.
For workflows that cannot be fully validated by simulation, such as those that depend on a live payment gateway or a production form submission, document the test procedure in the handover notes. Describe the exact steps, the expected output, and how to check the execution log to confirm it ran. The client or next developer should be able to run the test themselves in under 15 minutes.
If a workflow has never been tested in production, say so in the handover document. An honest note that says “validated in staging but not confirmed in production” is more useful than silence. It tells the next person where to start.
Multi-Site and Agency Considerations
If you are managing automation across multiple client sites, the documentation burden multiplies quickly. The answer is not to document less. It is to standardise the documentation format so each site takes less time.
We cover the broader strategy for WordPress automation across multiple client sites in a separate guide, including how to build reusable workflow templates and what to centralise versus what to configure per site. The short version: standardise the workflow structure, standardise the notes format, and export templates from your reference build rather than rebuilding from scratch for each client.
Krom Automation’s import/export system is designed for exactly this. Build a workflow on one site, export the JSON, and import it to a new client site in under 2 minutes. The notes field travels with the import, which means your documentation template travels too.
For agencies evaluating the cost model across client sites, the per-site cost analysis we published covers what automation tooling actually costs at 1, 5, 10 and 20 sites, including licence costs, time costs, and the break-even point between free and Pro tiers.
Also from wpRigel
Pollify is wpRigel’s Gutenberg-native poll, survey and quiz plugin. Polls are built as real blocks inside the block editor, so there are no shortcodes to paste and no separate interface to learn. It pairs naturally with automation workflows that trigger on user responses.
Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K to jump anywhere, search everything, and run admin actions without clicking through menus.
For developers managing client sites, it is the fastest way to navigate without knowing every menu path. It is the only command palette with real WooCommerce order, product and customer commands built in.
Our Verdict
If you are handing over a WordPress site with active automations and you have not written workflow notes, exported the JSON files, and produced a one-page client summary, the handover is not complete. It will cost you or your client time within 6 months.
That is not a prediction. It is the pattern we see repeatedly across agency builds.
The tools to do this correctly are built into Krom Automation: the notes field, the JSON export, the execution log, the analytics dashboard, and the workflow simulator. None of them require extra setup. They require the habit of using them before you hand over, not after the first support ticket arrives.
Who should invest in this now: any agency handing over more than 3 client sites per quarter, and any developer who has ever spent a Saturday debugging an automation they built 8 months ago and cannot remember. Who can wait: teams where all automation is internal, the codebase is under version control, and the same developer maintains it indefinitely.
The free version of Krom Automation is available on the WordPress.org plugin directory with no trial period and no feature caps. If you are evaluating it for client work, start there and review the free vs Pro comparison before you decide whether the Pro integrations are worth it for your stack.
See the full Krom Automation pricing and plan details to find the right licence for your site count.
Frequently Asked Questions
Where does automation documentation live in Krom Automation?
Each workflow has a notes field inside the workflow settings panel. Text entered there travels with the workflow when exported as JSON, making it the most reliable place for handover documentation. It is visible to any developer who opens the workflow on the destination site.
What happens to workflows if a dependent plugin is deactivated?
The workflow remains active in Krom Automation but the affected triggers or actions will fail to execute. The failure is logged in the execution history with a per-step audit trail, which is how you diagnose it. Documenting plugin dependencies at handover is what makes this diagnosable in minutes rather than hours.
Can I export all workflows at once for a client handover package?
Krom Automation exports workflows individually as JSON files. For a full site handover, export each active workflow separately and bundle the files in the handover package. Each file is self-contained and can be imported to a new or staging environment without any additional configuration.
How does the workflow simulator help with handover testing?
The simulator runs the full workflow logic without executing any real actions, so you can verify trigger conditions, branch logic, and merge tag resolution without sending emails or modifying data. It is the right tool for pre-handover validation and for testing changes on a live site without side effects.
Is Pro required to use the notes field and JSON export?
No. Both the workflow notes field and JSON import/export are included in the free version of Krom Automation. You do not need a Pro licence to document and export workflows as part of a client handover.