AI email triage for a small business means proposing where a message belongs and who should review it. A useful first pilot produces suggested labels and a review list. Your team can compare those suggestions with its own decisions before granting a system permission to move messages or contact customers.

For a Canadian service business, the relevant question is usually practical: did a new enquiry reach the right person, with enough information to act? A neatly sorted inbox is not enough if an important request lands in the wrong queue. I use the same workflow-first approach when scoping automation from Winnipeg for teams across Canada.

Start with the decision you want help making

Choose one mailbox and a small set of categories the team understands. Our fictional example uses quote, billing, support and admin. Define an owner and the next action for each. A billing question might require an account lookup; a quote request may need a site link before anyone can estimate it.

If a known sender or subject pattern determines the category reliably, ordinary rules may be sufficient. Gmail's official filter documentation describes applying labels and other actions through filters. Review the available behaviour in your actual mailbox before paying for a custom classifier. Ambiguous, varied requests are a better place to test whether AI adds anything.

Label the examples before looking at the predictions

Start with fictional messages or appropriately protected examples approved for the pilot. Record the message identifier, expected category, proposed category and the reason someone might need to review it. Let the people who handle the inbox agree the expected answers first. Disagreement between staff is a workflow question to resolve before treating it as a model mistake.

Include both ordinary requests and awkward ones. Our eight fictional messages cover two quotes, a blank status page, a meeting change, a refund request, changed bank details, an instruction to archive messages and a failed upload. The expected labels are written directly into the downloadable file so the result is inspectable.

The classifier outputs in this example are deliberately written by hand. No AI model was called and no real inbox was read. The purpose is to demonstrate the evaluation and review rules, not to benchmark a provider or claim that a production system achieves a particular accuracy.

What the eight-message example actually shows

Six of the eight simulated category guesses match the expected labels. The meeting change is mislabelled as a quote, and the bank-detail change is mislabelled as admin. That second mistake has a high simulated score. It demonstrates why a confident-looking output is not sufficient reason to trust a routing decision.

The independent review gate checks the proposed category, score, requested action and a small list of sensitive phrases. It sends five messages to human review and leaves three as suggested labels. The refund, meeting change, bank-detail change, archive instruction and uncertain upload request all enter the review queue. Neither queue sends, deletes or archives anything.

These results are intentionally small and synthetic. The phrase check does not understand every sensitive request. Different wording, languages or omitted context can defeat a simple rule. The simulated score is not a calibrated probability. A real pilot needs representative data and a broader evaluation of both missed risks and unnecessary reviews.

Run the local checks

Download the original workflow fixture. With Node 22 or later, run:

node --test business-workflow-proof.mjs

The file includes all eight messages, expected labels, simulated outputs and review reasons. The recorded results include the evaluation counts and seven passing workflow scenarios. Everything runs in memory without connecting a mailbox, CRM or model account.

One case contains a request to ignore instructions and archive messages. The gate rejects the proposed archive action because the fixture allows only label suggestions. This checks that boundary for this supplied output. It does not prove that a real model resists every instruction embedded in an email.

Keep routing separate from customer commitments

The classification result should not be allowed to add new action types. Define the permitted categories and actions outside the message text. Unknown outputs should remain visible for review. A suggested label is different from permission to issue a refund, change bank details, promise delivery or send a reply.

For the first live pilot, a person can inspect suggestions beside the existing manual process. Agree who reviews them and how to pause processing. Record messages that were missed, cases that were routed incorrectly and how long review took. Do not automatically hide a message just because the system assigned a category.

Check the fit for your Canadian team

Include the languages your customers actually use, business hours and time zones in the pilot cases. Decide which message fields are needed and which can stay in the mailbox. If a particular storage region is required, verify the actual services and account settings before using customer messages. Scoping can start with invented examples instead of a customer-data export.

Compare manual handling time, delayed enquiries, routing corrections and review effort before and during the pilot. Count operating costs as well. This guide provides no measured time-saving claim: the local fixture establishes its listed outcomes only.

If the real problem is missing request details, client intake automation may be more useful than another inbox layer. For the next system handoff, see CRM workflow automation. The first-automation worksheet helps decide which repeated job is worth testing at all.