Begin with a bounded rule
Help Scout documents workflows as conditions and actions, with automatic and manual forms. Its guide explains that automatic workflows run once per conversation while manual workflows can be applied repeatedly. These are product-specific mechanics, checked as a reference. The design process below is AMZ12’s independent operational guidance and should be adapted to the chosen helpdesk.
Choose a task with a clear input and result, such as routing delivery-status questions to the fulfillment queue. Write down what the rule should recognize and what a human still needs to decide. Start with one responsibility rather than a sequence that tries to resolve every enquiry.
Define the matching evidence
List the fields the rule relies on and how trustworthy they are. A subject line can be ambiguous; an order reference may be missing or mistyped. Include examples that should match and similar examples that should stay outside the rule.
Use fictional conversations to build the test set. Include a customer discussing delivery while also reporting a damaged item. If the rule cannot safely distinguish the cases, route the conversation for review rather than assuming that one keyword expresses the whole request. Keep the original message visible to the receiving agent.
Prefer visible internal actions first
Begin with a label, assignment or internal reminder where the system permits. These actions make the rule’s interpretation visible while leaving an agent to check the answer. Review the results before adding an automatic customer reply or closing a conversation.
For any external message, identify the facts it can safely state. A general acknowledgement may be appropriate while a shipment-specific promise requires verified order information. Keep templates short enough that staff can recognize when the actual case falls outside their wording.
Specify the human handoff
Write the receiving role, required information and expected next action. Decide what happens when that person is absent or the queue is not monitored. A label is an aid to organization; it does not by itself establish that someone owns the case.
Give agents a way to mark incorrect routing and explain why. Collect those examples in a review queue with an owner. Avoid relying on a colleague to remember every misclassification until the next team meeting. Feedback should be part of the operating process, not an informal complaint about automation.
Rehearse interactions and repeats
Test the new rule alongside existing rules using the authorized evaluation setup. Inspect a conversation that changes subject, receives another reply or moves between teams. Look for conflicting assignments, repeated responses and cases that become closed before the requested work is complete.
Record the intended order of actions and the method for pausing the rule. Ask a colleague to follow the pause instructions without help from the person who configured it. A recoverable rule gives the team room to learn without turning every unexpected case into a developer emergency.
Review outcomes at the case level
Sample matched and unmatched conversations after release. Check whether the recipient had the information needed and whether the customer received an accurate response. Count recurring errors by cause so the team can adjust the condition, wording or handoff separately.
Retire rules that no longer fit current products, carriers or team responsibilities. Keep a change record and a named owner for each active workflow. Good automation removes a repeatable clerical step while leaving clear accountability for the customer’s unresolved problem.
Official reference: Help Scout Support: getting started with workflows. Source checked on 29 October 2026. AMZ12 analysis and suggested checks are independent editorial guidance.