Choose one action, not the whole relationship.
“Automate our estimates” bundles together several jobs: finding the request, assigning a reviewer, understanding what the customer wants, preparing an answer and agreeing the work. Those jobs do not need the same treatment.
Start with one action. Describe its input, the result you want and what that result must not imply. “Place an exterior-window request in the office review queue” is different from “confirm a window-cleaning visit.” A queued request still needs someone to review it.
If you have several processes competing for attention, choose the first customer path before making this list. Then identify the working steps to keep. Changing every part of the process is not a requirement.
Separate a rule, a draft and a decision.
A rule-based action follows a specific condition using current information. It may be worth considering where the required input, allowed result and exception are clear. A familiar rule is still only a proposal until the chosen software and actual arrangement have been checked.
A reviewed draft helps a person prepare an answer or summary. The person checks it against the source before it is used. A well-written draft can still omit a correction or turn a preference into a promise.
A human decision stays with someone who can judge the situation and make the commitment. In the example below, agreeing an unusual service request or an unconfirmed date stays with the responsible teammate.
Clarify first is the fourth useful answer. Missing information or responsibility is a reason to resolve that gap before selecting automation. Putting AI in the middle does not supply the missing business decision.
Give four actions four different treatments.
Fictional example: Rosa owns a window-cleaning business. Ben reviews estimate requests. A customer asks about outside windows, asks whether skylights are included and says Friday would be convenient. Nothing has been booked.
On a small screen, swipe or scroll sideways to read the full table.
| Action | Proposed treatment | Boundary to keep |
|---|---|---|
| Route the request for review | Consider a rule for requests explicitly marked as exterior-window estimates. | Ben has agreed to review that queue. Missing or conflicting request types need a separate review route. |
| Summarize the customer's questions | Consider an assisted draft that points back to the current request. | Ben checks the summary before relying on it. The skylight question and Friday preference must remain questions, not commitments. |
| Answer the scope and date questions | Keep the decision with the teammate responsible for those answers. | The person checks the service scope and availability. Neither the queue rule nor the summary confirms a visit. |
| Handle a request whose current version is missing | Clarify first. | Find the current request and its owner before deciding the next action. Do not fill the gaps from an old summary. |
These are proposed choices for the fictional business, not features promised by a product. One process can use all four treatments without becoming fully automatic.
Make the review and the exception practical.
“A person checks it” needs an actual arrangement. Name who reviews the draft, what source they check, when review happens and what remains pending until then. If nobody can take that role, do not treat the review as covered.
For a rule, describe the case it cannot decide. Where does that request remain visible, and who accepts the next action? An exception route that nobody watches moves the uncertainty rather than resolving it.
For AI-assisted work, NIST's voluntary AI Risk Management Framework calls for defined tasks, responsibilities and human oversight. This worksheet is our practical discussion aid; it does not certify a tool or establish that a proposed use will work.
Rehearse the awkward case before relying on the easy one.
Use fictional information in a non-sending practice setting. Try the ordinary request, then change one fact: the customer corrects Friday to Thursday, the request type is missing, or the reviewer is unavailable. Write the expected result before looking at what happens.
Rosa and Ben could check whether a corrected date remains a preference in the draft and whether the unanswered skylight question survives. They should also check whether an incomplete request stays available for a person instead of receiving an invented answer.
Do not submit a real inquiry, booking or message as part of this exercise. A rehearsal can reveal a problem; passing it does not prove every future request will work. Use the AI-reply review guide for the detailed draft check.
Write down the treatment and the next check.
Download the blank follow-up automation decision worksheet (CSV). Use one row per action. Reference your own records without copying private customer conversations into a shared worksheet.
Record the proposed treatment, its limits, the responsible person and the case still to check. Then compare available options against that specific job. A demonstration or completed worksheet does not add a capability to an agreement.
Revisit the decision when the service, source information, staffing or chosen software changes. The useful result is a clear division of work your team can explain and examine, with unresolved decisions still visible.