Can AI answer customer emails using our company documents?
Yes. The safer pattern is to retrieve the relevant approved facts, show which sources support the answer, and flag missing or conflicting information before the reply is approved or sent.
AI customer email automation
How can we automate customer email without losing control?
Reliable email automation should do more than generate fluent text. It needs to understand the latest request, find the right business facts, show what is missing, and keep sensitive replies or actions behind an appropriate review gate.
Use AI to prepare the work, not to invent authority. Ground drafts in approved company knowledge, separate the current request from quoted history, route uncertainty as an exception, and require a person or deterministic policy check before sensitive external action.
Frequently asked questions
What teams usually want to know
Does every email need a human to approve it?
Not necessarily. Review should follow risk and policy. A team can define which drafts always require approval, which cases must escalate, and which low-risk steps can proceed after deterministic checks.
What happens when the system cannot find the answer?
The workflow should expose the knowledge gap, ask for the missing detail, or route the case to an owner. It should not turn uncertainty into a confident customer-facing claim.
Can AI safely read an entire email thread?
It can use the thread as context, but the latest customer message should remain the primary request. Quoted history, signatures, and earlier resolved questions need to be separated so they do not become new instructions.
What if two company documents disagree?
The workflow should apply an agreed source hierarchy or effective date where one exists. Otherwise it should show the conflict and route it to the person who owns that knowledge before a factual reply is sent.
Illustrative example
A replacement part question that cannot be answered in one step
This example uses the same fictional Harbour Garden Supply request shown in the interactive demo. It is deliberately ordinary: the difficulty comes from joining several facts without making a promise the business cannot support.
- 1
Read the new request
Sarah asks for the correct replacement seal for a 40 mm pump connector and wants to know whether the leaking part is covered under warranty. Earlier messages explain the product history, but they do not add a new request.
- 2
Find the supporting facts
The workflow selects the HG-SEAL-40 product sheet, the approved 30-day exchange policy, and the order record. Each fact used in the draft remains attached to its source.
- 3
Keep the gap visible
The product and policy answers are supported, but the shipping address has not been confirmed. The case is not treated as complete simply because most of the answer is available.
- 4
Prepare, then review
A draft explains the compatible part and the applicable policy, then asks for the missing address. A reviewer can inspect the evidence, adjust the wording, approve it, or hold the reply.
- 5
Record what was sent
Delivery is a separate permissioned step. The final record shows the approved wording, reviewer, sources, missing detail, send result, and any later follow-up.
The useful result is not merely a polished email. It is a reply whose factual basis, unresolved detail, approval, and delivery can all be checked afterwards.
Start with what the customer is asking now
Long email threads are full of tempting distractions. A previous delivery issue, an old price, or a question that was already resolved may still appear below the latest message. If the system treats the whole thread as a fresh instruction, it can answer the wrong question or reopen work that is finished.
The current message should determine the task. Quoted history can identify the product, customer, order, or earlier decision, but it should not silently broaden the request. This distinction matters most when a short reply such as ‘yes, that address is correct’ sits above a long chain of older questions.
- Separate the newest customer-written content from signatures, disclaimers, and quoted history.
- Carry forward relevant context without treating every earlier sentence as an open request.
- Show the detected request and selected context to the reviewer instead of hiding them inside a prompt.
A fluent answer still needs business evidence
A language model can produce convincing wording even when the underlying fact is missing, stale, or contradictory. Customer email therefore needs an answerability check before it needs a writing style. The system should know which sources are approved, how current they are, and what happens when two sources disagree.
Source selection should be narrow enough to explain. A product question may require a product sheet and an order record; a warranty answer may require a policy version that was in force when the order was placed. Pulling in every available document can make the answer less reliable, not more.
- Define an owner and review date for policies, product facts, and standard responses.
- Set source precedence for conflicts, such as an approved policy over an informal internal note.
- Treat a missing authoritative source as a workflow outcome: ask, hold, or escalate.
- Keep customer and order data scoped to the organisation and request that is being handled.
Drafting and sending are different permissions
Preparing a reply is reversible. Sending it creates a customer commitment and may trigger further work. Combining those two steps removes the most useful place to apply policy, permission, and human judgment.
Low-risk cases can become faster over time, but that should follow observed performance and explicit rules. Refunds, warranty decisions, account changes, sensitive information, pricing exceptions, and unsupported promises deserve a clear stop until the required authority is present.
When should an email stop for review?
The right control depends on the consequence of being wrong, not on how confident the draft sounds. These examples are a starting point for defining a policy with the people who own the work.
| Situation | Sensible response |
|---|---|
| Routine fact supported by a current approved source | Prepare the reply and follow the organisation's normal review rule for that request type. |
| Required fact is missing or two approved sources conflict | Hold the reply, expose the gap, and route it to the source owner or request owner. |
| Refund, warranty exception, price commitment, or account change | Require approval from the person who holds that business authority before any customer promise is sent. |
| Customer message contains sensitive or unexpected personal information | Limit access and processing, then apply the organisation's privacy and escalation procedure. |
| Draft is approved but the delivery provider returns an error | Record the failure and reconcile before retrying so the customer does not receive duplicate messages. |
What reliable automation requires
A trustworthy reply needs context, evidence, and a controlled next step
The current request comes first
The latest customer message should determine the task. Earlier thread history provides context without broadening what the customer is asking now.
Answers come from approved sources
Product sheets, policies, order details, customer context, and selected documents should support factual claims instead of relying on a model's general memory.
Missing facts stay visible
When a price, address, compatibility detail, permission, or policy answer is missing, the workflow should ask, hold, or escalate rather than guess.
Review follows risk
Routine drafting can move quickly while refunds, commitments, account changes, sensitive cases, and other consequential actions require explicit authority.
Every decision can be inspected
A useful execution record shows the request, selected facts, checks, missing context, reviewer decision, and final approved or blocked action.
Delivery is a separate controlled step
Generating a draft is not the same as sending it. The outbound action should have its own permission, review state, and delivery record.
The NotchPath approach
Ingest, infer, propose, confirm, activate
Ingest
Connect the inbox and approved knowledge sources used to answer the request.
Infer
Identify intent, relevant context, likely workflow, and any missing information.
Propose
Prepare a source-backed draft, next step, and exception or approval requirement.
Confirm
Apply policy checks and route the work to the right person when review is required.
Activate
Send or continue only after the required permission and record the outcome.
Before you automate
Questions to answer before connecting a shared inbox
A useful first review is usually about one repeated request type. If these questions have clear answers, the workflow can be tested without pretending the rest of the inbox is equally well understood.
- Which messages are in scope, and which must remain outside the workflow?
- What sources may be used for product, policy, order, and customer facts?
- Which source wins when information conflicts or has different effective dates?
- What details must be present before a reply can be considered complete?
- Which replies always require a named person's approval?
- Who owns knowledge gaps and policy exceptions?
- What permission is required to send, retry, or follow up?
- Can the final response be reconstructed from its request, evidence, checks, and approval?
Product fit
Fit depends on the work, not organisation size
A good fit when
- Your team repeatedly answers product, order, policy, account, supplier, or service questions.
- Useful knowledge is spread across inboxes, documents, systems, and people.
- You want faster response preparation without allowing unsupported promises or uncontrolled sends.
- Reviewers need to see the evidence, missing facts, and proposed next step in one place.
Not designed for
- Replacing every customer conversation with unattended generic replies.
- Sending high-impact decisions without defined permissions or accountable owners.
- Treating unverified model output as the final source of truth.
- Automating a process that has no agreed policy, knowledge owner, or escalation path.
Further reading
Sources behind this guide
These references provide broader guidance on governance, privacy, security, and meaningful human control. They do not replace advice for your organisation or industry.
Office of the Australian Information Commissioner
Guidance on privacy and the use of commercially available AI productsExplains how Australian privacy obligations can apply to personal information entered into or generated by AI systems, including accuracy, transparency, due diligence, and human oversight.
US National Institute of Standards and Technology
Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence ProfileDescribes governance considerations for generative systems, including risk-based oversight, review, tracking, documentation, and management accountability.
OWASP Foundation
OWASP Top 10 for Large Language Model ApplicationsProvides practical security context for prompt injection, sensitive information disclosure, improper output handling, and other risks relevant to processing untrusted email content.