Offboard client forms

A client can leave with the website still online and the form operation already broken. The form submits, but alerts still go to the old agency, provider keys belong to the wrong account, nobody owns the review queue, and the privacy policy describes a workflow that no longer exists.

A WordPress form client offboarding checklist closes those gaps before access changes hands. The goal is not to preserve every tool or automation. It is to leave the client with a form workflow they can understand, test, and operate without calling the former WebMaster for hidden context.

Inventory the form operation, not just the forms

Start with every live form that creates work for the client. For each one, record:

• the page URL and Form Source;
• the business purpose and current owner;
• where submissions and AI results are reviewed;
• notification recipients and escalation contacts;
• connected actions, webhooks, or downstream tools;
• the provider path used for AI requests;
• the retention or deletion rule; and
• the last controlled test date and result.

Do not copy passwords, API keys, or customer submissions into the handoff document. Record the account owner, transfer status, and approved credential-sharing method. The WordPress guide to roles and capabilities is a useful baseline for replacing shared administrator access with named accounts.

Decide what transfers, what rotates, and what stops

Every dependency needs one explicit disposition:

• Transfer: The client already owns the account and keeps it.
• Rotate: The client will keep the service, but credentials or access must change.
• Replace: The agency-owned service must move to a client-owned alternative.
• Stop: The automation is no longer approved or useful and should be disabled after a safe cutoff.

Sentient Forms can run through a site-owned Direct OpenRouter key or through Managed Execution. Those paths create different ownership tasks. A direct key should belong to an account the client controls. A managed-service subscription should have a named billing and operations owner. The guide to managed AI execution for WordPress forms can help the client choose the path they are prepared to operate.

If nobody can name the owner, renewal date, credential location, and manual fallback, the workflow is not ready to transfer.

Leave a plain-language runbook

The client should not need implementation knowledge to handle the next submission. Write one page for the person on duty:

1. Where do I see new submissions?
2. Where do I see the AI result?
3. What decisions must a person make?
4. What do I do when the result is missing or wrong?
5. Who changes a prompt, route, recipient, or provider setting?
6. How do I disable the action without breaking the form?
7. What evidence shows a controlled test passed?

Use screenshots only when they clarify a stable step. Names, URLs, owners, and expected outcomes are more useful than a gallery of controls that will age after the next plugin update.

Verify privacy and data handling

Offboarding is a good time to remove unnecessary data access. Review which form fields are sent for AI analysis, who can view stored submissions, how long records stay available, and whether former staff or vendors still have access.

WordPress provides a starting point for documenting privacy and personal-data handling. Your actual notice still needs to match the site’s tools, contracts, and legal obligations. The Sentient Forms guide on sending only the fields an AI action needs can help reduce unnecessary exposure before the handoff.

Respect the current Form Source boundary

Sentient Forms supports Gravity Forms, Contact Form 7, WPForms, and Elementor Pro Forms in the current public release. Gravity Forms has the deepest native integration. Contact Form 7, WPForms, and Elementor Pro Forms use after-submission review through the Sentient Forms Submission Ledger.

That means a handoff runbook should name the real review surface for each form. Do not promise native notes, validation blocking, notification suppression, webhook controls, or realtime behavior across every builder. Use the current WordPress.org listing as the public support reference.

Test the WordPress form client offboarding before access changes

The incoming owner should perform the final test while the outgoing team can still help:

• submit a controlled entry through the public form;
• confirm the stored submission appears in the expected surface;
• confirm the AI action runs where that lifecycle is supported;
• inspect the visible result and human decision step;
• verify the notification and escalation path;
• exercise the manual fallback; and
• record the test ID, date, owner, and outcome.

Do not substitute a settings screenshot or direct API call for this test. The incoming operator needs proof from the same path a visitor and staff member will use. The client rollout test checklist is a useful template.

Close with owners and dates

A form-operations handoff is complete when the client has accepted the inventory, each dependency has a disposition, named operators have access, the runbook matches the live site, and the controlled test has passed. Add dates for account transfer, credential rotation, subscription changes, and agency access removal.

If the client wants to keep AI review, browse the Sentient Forms action library together and keep only the actions with a clear owner, decision, and fallback.

Frequently asked questions