微信消息模板业务背景
在电商系统里，消费者总是需要消息通知的，如支付成功通知，如物流发货通知，如领取奖励通知，既作为信息提醒，又作为凭证和详细信息入口引导，传统平台型产品的做法是在自己的平台应用中开启消息通知模块，依靠强有力的推送提醒，一般已足够，但对saas服务的电商系统产品来说，去中心化的特点使这一点没那么方便直接，因为大量的用户没有平台应用的概念，手机上没有yz买家端app，也就没有消息通知的渠道，但既然游离于第三方平台如微信中，那么这自然成为替代渠道，于是拿我们最大的第三方平台微信来说，我们需要借助它的消息通知功能，也就是微信消息模板。
业务架构设计
微信消息模板有很多前提使用条件，如公众号为认证服务号，消息模板行业类型，授权情况，最多25条，如此种种，给产品设计带来了一定难度。首先我要考虑如何使yz和微信消息模板进行结合，考虑到这是一种附加工具，我们将它做成一个可用开关控制的营销应用，同时将通知业务的每一种都做成可控的开关，以便商家选择性使用会比较好。
另外，因为微信为了防止用户受到公众号信息骚扰，有严格的模板消息运营规范，所有广告，营销，红包等类型模板都一经发现将严厉处理。因此初期我决定在初期将严格控制模板消息内容，并制定规则后通知平台中所有业务方产品负责人，当他们作为上游业务使用我提供的这个服务工具时，需遵守规则，由产品经理自己挑选字段并撰写合适的内容，然后提交给我进行审核，通过后将作为一个新增业务通知类型进行开发上线，这就由一套制度来有效运行该业务的持续变动，并保证了内容的合规性。
如图，简要说明了业务流转是如何在各个平台系统之间进行的：
产品设计
另一方面，由于工具的使用天生有很多无法逾越的前提条件，因此这个复杂的依赖性就决定了，在业务设计明确的情况下，如何降低工具的使用复杂度，提高成功率，提升体验到普通用户都能理解甚至不需要理解的程度，就是接下来产品和交互设计的关键：
在经过大量的讨论，思考和调整之后，我针对商家必须要有公众号且公众号为认证服务号这一点，决定使用平台方yz的大公众号来对不具备这个条件的商家的买家客户进行代为服务，即代发。首先平台方的公众号调整到一切满足条件，然后再利用商家的消费者有许多也是平台自己粉丝的优势，进行消息发送。
针对行业类型，授权情况，最多条数这几点，在设计上默认情况下直接隐去所有限制说明，而在已经打开开关的情况下，通过技术手段每次当用户进入页面有使用意向可能时直接拉取数据进行判断，如果符合条件，则继续发送，如果不符合条件，则报出错误来源原因，使用户进行调整。其中开关默认值为关闭，因为有些即使打开，也不满足条件无法正常发送，且最重要的是，该业务通知模板需要有一个添加的动作，使商家自己的公众号后台中增加一个该模板到微信系统中，也就是该页面唯一的保存按钮，可以保存成功就意味这一切，如果保存不成功，就有可能是三个方面任一方面的问题，我们会将问题列出来。
另外，非认证服务号或没有认证服务号的商家，只要他选择使用该工具并将开关打开，则他的买家中是平台方yz粉丝的那一部分总能成功收到通知。
所以总的来说，该设计尝试在最大程度上减少用户的认知和操作负担，用户只需要决定自己是不是想用，并关心我们提供的服务在他按下那一个按钮之后给出了什么结果。个人认为这整产品系统是一个比较成功的设计。
