Subject: Mail system: final architecture, and a few things I need from you

Hi Roma, Narin

Quick update on the pilot, the architecture I've settled on, and a few pieces of
information I need from your side to move forward. To set expectations: this round
is the first step, just what I need to get the real system started. More rounds of
fine-tuning will follow (details in "What comes next" at the end).


1. WHERE WE STAND

The core/engine is working end-to-end on the test domain: incoming emails are sorted
automatically into the right team queues (I ran a realistic 13-email test round, and
all 13 landed correctly), your hybrid queue layout is live, and the AI drafting
assistant is validated inside the helpdesk. The first attached diagram
(adr-0002-ai-assist.png) shows how drafting works today: the assistant proposes a
first draft, then a person always reviews, edits and sends. Nothing ever goes out
automatically. That rule is built into the system as a policy.

To be concrete about what the routing engine does today, the moment an email
arrives:

1) Every mailbox lands in its own team queue: quote@ goes to Quote / Estimating,
   sales@ to Sales, cad@ to Engineering / CAD, delivery@ to Logistics, accounting@
   to Accounting, support@ to After-sales / Quality, and contact@ to a shared
   Triage queue.

2) For general mail (contact@), keyword rules on the subject and the body move the
   email to the right team: quotation / RFQ / pricing goes to Quote; invoice /
   payment to Accounting; CAD / drawing / 3D to Engineering; shipping / lead time
   to Logistics; warranty / complaint to After-sales. When subject and body point
   to different teams, the subject wins.

3) A brand-new quote request sent to the wrong address (for example an RFQ sent to
   accounting@) is moved to the Quote queue automatically and tagged, so your
   estimators see it immediately. Replies to existing conversations (Re: ...) are
   never moved; they stay with the team already handling them.

4) Emails from automated senders (no-reply addresses, newsletters) are tagged and
   set to low priority, so they never bury a real customer.

5) Non-English emails are flagged so the right person picks them up.

6) When an email has no clear signal at all, it stays in Triage for a quick human
   sort. A typical example from your real traffic: "I am looking for a new factory
   for my vermeil collection, please send details about MOQ and sampling fees".
   No keyword rule can safely catch that today. This is deliberate: a wrong
   automatic move is worse than a 10-second human decision, and this is exactly
   the kind of email the AI workspace (below) will help with later.

These rules run at the moment the email is received, so a message is already in the
right queue before anyone opens it. The keywords are a starting set; tuning them to
your real traffic is part of the next steps.


2. THE FINAL ARCHITECTURE AND WHY I BUILT IT THIS WAY

The second diagram (final-architecture.png) shows the full structure. The idea is
simple: I assemble proven open-source products as modules, and I only write one
small piece of software myself.

- Zammad, the helpdesk module. Receives all mailboxes, sorts requests into team
  queues, tracks status, and is where your team replies from.

- Open WebUI, the AI workspace module. A chat interface where your team can ask the
  assistant things like "what's urgent in the quote queue today?", and where the
  company knowledge lives (MOQ policy, sampling fees, business terms, past quotes).

- Claude (Anthropic), the AI model behind the assistant. OLLAMA coming soon.

- The connector, the only piece I will have to code: a small auditable bridge that
  lets the assistant read tickets and place draft replies inside the helpdesk. By
  design it has no ability to send email. Only humans send.

Why this matters for you:

- Each module is maintained by its own team. Zammad and Open WebUI are widely-used
  open-source products with their own developers, security updates and
  documentation. I don't modify them, so updates stay safe and nobody inherits a
  pile of custom hacks buried inside each tool.

- Maintenance stays realistic. One small connector to maintain instead of custom
  code scattered across every product. If something needs fixing, there is exactly
  one place to look.

- It's future-proof. Other modules can be added later (accounting, CRM, product
  catalog and so on) the same way: plugged in through the same pattern, not welded
  in.

What the AI workspace adds on top of what the pilot already does:

Already working today:
- Automatic sorting of incoming emails into team queues
- One-shot AI draft inside the reply window

What the AI workspace module adds:
- Ask questions across all tickets ("anything urgent in Triage?")
- Full back-and-forth conversation about a ticket before drafting
- Drafts informed by company knowledge: MOQ, sampling fees, terms, past quotes
- Complete draft placed directly into the ticket, ready for human review


3. WHAT I NEED FROM YOU (STEP ONE)

(a) The complete email map of Advance Manufacturers. I attached a short spreadsheet
(staff-email-map.csv, opens in Excel) to make this easy. Please fill in one line per
person for everyone who sends or receives work email: full name, role or department,
and the email address they use. If someone uses several addresses, add one line per
address.

In the same file, please also list every shared or company mailbox that exists
(info@, sales@, accounting@ and similar), even old or barely-used ones. I need the
full picture to map mailboxes to queues and decide what gets plugged in.

(b) Usernames for logging in. I've confirmed the helpdesk supports simple usernames
for login instead of email addresses (for example just "noc"; this is internal only
and doesn't change anyone's email). Please confirm you're happy with that, and use
the "Preferred username" column in the spreadsheet to tell me what each person
wants. If left empty, I'll default to first names.

(c) Your current email signatures. So replies from the new system look exactly like
your emails today, please send me the signatures currently in use: the company
signature template, and each person's variant if they differ (name, title, phone,
logo and so on). The easiest way is to forward me one recently sent email per
person; the signature at the bottom is all I need.

(d) Your reply templates, per department. If your teams have standard replies they
reuse (quote replies, sampling fee explanations, payment terms, shipping updates,
complaint handling and so on), please send them to me, organized by department. And
if possible, include a few real case studies: complete email exchanges from first
customer contact to the final reply (customer names can be removed). These are what
I'll use to teach the assistant your tone, your terms and your way of answering, so
the drafts it prepares sound like Advance and not like a generic robot.


4. WHAT COMES NEXT

To be clear about the road ahead: this information round gets us started (accounts,
mailbox connections, signatures, first mapping), but it is step one, not the whole
journey. The following steps will be about fine-tuning, and I will need your team
for them:

- Tuning the routing keywords against your real traffic (the current set is a
  sensible starting point, your actual emails will tell us what to add).
- Feeding the assistant with real email samples per department, beyond the first
  templates from point (d).
- Filling and validating the company knowledge base (MOQ policy, sampling fees,
  business terms) that the assistant will draw from.
- A supervised test round with your team before anything touches real customer
  email.

Nothing else is needed from your side for now. Once I have the list, the signatures
and the templates back, I'll prepare the accounts, the signatures and the final
mailbox mapping for your validation.

Best regards,
Bastien