Define done for every form request

A successful form submission proves that WordPress accepted a request. It does not prove that staff understood it, assigned it, replied, or finished the work. When those events share one vague status, old requests stay open forever and new ones get closed too early.

A definition of done gives each form workflow a visible finish line. It tells a Webmaster what evidence must exist before a request leaves the queue. That makes overdue work easier to find and client reporting less dependent on inbox archaeology.

Received is the start, not the finish

Many queues blur technical delivery and business completion. A contact request can be received but unreviewed. A quote can be reviewed but waiting for an estimator. A support request can have a reply while the underlying problem remains open.

Use four states that describe the work without pretending every form follows the same process:

State	Meaning	Evidence required
Received	The form source accepted the request	Native entry or enabled ledger record with a stable ID and time
Review available	A configured review step produced a result, or a person recorded a review	Result or reviewer note linked to the record
In progress	A named owner accepted the next action	Owner, next action, and deadline
Done	The workflow’s promised outcome occurred	Completion time and a short outcome reason

Do not infer one state from another. An AI summary does not assign an owner. A notification email does not prove a reply. A staff reply does not always complete a repair, refund, estimate, or access request.

Define done from the promise on the form

Read the form confirmation and any response promise beside it. The finish line should match what the visitor was told would happen next.

• A contact form may be done when a qualified reply is sent and recorded.
• A quote request may be done when the estimate is delivered or the request is declined with a reason.
• An access request may be done when access is granted, denied, or returned for missing proof.
• A repair request may be done when the work is completed or an appointment is accepted.

The form confirmation guide helps align the public message with the real next step. The response SLA guide helps set the deadline. Neither should define completion more broadly than staff can verify.

Use a small set of closure reasons

A done checkbox hides why the request left the queue. Add a short controlled list that fits the workflow. Keep free text for context, not for the primary outcome.

• Completed as requested
• Completed with an agreed change
• Declined or out of scope
• Duplicate of another request
• Withdrawn by the requester
• No response after the documented follow-up sequence

Choose only reasons the team can apply consistently. A label such as bad lead mixes opinion with outcome and makes later reporting hard to trust.

Require one owner before work can start

A request should not move to in progress because someone opened it. Require a named owner, a next action, and a deadline. If the normal owner is unavailable, apply the documented backup instead of leaving the request in a shared queue.

The submission ownership guide defines that handoff. The capacity-aware routing guide covers temporary backups. A Routing Recommendation can prepare a suggested destination and reason, but the business still controls the allowed routes and final assignment.

Keep review evidence separate from closure evidence

A review result helps staff decide what the request needs. Closure evidence proves what happened. They belong together, but they are not interchangeable.

Where the form builder retains a native entry, keep it as the source record. For Contact Form 7, or when a comparable native entry is unavailable, enable the Sentient Forms Submission Ledger for the relevant form before relying on after-submission results. Review who can access it and set retention for the records your process needs.

The Entry Summary action can prepare a staff-readable review aid. Keep the original submitted fields available for verification, and record the later completion event separately.

Do not let automation close the request by inference

A positive score, routing suggestion, or drafted reply can move work forward. None proves that the promised outcome occurred. Reserve the done transition for a deterministic event or a person who can verify the result.

• Sent reply recorded: may close a simple contact request.
• Appointment accepted: may close scheduling intake.
• Estimate delivered: may close quote preparation.
• Draft created: does not prove the reply was reviewed or sent.
• Owner suggested: does not prove anyone accepted the work.

Reopen only when new work exists

Do not erase a valid completion because the customer replies later. Reopen the request or create a linked follow-up when the new message changes the work. Keep the original completion time and reason so the queue history still explains what happened.

A reopened request needs a new owner and deadline. Otherwise it becomes an old completed item with hidden active work.

Test five paths before using the states

Choose one form and write the expected state changes for five redacted examples: a normal completion, an out-of-scope request, a duplicate, a requester who stops replying, and a completed request that later reopens.

For each example, name the owner, deadline, closure reason, and evidence. If two reviewers choose different outcomes, tighten the rule before applying it to live requests.

Review access and retention

Completion records can contain customer details, staff notes, or links to submitted fields. Show reviewers only what they need for the current task. WordPress documents the standard roles and capabilities model; verify the permissions added by the form plugin and review tools.

Keep closure reasons long enough to support the operating process, then apply the site’s retention policy. The form data retention guide is the companion check.

Define done for one form

Pick one form with an unclear queue. Write its four states, allowed closure reasons, required evidence, and reopen rule. Test the five examples before the next live request depends on it.