Keep an inbox routing rule change log

Name the rule and the person who can change it

Write each routing rule as a short statement with a trigger, a destination, and an exception path. Give it an identifier and a version. Name the owner who can approve a change; an assistant may propose a change but should not alter a live rule that affects customer commitments, billing, or employee matters.

The owner does not have to approve every typo fix, but the boundary should be explicit. A rule that routes refund requests, legal notices, or safety complaints needs a higher approval level than a newsletter filing rule. Put that level in the log so the next person does not have to guess.

Record the rule as it existed, not as it reads today

When a rule changes, preserve the old version with its effective time and the reason for the change. Do not overwrite the earlier definition. A later reviewer should be able to see which rule was live when a specific message was routed.

Capture the trigger, destination, priority, exceptions, and the systems where the rule runs. If the rule exists in more than one place, record each location and the person who keeps them aligned. A rule that is documented in a note but implemented differently in the mail tool is a conflict, not a source of truth.

Test a change on a small set before it goes live

Build a test set that includes an ordinary message, a message from an unknown sender, a message with an attachment, a message that matches two rules, and a message that should match none. Predict the destination before running the test, then compare the actual result.

Record the test date, the rule version, the examples used, and the results. Use synthetic or properly protected messages rather than live customer mail. If the rule fails, keep the failed result and the correction; a clean test log that hides the failed attempt is less useful than an honest one.

Separate sorting from deciding

An assistant can apply a rule, label a message, and route it to a named queue. The assistant should not decide whether a customer is entitled to a refund, whether a contract notice is valid, or whether a message creates a legal deadline. Those decisions stay with the owner who is authorized to make them.

Write the boundary into the rule. If a message matches a sensitive category, the rule should route it with a neutral label and a request for owner review, not with a disposition. A neutral label such as needs owner review is safer than a conclusion such as approved or resolved.

Watch for silent drift

Rules drift when a mailbox is renamed, a sender address changes, or a new message type appears. Review the rule against actual traffic on a fixed cadence. Count messages that matched no rule and messages that were manually rerouted, because both can reveal a gap.

Do not treat a low exception count as proof that the rule works. The team may be quietly fixing misroutes without logging them. Ask for the manual corrections and add them to the review. A rule that depends on private repair is not stable.

Close the change with evidence and a review date

After a change goes live, confirm that the destination queue received a test message and that the old rule no longer applies. Record the confirmation, the person who checked it, and the time. If the change affects a customer-facing response, verify that the approved response text is also current.

Set a review date and an owner. At the review, sample routed messages, check the exception log, and decide whether to keep, revise, or retire the rule. Retiring a rule is a change too, and it needs the same record so a later reader does not assume the route still exists.

Questions and operating boundary

Source

sba.gov provides authoritative background and does not endorse this service.