AI email assistant setup: drafts, auto-send and safety

Open the assistant that should answer the support mailbox, select Channels and choose Email. Confirm the assistant name in the heading and sidebar before entering credentials; email behavior and knowledge belong to this selected assistant.

The introductory notice distinguishes draft mode from direct send. For a new rollout, plan Create drafts first so a human retains the final send decision while you evaluate real reply quality.

Enter the mailbox address and a sender name that recipients recognize. Leaving the address field can detect supported provider settings and prefill host, port, encryption and username. Review every value against the provider documentation instead of assuming detection is always correct.

Use the incoming IMAP host, normally port 993 with SSL/TLS, and a dedicated app password where available. Credentials are write-only in the interface: after saving, only their stored presence is returned, not the clear text.

Select Test connection. A successful IMAP result confirms host, port, encryption, username and password as one working combination. WebChatAgent then proposes Inbox, Drafts and Sent folders; confirm them because names vary between providers and languages.

In draft mode SMTP shows Not tested because it is not needed for delivery. If IMAP fails, check whether IMAP is enabled, whether the provider requires an app password, and whether port and SSL setting match before changing any AI model or prompt.

Under Reply behavior choose Create drafts. The assistant still reads the message, retrieves approved knowledge, follows the selected tone and prepares a complete reply. It then appends that reply to the mailbox Drafts folder instead of sending it.

Define the reviewer and response-time target before activation. The reviewer checks recipient, subject, factual claims, promises, privacy, tone and signature, then edits, discards or sends the draft manually.

Choose whether first contact is always formal, always informal or mirrors the sender. Include previous correspondence when follow-up answers need thread context; old messages support context and are not answered again as new mail.

Use Extra instructions for behavior: answer concisely, check approved policy, avoid sensitive-data requests and create a human-review draft for complaints, cancellations, legal requests or uncertainty. Keep prices and policies in maintainable knowledge sources. Add the normal support signature.

Confirm that you are authorized to connect the mailbox and have informed affected people where required. The checkbox is a product safeguard; independently document purpose, legal basis, retention, access roles, provider choices and privacy information for the real deployment.

Enable the channel, save and confirm Active. Initialization starts with new mail rather than answering an old backlog. Tell the support team where drafts appear and who monitors the activity log.

Recent activity shows when a message produced a draft, was sent, was skipped or failed. The example records the refund question as Draft and a newsletter as Skipped. Auto-replies, bounces, newsletters, own mail and no-reply senders should not trigger normal customer answers.

During the pilot, compare activity daily with the source message and final sent reply. A high edit rate points to weak knowledge, tone or routing rules. Investigate connection errors rather than hiding them behind automatic sending.

Alex Example asks whether a Northstar Cloud Pro purchase from 14 days ago is still refundable. The controlled draft uses the indexed 30-calendar-day rule, avoids requesting passwords or full card details and includes the configured signature.

Verify recipient, subject, dates, policy wording, sensitive-data handling and promises before sending. If account data is needed, add it only through an authorized team workflow. The green Draft state proves that no external delivery occurred in this example.

Selecting Send directly opens an explicit confirmation and makes SMTP required. The assistant would send in your name without a reviewer checking every reply, so changing this mode is an operational release rather than a cosmetic preference.

Before confirming, test unclear questions, complaints, cancellations, legal language, missing knowledge, attachments, forwarded threads and sensitive-data attempts. Keep human requests and uncertain cases as drafts. The tutorial leaves direct send unconfirmed.

Start with drafts, measure edit and rejection rates, repair weak sources and define which message types are genuinely low risk. Automate only one narrow class at a time and keep complaints, cancellations, legal issues, explicit human requests and answers without trusted evidence in the draft queue.

Use a dedicated support mailbox, least-privilege credentials, app passwords where supported, a named review owner and regular activity checks. Repeat the fixed test set after every source, instruction, model or routing change before expanding automation.