这页在讲什么
换掉的不是邮箱，是邮件在流程里的位置
这套系统我们自己每天在用：客户来信、售后往来、对外的正式记录、需要拍板的审批， 都跑在上面。先在自己身上跑顺了，才拿出来交付—— 下面写的每一条，都是被自己的实际往来逼出来的，不是提案里想出来的功能表。
为什么接不进来
现成邮箱接不进来的三件事
它不认识你的订单
一封信进来问「我上周下的单怎么还没发」，现成邮箱能做的只有把它标成「客服」。这位客户是谁、买了什么、订单走到哪一步、之前问过什么，它一概不知道——因为它和你的站点、客户档案、工单之间没有连接。
结果是人得开两个窗口，一个看信，一个查单。
它发不出由业务触发的信
客户完成购买之后该收到什么、保修该在什么时候提醒、发票该在哪一步开出去、久未回访的客户该在第几天跟进——这些的触发条件全在你的业务系统里，不在邮箱里。
所以只能等人去点发送，或者外挂一个营销工具，然后你有了两套互不认识的客户名单。
它按人头收费，而流程需要很多个地址
客服、售后、保修、开票、经销商、投诉、各语种市场各一个——十几二十个是常态，其中大部分根本不对应一个真人，它们是流程的入口和出口。
按人头订阅的计价和自动化的方向相反：流程越自动，地址越多，账单反而越贵。
这三件事合起来是同一个问题：邮件被做成了一个给人用的软件，而流程需要的是一个给流程用的节点。
接进闭环之后
它在四个地方替人省掉了动作
进来的信
信到的时候，上下文已经在同一屏上
进来的信不是躺在收件箱里等人看。它被分好类、标好紧急度、派给对口的人；被读懂的时候，这位客户是谁、买了什么、之前问过什么是一起读到的——所以它理解的不是一段文字，是「这位客户在这个订单上遇到的这个问题」。回复稿按你自己的政策先备好，人看一眼、改两个字再发。
出去的信
该发的信不靠谁记得
不是有人去点发送，是你的业务里发生了某件事，信自己就出去了：购买完成、物流出状况、保修到了该提醒的时候、发票该开了、售后走到下一步。每一封都带着这位客户自己的数据，不是群发模板。
跟进
该往下推的往下推，人只在需要判断时出场
久未回访的、保修快到期的、询价之后没有下文的——这些跟进本来全靠人记，记漏了也没人知道。现在由你定的规则往下推，节奏稳定，人只在需要拿主意的那一步出现。
审批与正式记录
要留痕的那一类，走邮件
我们的流程里有很多刻意保留的人工卡点，多数走内部沟通工具；但有一类必须走邮件——要留正式记录的、要对外发的、要抄送多人的、事后可能要拿出来对账的。审批链路和往来内容都落在你自己的系统里，谁批的、什么时候、当时看到的是什么，事后查得到。
最容易被低估的是第一件事的后半段。邮件是企业里被浪费得最彻底的知识来源——真实的客户问题、真实的解决办法， 每天都在往来里产生，然后随着邮件一起沉底。接进来之后它换了个去处： 一封信里出现的新问题、人工最后是怎么答的，会进入待审队列，人确认后正式入库， 下次同样的问题不用再从头答一遍。邮件从此是知识库自己长大的燃料，而不是它的漏点。
同一封信
接进闭环之后，和靠人接力的时候
接进闭环之后
- ✓信到的时候，这位客户是谁、买了什么、之前问过什么已经在同一屏上
- ✓回复稿已经备好，人看一眼、改两个字，发送键还在人手里
- ✓事务性的信由业务里的事件自己触发，不用谁记得
- ✓该找人拍板的那一步会主动找到人，不需要有人一直盯着收件箱
- ✓一次人工回复同时长进知识库，同样的问题下次不用从头答一遍
- ✓为流程新开一个地址，不会多一笔订阅费
靠人接力的时候
- ✕一个窗口看信、一个窗口查单，来回切着对
- ✕AI 把结果算出来了，还得有人复制粘贴进邮件
- ✕该发的通知靠人记得，忘了就漏了，漏了往往是客户先发现
- ✕营销工具一套名单、邮箱一套名单，两边对不上
- ✕客户问题答完就沉底，下一个人来问，再答一遍
- ✕每多一个流程用的地址，账单就多一份
我们不让步的地方
三条规矩，我们自己也守着
发送键不给机器
事务性邮件（订单、物流、保修、发票）由事件触发自动发出，这类内容是确定的。但对具体客户的个别回复、任何带承诺或让步的内容，发送前必须有人确认。系统可以起草、翻译、把全部上下文准备好，最后那一下是人按的。
身份校验是必检项，不是可选项
一个能读到全部客户往来的系统，没有身份校验等于把门开着。我们自建过程中最重要的一课就是这个：功能先跑通、认证以后再加，是这类内部系统最常见也最危险的顺序——「以后」很容易变成「上线之后」。它现在写在我们的部署规范里，是交付前的必检项，规范随系统一起交给你。
知识入库要人点头
邮件里出现的新问题、人工最后是怎么答的，会进入待审队列，人确认后才正式生效。不做无人确认的自动写入——那样知识库会被错误答案污染，而且没人说得清是从什么时候开始污染的。
三条指向同一句话：机器负责把事情准备到最后一步，需要担责任的那一下留给人。人在哪些位置出场，是诊断阶段和你一起定的，不是我们替你定死的默认值。
什么时候用不上
这件事有明确的边界
邮件在你这里就是人写人回
没有要接的上下游、没有要触发的后续动作，那现成邮箱已经够用。接过来只会多一套要维护的东西，省不掉任何动作。
想做大规模营销群发
买来的名单、群发式的营销投递，我们不做。这套系统发的是由业务事件触发、带着这位客户自己数据的信，是两件事。
规则还没定型
什么信该怎么分、什么情况必须转人工、哪些内容可以自动发——这些得先有一个人能拍板。规则没定型就接进来，只是把不确定性换了个地方放。
所以你会拿到什么
一个能被流程调用的邮件节点
这条线在一个真实业务上整体是什么样，看跨境电商独立站自动化 →
常见问题
你大概率会问的几个问题
01要换掉现在的邮箱地址和域名吗？+
常见的做法是地址与域名都不变，你的人该怎么收发还怎么收发，变的是它背后接上了什么。也可以只先接一两个业务邮箱——比如客服和售后——跑一段时间再谈其它的。具体怎么接、按什么顺序上，诊断阶段对着你的现状定，不套一个固定路线。
02AI 会替我把信直接发出去吗？+
分两类。事务性的信（订单、物流、保修、发票这类内容确定的）由业务事件触发自动发出；对具体客户的个别回复、任何带承诺或让步的内容，一律要人确认才发。系统负责起草、翻译、把上下文准备齐，发送键始终在人手里。
03往来数据在谁那里？+
系统与全部往来数据落在你自己的服务器或私有云内，不经过第三方平台。规则、模板、沉淀下来的知识也都在你自己手上。我们不提供代管实例——托管方在你这边，才不会又形成一个新的供应商依赖。
04会不会和现有的客服系统、CRM 冲突？+
不冲突，也不替代它们。它是叠在你已有系统之上的那一层，把邮件这个原本断开的节点接回流程里：你原来在哪里看订单，还在哪里看。接哪几个系统、接到什么深度，取决于你现在这些系统开不开得出口子，诊断阶段会先看这一点。
05邮件会不会进垃圾箱？+
送达受域名信誉、发信量与收件方策略共同影响，该做齐的配置我们会做齐，但送达率不是任何一方能单独保证的东西，所以我们不把它写进承诺里。判断方式很直接：先接一个真实在用的业务邮箱跑一段时间，看它自己的数据。
06这套东西要多久、大概多少钱？+
取决于要接的业务系统有几个、你的邮箱与规则整理到什么程度。可以从一个模块起步（比如先接「进来的信」这一头，起价 ¥28,000），也可以整条线一起做。整条线不挂价的原因是同一件事在不同企业工作量能差好几倍——具体金额在诊断结束时给你，不给一个没有意义的区间。
07上线以后新增流程要另外收费吗？+
要。这是我们写进合同的计费规定，在签约时就讲清楚，不会到项目中途才提。规定分两头：日常维护——改话术、调规则、加分类、补知识库条目、跟进版本、日常巡检与故障响应——你自己的技术人员接得住，也可以购买年度运维订阅；新增一条自动发信的业务线、接入新的业务系统、加一个新的处理场景，属于一次新的开发，按新项目单独立项计费。这样划分是为了把账算清楚：新增的工作量并进维护费里，要么让维护费虚高，要么让新增的那件事没人认真做。