A few months ago, this was my routine: AI gave me some text in a chat window. I read it, decided it looked fine, copied it, opened my email client, pasted it, added a signature and attachments, then went back to find the recipient's address.
Five minutes for one email. Ten messages could occupy an evening.
Things got missed: a signature, an attachment, one character in an address.
My own setup now reads email and puts prepared messages into the drafts folder. I open the client, review them and decide whether to send. Much of the copying and reformatting has gone.
One distinction matters before going further: this describes a connection I had working in my own environment at the time. It is not a promise that every mailbox or AI assistant can use the same setup.
1. Where email fits in the workflow
I think of customer development as a sequence of stages. It starts with an archive: what the company does, which brands it represents, who the contacts are and whether the opportunity is worth pursuing. Eventually, the work needs to lead to an actual business result, including payment.
Between those ends, a useful customer archive must connect to communication and follow-up records. Without a next action, even a beautifully organized archive is static information.
A reply is an important signal, but silence alone does not prove a lack of demand.
My working sequence is:
Customer archive → prepare contact → human approval → follow-up and records.
This article focuses on preparing email in the middle of that sequence.
2. Three channels, one connected in my setup
I use three channels to contact overseas customers.
| Channel | My integration at the time |
|---|---|
| Read historical messages and write drafts; sending requires my approval | |
| Not connected in my environment; I provide conversation material manually | |
| Not connected in my environment; I provide conversation material manually |
Email can be accessed through protocols or APIs permitted by the provider. IMAP/SMTP availability, app passwords and OAuth requirements depend on the provider and organization. The same authentication method will not work everywhere. Social messaging integrations likewise depend on official interfaces, account conditions and the tools being used.
For conversations I had not connected, I took a screenshot, provided it to the assistant and asked for wording and a next-step suggestion. I then sent the actual reply from my phone.
AI was involved, but that part was not automated.
It is tempting to wait until every channel is connected before starting. I chose to begin with the channel I could connect reliably.
3. Four preparation steps
These steps describe the approach on my own computer and mailbox. They require some scripting and email configuration skills. Start with a dedicated practice mailbox rather than immediately connecting your entire business mailbox. Authentication, permissions and folder names vary by provider.
Step 1: establish the supported authorization method
This is often the first obstacle.
An app password, where supported, is different from the password you normally use to sign in. It is a separate credential intended for an application.
Read the provider's official instructions first. Generate an app password only where that is the supported approach. If the environment requires OAuth, use its supported authorization flow. An organizational mailbox may also require administrator approval.
Keep the resulting credential in a local configuration file in your own environment. Do not paste it into a conversation, hard-code it in shared source files or send it to someone else.
Step 2: prepare a mailbox module
I used a file with four responsibilities: connect to the mail server, read messages, prepare messages and send approved messages.
I called my module email_signature.py, because it also handled the signature.
It can accept a recipient, subject, body and language, then write a draft. This filename refers to my own module. It is not a feature built into every assistant, and a prompt alone does not grant access to a mailbox.
Step 3: make the signature part of the module
I learned this after a mistake.
At first, I took a shortcut and let a program send a message directly. The customer received it without the signature or the banner image beneath it.
The program had bypassed the module that added those elements. Once the module was bypassed, the signature disappeared.
I made a rule for my setup: outgoing messages must go through the intended module rather than bypassing it.
I also standardized the structure:
| Position | Content | What to check |
|---|---|---|
| Opening | Name, role, company or brand | Accurate identity and a clear visual hierarchy |
| Middle | Business phone, email, website and other necessary contacts | Correct details; include only what is useful |
| Lower section | Address or brand image | Image availability and actual rendering |
The closing depends on the customer's language: for example, “Saludos,” in Spanish, “Atenciosamente,” in Portuguese and “Best regards,” in English.
A fixed configuration reduces repeated typing. It does not remove the need to check the customer's language, signature details and displayed result.
Step 4: write a draft before sending anything
Do not begin with a live message to a customer.
Write a draft, open the actual email client and inspect the signature, banner image, paragraph spacing and line wrapping.
The first message is for you to review.
4. Six parts of the working process
1. Search by content, not just the latest messages
Customer follow-up often begins with a simple question: when did we last contact this company?
Get that wrong and the next action can be wrong too.
I needed to search across the relevant history by subject keyword, recipient, date range and attachment name.
Two failures shaped the way I did it.
In my environment at the time, server-side search proved unreliable. Subjects containing Chinese, Spanish or Portuguese produced errors. Some date filters did not behave as expected and returned more than 1,800 messages instead of the intended subset.
The approach that worked there was to retrieve message headers in batches and filter them locally. That is a report of my environment, not a general claim that server-side search is unusable.
The second mistake cost me a month. I asked the program to inspect the latest eight messages in the sent folder to determine whether I had written to a customer. It said I had not.
The relevant email was around seventy messages back in a folder containing more than 1,900 messages. Looking at eight could never establish the answer.
A month later, I discovered that the message had already been sent.
My rule became: locate correspondence through relevant content and search conditions. A small recent sample is not a substitute for checking the record.
2. Check the address before relying on it
Addresses can come from business cards, company websites and LinkedIn. Finding one is not the same as verifying it.
At a minimum, check whether the domain exists and whether there is evidence of a usable mail service.
I once used an address that looked plausible. There was no reply and no obvious bounce. A later check found that the domain did not exist. It should not have continued to be treated as a valid contact.
In my workflow, an unchecked domain is marked “needs verification” and is not used for sending. Domain checks can identify some problems; they cannot prove that an individual mailbox exists or guarantee delivery.
3. Treat the drafts folder as the review point
The assistant prepares the message; it does not decide to send it.
I inspect the actual draft in the client, approve it or request changes. The drafts folder is the review point between us.
Repeated revisions created another problem: four or five versions of a draft for the same recipient accumulated in the folder.
Duplicates need attention, but the recipient alone is not a safe deletion rule. One customer can have several simultaneous topics. A better approach is to preserve originals and identify drafts using the customer, subject, thread and version together. List likely duplicates, then let a person decide what to archive or delete.
Synchronization also matters. A success message from the program does not prove that the expected draft is visible in the intended folder. Inspect its recipient, subject and content in the actual mailbox. If it is absent, investigate synchronization and folder mapping before marking the task complete.
4. Check identity and formatting
Verify the recipient's name and full email address, using a format the client supports. Do not make the reviewer reconstruct the address from an incomplete label.
Avoid inserting hard line breaks in the middle of every sentence to fit your own screen. Use normal paragraphs and let the recipient's client wrap the text to its available width.
5. Follow the complete drafting and review sequence
I split the work into eight steps:
- Read the customer archive, development log and status card.
- Search actual messages by content, recipient and date; establish what was sent, what arrived and what remains open.
- Choose the angle for this round without repeating the previous message.
- Draft without inventing specifications, prices or delivery commitments.
- Use a separate reviewing role to identify issues and explain suggested changes against a checklist.
- Prepare a preview for me to check the facts, recipient, wording and attachments.
- After approval, write the draft to the real mailbox and inspect it again.
- Let me decide whether to send; afterward, confirm the action and update the log.
Step 2 reduces reliance on potentially outdated files. Step 5 separates writing from reviewing. My own setup used a score out of 100 with 95 as its threshold. A model's high score cannot replace factual checking or predict replies and sales.
Two further decisions matter each time.
Should this be a reply or a new message? If the customer has written and the topic continues, preserve the relevant thread and context.
I got this wrong twice. Once, the program labeled something a reply without including the original-message context, and the client still presented a new email. Another time, I started a new message despite an existing customer reply, losing the continuity of the conversation.
What time is it for the customer? Brazil, Colombia and Chile cannot be treated as one time zone. Check the customer's city and the actual date before using a morning or afternoon greeting. If that cannot be established, use a natural opening that does not depend on the time of day.
6. Set operating limits
The difficult part of automation is controlling what happens when it goes wrong.
My setup uses limits on messages per sending window and per day. Reaching a limit means stopping, not rushing through a backlog.
I also set a rule to stop the day's sending after more than two bounces and investigate. That is my operating threshold, not a universal deliverability standard.
No unapproved draft is sent. Quotes, meetings and complaints that require a decision are brought to me rather than answered on my behalf.
The assistant can prepare work. It cannot take over my authority to make business commitments.
5. How I handle messaging channels
WhatsApp and WeChat were not connected for automated reading and writing in the environment described here.
I still used AI to help with them. When a customer replied, I provided the relevant conversation material. The assistant helped identify the current situation, possible responses and questions to clarify next. I sent the actual message from my phone.
It can suggest what a reply may mean, what conditions are missing and what I should ask. Those are analytical suggestions. Purchasing intent still needs to be established through real communication.
It is slower than a direct integration, but the work can continue. One unconnected channel does not mean the whole process must stop.
6. Failures are part of the record
Only describing the benefits would leave out the most useful lessons. My setup encountered all of these:
- Server-side search that did not work as expected.
- A review limited to the latest messages that missed earlier correspondence.
- Several versions of the same draft accumulating.
- Records saying “ready to send” when the drafts folder was empty.
- Signatures and banner images lost when the intended module was bypassed.
- A supposed reply appearing as a new message in the client's mailbox.
Each rule followed a problem that had actually occurred.
The point of configuration is not to pretend that errors disappear. It is to make the process easier to inspect when something goes wrong.
Manual and programmatic actions can both fail. Original messages, action records and traceable versions help reveal those failures. Incomplete logs still mean that some errors may be missed.
For me, that ability to inspect the work is one of the most valuable parts of the setup.