上周，一家销售工业润滑油的小公司的主管写信给我。他的问题的本质可以用一句话概括：“我们使用 WooCommerce，我们通常无法接受商业提案请求。”以下是我每月至少听到一次的故事，而且来自完全不同的企业。客户前往现场，查看目录，找到所需的物品 - 然后马戏团就开始了。他打电话给经理，经理打开1C，搜索商品，在Excel中手动收集CP，并通过邮件发送。客户要求换两个位置，经理重做文件并再次发送。在第三封和第四封信之间的某个地方，有人失去了线索，混淆了文件的版本，交易悬而未决。听起来很熟悉吗？非常适合我。因为在我们构建一个完全解决这个问题的系统之前，我们自己就经历过这个，从第一次点击到签名CP。
十多年来，我一直在为工业 B2B 公司进行开发和营销，在那段时间里，我得出了一个简单的结论：WooCommerce 是一个很棒的电子商务平台，但它完全没有为开箱即用的 B2B 做好准备。 “购买”按钮和购物车是零售范例。在批发世界中，没有人使用银行卡从网站上购买商品。 70% 的 B2B 交易都是从报价请求开始的 - 报价请求，简称 RFQ。客户想知道他的特定数量的价格、特定的折扣以及运送到他的特定仓库的价格。他希望收到一份文件——漂亮、有印章、有详细信息——他可以将其展示给他的管理或会计部门。这就是 WooCommerce 举手的地方，因为里面没有类似的东西。
当然，您可以为 RFQ 安装单独的插件。市场上大约有二十个。但你知道吗？我试过了。其中大多数只是贴在购物车上的反馈表。客户发送请求，经理收到电子邮件，然后一切都像以前一样 - Excel 中的手动工作、信件的乒乓球、版本的丢失。我测试的插件都没有提供完整的工作流程：从请求到谈判再到接受的商业提案。没有人生成包含公司详细信息的 PDF。没有一个支持 WooCommerce 内部的对话系统，因此有关交易的所有通信都集中在一处。这就是我们决定构建自己的 B2B 模块，而不是用十个不同的插件组装弗兰肯斯坦的原因之一。
为什么“购买”按钮正在扼杀 B2B 销售
让我解释一下为什么标准 WooCommerce 模型不适用于批发，不仅从技术上理解，而且从业务流程的角度理解也很重要。当零售买家来到该网站时，他会看到价格，将产品添加到购物车，通过卡付款并等待送货。整个过程是线性的、可预测的、自动化的。经理根本不参与，除非出现问题。
在 B2B 中，一切的运作方式都截然不同。产品的价格并不是价格标签上的固定数字。这是谈判的结果，取决于十几个因素：采购量、与客户的关系历史、当前库存余额、物流、季节性、竞争状况。同样的产品对于新客户来说可能要花费 1,500 卢布，而对于用托盘购买的常规批发商来说可能要花费 1,200 卢布。而且这个价格并不是一成不变的——可以进行讨论，您可以要求额外的数量折扣，或者同意延期付款。在这种情况下，“以 1,500 卢布购买”按钮看起来就像是在与机器讨价还价——毫无意义，而且对专业买家来说有点侮辱。
我一次又一次地看到我们的客户遇到这个问题。该公司投资建立了一个漂亮的 WooCommerce 网站，填写目录，设置过滤器和搜索 - 并通过该网站收到零订单。不是因为网站不好。但因为批发客户根本不明白如何使用“购买”按钮。他需要一个“请求报价”按钮。他需要有机会收集持仓清单，指明所需的交易量，并将其发送给经理，并注明“周四之前需要 CP”。经理需要一个工具来快速响应此请求，而无需离开 WooCommerce 管理面板。
事情是这样的：WooCommerce 实际上包含 B2B 的所有基本构建块。有一个产品目录，有一个作为生成项目列表的机制的购物车，有一个用户和角色系统，有一个用于自动化的 REST API。缺少一层——谈判层。客户和经理交换报价、讨论价格和条件并达成协议时的流程相同。我们构建的就是这一层。
说实话，当我们开始设计询价模块时，我认为这将是一个相对简单的任务。一份申请表、管理面板中的表格、PDF 生成——这似乎需要几周的时间。事实证明，情况要复杂得多。因为询价并不是一个孤立的功能。这是 B2B 流程的核心，它与一切相关：与定价、与客户群体、与通知系统、与您的个人帐户、与会计文件。如果不考虑整个链条，就无法制作出好的询价模块。
完整周期：从购物车到签名收据
让我通过我们的模块向您介绍整个过程 - 通过客户和经理的眼睛。这很重要，因为解决方案的美妙之处不在于单个功能，而在于它们如何相互连接。
想象一下：买家访问一家销售工业油的批发公司的网站。他登录了他的 B2B 帐户，这意味着他看到了与其客户群相对应的价格。假设他属于“经销商”组，并且他在基本价格的基础上获得 15% 的折扣。他找到了合适的商品 - 200 升桶装 HVLP-46 液压油、罐装 VDL-100 压缩机油、散装 TM-5 变速箱油。将每件商品添加到购物车，并指明所需数量。到目前为止，它看起来就像一个普通的在线商店。
但接下来就是 B2B 平台与零售平台的区别。他看到的不是“下订单”按钮，而是“请求报价”按钮。单击，将打开请求表单。它已经预先填充：购物车中的商品会自动拉出，公司详细信息会从个人资料中获取。客户可以添加评论 - 例如，“我们需要送货到叶卡捷琳堡，最好在月底之前，请考虑数量折扣。”发送请求。
WooCommerce 方面发生了什么？将在数据库中创建一个状态为“新建”的新查询。所有职位都存储在单独的表中 - 包含价格、数量、产品链接。经理收到一封电子邮件通知：“Ural Mechanisms LLC 提出新的 CP 请求，3 个职位，金额为 847,000 卢布。”同时，WooCommerce 管理面板中会出现一条通知 - 仪表板显示未处理请求的数量。
经理在管理面板中打开请求并查看全貌：客户是谁、来自哪个组、他有哪些购买历史记录、他请求什么。最有趣的部分开始了——对话系统。经理不会访问电子邮件客户端，也不会打开 Excel。请求卡中有一个聊天功能 - 就像 CRM 系统中的对话一样。经理写道：“下午好，阿列克谢。对于 HVLP-46，订购 10 桶或以上时，我们可以额外提供 5% 的折扣。对于散装 TM-5，最低数量为 1000 升。我们将在一小时内准备好指挥所。”客户通过电子邮件收到通知，并可以通过电子邮件（响应被拉入系统）或通过他在网站上的个人帐户进行回复。
我思考了很长时间是否需要这个对话系统，或者标准的电子邮件通知是否足够。实践表明，对话是专业乐器与工艺的区别。没有它们，一切都会陷入我们想要消除的电子邮件乒乓球中。当每个 CP 请求的对应关系存储在 WooCommerce 中时，经理可以看到与客户端通信的完整历史记录。如果经理生病了，他的同事可以在不丢失上下文的情况下接手这笔交易。如果客户打电话询问问题，经理会打开请求卡并查看昨天商定的内容。这似乎是显而易见的，但请相信我，我见过一些公司，经理们在个人收件箱中协商 CP，当有人辞职时，整个故事都会随之而来。
因此，经理准备了一份商业提案。他调整请求卡中的价格 - 在某处给出折扣，在某处更改数量，并添加有关交货和付款条件的评论。点击“创建CP”，系统自动生成PDF文档。不仅仅是一张价格表，而是一份完整的商业报价，其中包含公司标题、徽标、详细信息、印章和签名。可以打印、向导演展示并附在合同上的东西。请求状态自动更改为“CP已发送”，客户收到一封附有PDF的电子邮件。
客户打开 PDF，查看价格，与管理层讨论。他认为一切都很好 - 他进入网站上的个人帐户，打开请求并单击“接受 CP”。或者如果他不满意，他会在对话中写道：“第二名的价格很高，竞争对手的报价便宜8%。”经理更正提案，生成新的 PDF 版本，然后重新发送。这个循环可以根据需要重复进行——整个版本历史记录都保存在系统中。
接受报价后，请求会自动转换为固定价格的 WooCommerce 订单。不是按照当前的目录价格，而是按照谈判期间商定的价格。这是一个基本点 - CP 中固定的价格不应改变，即使第二天目录中的价格提高了 10%。
让我更详细地讨论此过程的几个关键要素，因为像往常一样，细节决定成败。
我将从 PDF 自动生成开始，因为这是市场上大多数解决方案失败的地方。我见过生成“PDF”的插件 - 本质上是通过浏览器另存为 PDF 的 HTML 页面。没有字体，没有标记，没有细节。向客户展示这样的文件是一种耻辱，会计部门根本不会接受它进行工作。我们的 PDF 生成器创建的文档看起来像真正的商业提案，是在 Word 或 InDesign 中准备的。标题中包含公司徽标和完整详细信息（TIN、KPP、OGRN、法定地址）。正文中有一个表格，其中包含头寸、价格、数量、金额。以下是报价总额、付款和交货条件以及报价有效期。最重要的是，授权人签名的印章和传真。所有这些都在管理面板中配置：上传徽标、印章、填写详细信息、选择模板 - 然后每个后续 CP 都会自动生成。
我记得我们的一位客户——一家轴承销售公司——向我展示了他们之前寄来的一台变速箱。这是一个 Excel 文件，在单元格 A1 中插入了一个作为图片的徽标，表格边框会移动，公式也会时不时地飞走。经理花了30-40分钟准备每个CP，因为一半的时间都花在了格式化上。切换到自动 PDF 生成后，这个时间减少到两分钟 - 单击“创建 CP”并检查结果。
现在关于请求状态 - 这似乎是一件小事，但它们是将混乱变成受控过程的人。我们实现了五种状态：“新”、“处理中”、“CP 已发送”、“已接受”、“已拒绝”。每次转换都会向双方（客户和经理）发送电子邮件通知。经理不能忘记该请求，因为仪表板上有一个未处理的计数器。客户总是知道他的请求处于哪个阶段，因为他可以在他的个人帐户中看到状态。这是一个陈词滥调的流程透明度，但它确实为客户信任创造了奇迹。
如果客户不仅想问价，还想还价怎么办？这就是优惠系统存在的原因。经理创建报价（他自己的 CP），客户可以创建还盘（他自己与其他价格的还盘），经理接受或提出新报价。事实证明，这是一场成熟的拍卖，只是不是公开的，而是一对一的。我看到了这种机制如何为我们销售特种设备的客户发挥作用 - 平均交易要经过三到四轮谈判，而以前所有这些都是通过信函完成的。现在，每一轮都是系统中的新报价，具有固定的价格和条件。如果六个月后客户说“他们向我承诺了这个价格”，经理就会打开故事并展示到底同意了什么。
B2B 团体如何改变游戏规则
报价请求并不存在于真空中。当与 B2B 分组和定价系统集成时，其价值会成倍增加。让我解释一下它在我们的模块中是如何工作的，因为正是这种连接将成熟的 B2B 解决方案与简单的反馈表单区分开来。
每个 B2B 客户都属于一个特定组：“经销商”、“批发商”、“VIP 合作伙伴”、“零售”。每个组都有自己的定价规则 - 基本价格的百分比折扣、固定批发价格、分级定价（拿得越多越便宜）。当客户创建 CP 请求时，其购物车中的价格已根据其所在组进行计算。经理可以看到基本价格、客户价格和差价，并可以有意识地做出有关额外折扣的决定，了解利润。
我遇到过这样的情况：经理“从基本价格”给予折扣，但不知道客户已经在享受 15% 折扣的团体中。结果，总折扣达到了30%，吃掉了全部利润。这对于我们的系统来说是不可能的 - 经理可以直接在 CP 请求卡中看到定价的全貌。他了解为客户群体设定的价格、可接受的最低价格（底价）是多少，并可以在给定的范围内做出决定。
我认为还有一件事至关重要：规则继承。我们的客户群体是分层的 - 例如，“乌拉尔地区”群体继承了“经销商”的规则，但额外享受 3% 的物流折扣。当乌拉尔地区的客户请求 CP 时，系统会自动应用所有定价级别：基本经销商折扣加上地区奖金。经理不需要记住这一点或手动计算 - 一切都是自动计算的。
现在让我们来谈谈许多人忽视的东西，但它从根本上改变了 B2B 销售的有效性 - B2B 钱包。这是我们为老客户实施的预付余额机制。工作原理很简单：客户预付款（例如，将 500,000 卢布转入账户），这笔金额将记入他在 WooCommerce 中的“钱包”。当接受 CP 时，付款会自动从钱包余额中扣除，无需额外的付款交易。
为什么需要这个？我将用一个例子来解释。我们的客户之一是一家汽车机油经销商，每周约有 200 名常客下订单。此前，每个订单都会经历一个完整的周期：开发票、等待付款、检查收货、发货。周期需要3-5个工作日。有了钱包，老客户每月补充一次余额，然后只需请求 CP 并接受即可 - 钱会立即记入借方，并在同一天开始发货。从请求到发货的时间已从五天缩短到几个小时。对于营业额是盈利能力关键因素的企业来说，这是一个巨大的差异。
钱包与通知系统集成：当资金存入、每次借记以及达到最低余额时，客户都会收到一封电子邮件。经理可以直接在 CP 请求卡中看到客户钱包的余额，并可以立即说：“您的余额有 340,000，CP 为 287,000 - 有足够的资金，我们今天可以发货。”这消除了整个通信层并显着加快了流程。
如果从会计部门的另一面来看呢？每笔钱包交易都记录有元数据：日期、金额、操作类型（存款、冲销、退货）、关联订单或 CP。会计师可以下载任何时期的交易历史记录并将其与银行对账单进行比较。我们并没有重新发明轮子——我们只是做了长期以来在批发 ERP 系统中有效的事情，只在 WooCommerce 内部进行，而不需要部署单独的会计系统。
电子邮件通知：B2B 流程的无名英雄
我可以单独写一篇关于通知系统的文章，因为它是当它正常工作时不可见的东西之一，但当它不能正常工作时却非常明显。在 B2B 销售中，错过通知就意味着失去交易。客户发送了请求，但没有收到确认 - 他认为该网站无法正常工作并转向竞争对手。经理没有看到新的请求 - 客户等了两天，很生气并打电话投诉。情况熟悉吗？我们也有它们，直到我们建立了一个涵盖流程每个阶段的通知系统。
对于每个重大事件，都会向客户和经理发送一封电子邮件。新请求 - 客户收到确认“您的请求已被接受，编号 RFQ-2024-0347，经理将在 2 小时内与您联系”，经理收到“Mechanics LLC 对 5 个职位的新请求，金额 120 万卢布”。经理在对话中做出回应 - 客户端收到包含消息文本的通知。 CP 已准备就绪 - 客户收到 PDF 作为附件。情况已经发生了变化——双方都知道。
但真正重要的是 - 这是大多数插件所没有的 - 是将通知与模块的整个电子邮件系统集成。我们不只是通过 wp_mail() 发送电子邮件。我们有一个成熟的 SMTP 模块，可以跟踪投递、记录每封已发送的信件，并在出现错误时重新发送。经理可以查看信件日志，看到：“CP的信件于14:32发送给客户，于14:47打开，PDF于15:03下载。”它不仅仅是一种便利——它还是一种销售管理工具。如果客户打开了 CP，但在 24 小时内没有回复，经理就知道是时候打电话澄清是否有任何问题了。如果信件没有送达，经理会立即知道并可以通过其他方式联系客户。
信件模板在管理面板中配置。您可以更改文本、添加变量（客户名称、请求编号、项目列表、金额）、自定义品牌（徽标、颜色、签名）。每封电子邮件看起来都很专业——不像 WordPress 的系统通知，而是像企业的企业通信。
我对我们根据客户反馈添加的一项功能感到特别自豪。这是给领导的摘要。每天一次或每周一次，销售部门负责人会收到一份汇总：已收到多少请求、已处理多少个、已接受多少 CP、转化情况是多少、平均账单是多少。如果没有此摘要，经理将被迫进入 WooCommerce 管理区域并自行计算数字 - 我们都知道经理这样做的频率。也就是说，从来没有。但是一封包含两个关键指标的电子邮件会被每个人打开并阅读。
个人账户：批发商自助服务门户
你知道我喜欢优秀 B2B 平台的什么吗？它们通过为客户提供自行解决问题的机会来减轻经理的负担。温和地说，您在 WooCommerce 中开箱即用的个人帐户是一个不起眼的景象。送货地址、订单历史、密码更改。对于零售来说——足够了。对于 B2B 来说——少得离谱。
在我们的模块中，B2B 客户的个人帐户是一个成熟的自助服务门户。 “我的请求”部分显示所有 CP 请求的完整历史记录以及当前状态。客户端可以看到哪些请求正在进行中、哪些 CP 正在等待他的决定、哪些事务已经完成。可以提出任何请求并重新阅读与经理的所有通信 - 对话、报价、还价。可以下载任何 PDF 版本 - 当前或以前的版本。
但还有其他事情。客户不仅可以通过购物车创建新的 CP 请求，还可以直接从其个人帐户创建新的 CP 请求。此外，他还可以使用“采购表”——保存他定期采购的成套商品。假设客户每个月都会订购相同的 15 种油。他创建了一个采购清单并保存，下次他只需单击“请求此清单的报价”即可。无需再次浏览目录、搜索产品并添加到购物车。单击三下 - 请求就发送给了经理。
我记得与我们一家客户公司的销售经理的一次谈话。她说：“以前，我花了一半的工作日时间通过电话接受订单 - 客户指定头寸，我将其输入 1C，然后检查可用性。现在，客户通过网站创建自己的请求，我将这段时间用于与新客户合作。”这位经理每天处理 25-30 个请求，而不是之前的 12-15 个，而且错误也更少，因为客户自己从目录中选择商品，并且不会在电话中口述“液压油……这是什么……嗯，和我们上次取的一样。”
子账户是另一个对 B2B 至关重要的故事。在大公司中，不止一个人参与采购。有一个买家产生请求。有一名供应部门负责人负责协调。有一名会计师检查文件。我们的子账户模块允许您在一家 B2B 公司下创建具有不同访问权限的其他用户。买家可以生成请求，但不能接受CP。经理可以接受 CP，但不能更改细节。会计师只能看到财务文件和钱包交易历史记录。这并不是一种奢侈——这是大型 B2B 客户的真正需求，如果您的平台无法做到这一点，您就会失去需要这些功能的大客户。
我长期以来一直在思考我们需要将 RFQ 与其他 B2B 功能集成到多深的程度。您可以做最少的事情：申请表、给经理的电子邮件、手动回复。很多人都这样做，而且从形式上来说它确实有效。但“有效”和“有效”是两个不同的层面。当所有组件（客户组、定价、钱包、子帐户、对话框、PDF）连接到单个系统时，就会产生协同作用，而这是通过将五个不同的插件粘合在一起所无法获得的。经理在一个界面中工作，客户在一个个人帐户中看到所有内容，在模块之间移动时数据不会丢失，并且报告基于完整且一致的数据。
还有一个很少被谈论的方面，但对于有历史的公司来说至关重要：版本控制和审计。 CP 请求系统中的每个操作都会被记录 - 谁创建了请求、谁更改了价格、谁接受了报价、谁生成了 PDF。一年后，当客户说“我们得到了特殊条件的承诺”时，经理可以恢复完整的谈判时间顺序。对于与政府客户或大公司合作的公司来说，CP 中的每一分钱都可以接受审计，这不仅是一种便利，而且是必要的。
我想单独谈谈与1C的整合，因为对于俄罗斯公司来说这往往是一个决定性因素。我们的 KP 请求模块与 1C：贸易管理同步模块集成。这在实践中意味着什么？当经理创建 CP 时，价格和余额会实时从 1C 中拉出。当 CP 被接受并创建 WooCommerce 订单时，该订单将自动导出到 1C。会计在通常的系统中工作，经理在 WooCommerce 中工作，客户在网站上的个人帐户中工作。没有人会两次输入相同的数据。
我遇到过一些公司，销售经理首先在 WooCommerce 中接受订单，然后在 1C 中手动创建订单副本，然后在 1C 中开具发票，然后从 Outlook 将其发送给客户。四个系统、四个手动操作、四个潜在错误点。通过我们的连接，这只是一项操作 - 接受 CP，其余的将自动发生。
我们来谈谈数字，因为商业只懂金钱的语言。 B2B 销售经理平均每天处理 15-20 个销售请求。每个请求需要 30-45 分钟：在目录或 1C 中查找产品、考虑折扣计算价格、在 Excel 或 Word 中创建提案、发送给客户、等待响应、调整、重新发送。一项例行操作每天需要 7-10 小时。通过我们的模块实现自动化，一个请求的处理时间可减少到 10-15 分钟，因为价格是自动计算的，PDF 一秒钟生成，并且对话在一个地方进行。经理每天可以处理 40-50 个请求，或者将腾出的时间用于吸引新客户。计算一下节省的费用：如果一名经理每月为公司花费8万卢布，而他的效率提高了一倍，这相当于在不增加成本的情况下雇用了第二名经理。
我们跟踪的另一个指标：CP 请求到订单的转换。对于我们的客户来说，在实施该系统之前，转化率为 25-35% - 每四个 CP 请求中，只有一个转化为交易。实施后 - 45-55%。为什么？因为响应速度提高了（客户没有时间留给竞争对手），提案的质量提高了（专业的 PDF 而不是歪歪扭扭的 Excel），提醒系统不会让你忘记待处理的请求。
但老实说：自动化 KP 请求并不是一根魔杖。如果你的价格没有竞争力，如果货物缺货，如果经理没有接受过使用系统的培训，那么这些都无济于事。技术对于业务流程来说是一个倍增器，而不是替代品。好的流程乘以好的工具会产生很好的结果。糟糕的流程与同一个工具相乘会产生自动化的混乱。
为什么我们将其构建为单个插件而不是使其成为单独的产品？
这是我经常被问到的问题，值得诚实的回答。市场上有单独的 RFQ 插件：YITH Request a Quote、WooCommerce B2B、NexusPress Quote 等等。为什么不使用它们呢？
我将尝试不是抽象地回答，而是用具体的例子来回答。假设您输入 YITH 请求报价（最受欢迎的之一）。它为您提供申请表和电子邮件通知。不错。但它对您的 B2B 组一无所知 - 因为客户组是由另一个插件（假设是 B2BKing）管理的。它不会生成 PDF - 它需要第三个插件（WooCommerce PDF 发票）。它不支持钱包 - 第四个插件（TeraWallet）。对话系统？第五个插件甚至是第三方 CRM。子账户？第六。
您最终会得到来自六个不同开发人员的六个插件，这些插件在不同时间更新，可能会相互冲突，并且无法通信。经理在六种不同的界面中工作。在一个插件中计算的价格不会转移到另一个插件中。如果其中一根断裂，整个链条就会崩溃。每个插件每年的费用为 50-100 美元。总计 - 每年 300-600 美元，加上整合和支持的时间。
我们采取了不同的路线。 RFQ 是单个 B2B 模块的一部分，该模块包括客户组、定价、钱包、子帐户、PDF 生成、对话系统和电子邮件通知。所有组件均由一个团队开发，使用一个数据库、一个设置系统、一个管理界面。当“经销商”组的客户生成 CP 请求时，系统会自动应用经销商价格，经理会看到钱包余额，对话中会提供完整的关系历史记录，并会生成包含正确详细信息的 PDF。所有这一切 - 一个插件、一个许可证、一个更新。
老实说，将所有内容放入一个插件中是一项工程挑战。制作一个只做一件事的小型、高度专业化的模块要容易得多。但用户（包括经理和客户）的便利性需要集成。 B2B 流程本质上是端到端的，它贯穿系统的所有层。将其切成孤立的碎片意味着会产生裂缝，从而导致数据和时间丢失。
我喜欢汽车的比喻。你可以从一个制造商那里购买发动机，从另一个制造商那里购买变速箱，从第三个制造商那里购买悬架，从第四个制造商那里购买电子设备。从技术上讲，它们可以一起工作——如果你花很多时间去适应的话。但没有一个理智的人会这么做。购买一辆所有部件都设计为可以协同工作的汽车。商业软件的逻辑是一样的。
顺便说一句，关于实施的实际方面 - 我想消除我一直听到的一个神话。 “我们的经理无法弄清楚。”你知道，我也是这么想的。当我们第一次向其中一个项目的经理展示该系统时，我预计会遇到阻力。人们习惯了 Excel、邮件、盘子 - 突然间他们可以通过 WooCommerce 网络界面进行工作。但令人惊奇的事情发生了：半天后经理们就习惯了。而且不是最年轻、技术最先进的销售经理，而是四十岁以上、认为 Excel 是技术进步顶峰的普通销售经理。为什么？因为界面是为他们的任务而设计的。不是针对开发人员的任务，不是针对主管的任务，而是专门针对每天处理数十个请求的经理的任务。
当您打开仪表板时，您会看到带有彩色状态指示器的请求列表。红色的是新的，未经处理的。黄色——工作中。绿色 - CP已发送，正在等待客户的决定。灰色——完成。经理立即了解火在哪里，现在需要注意什么。单击请求即可在一个屏幕上查看所有信息：客户、头寸、价格、对话、历史记录。无需在选项卡之间切换，无需在邮件中搜索信件。一切都在一处。这听起来很平庸，但正是这种“平庸”每天为经理节省了两到三个小时。
还有一个细节看似小事，但实际上却至关重要：对话中的快速答案。我们注意到，80% 的情况下，经理都会用相同的短语来回应客户。 “谢谢您的请求，指挥所将在一个小时内准备就绪。” “该商品的最低数量为 5 件。” “数量从 10 件起可享受折扣。”我们添加了快速响应模板，经理可以一键插入并在必要时进行编辑。琐事？但是，当经理每天有 30 个请求并且需要为每个请求编写 2-3 条消息时，节省的成本是显而易见的。时间就是金钱，尤其是在销售领域，响应速度与转化率直接相关。
一个单独的对话是移动性。经理并不总是坐在电脑前。他可能正在与客户开会、出差或在仓库里。人们经常告诉我们，“如果能够在旅途中看到手机上的请求并做出响应，那就太好了。” WooCommerce 管理面板并不是特别适合移动设备，但我们特意设计了 CP 请求界面，以便在移动屏幕上正常工作。经理可以在电话上打开请求、阅读对话、发送快速响应、更改状态。当然，不可能完全用手机组装CP，但是可以快速响应客户的请求，让他不必等到明天。
另一点值得一提的是 KP 请求的分析。数据就是石油，当所有请求都流经单个系统时，您将获得手动流程从未有过的分析。平均请求处理时间是 47 分钟还是 4 小时？哪一位经理处理得最快，哪一位经理有系统地拖延？最常需要哪些产品？来自新客户的请求百分比是多少，来自老客户的请求百分比是多少？季节性如何影响请求数量？所有这些都在报告中可见，这使得销售部门主管能够根据数据而不是感觉做出决策。我知道一家公司，在实施请求分析后，CP 发现一名经理平均需要 52 分钟处理请求，而另一名经理则需要 3 小时。区别不在于能力，而在于第二位经理浪费时间搜索 1C 的价格，因为他不知道提取数据的可能性。五分钟的培训解决了这个问题，但如果没有分析，没有人会注意到它。
我经常听到这样的问题：这是如何扩展的？如果我们每天的请求不是 20 个，而是 200 个怎么办？还是2000？答案很简单：我们最初设计的系统是为了高负载。 CP 请求、职位、报价、对话 - 所有这些都存储在自定义数据库表中，而不是像许多插件那样存储在 WordPress 元字段中。差异是根本性的。如果您每年有 50,000 个请求，并且每个请求都附加了 10 个职位，则相当于 500,000 条记录。在 wp_postmeta 表中，WordPress 会连续转储所有内容，如此大量的数据会将任何请求变成令人痛苦的长时间操作。在具有正确索引的自定义表中，相同的数据在几毫秒内得到处理。我们在包含 16,844 个产品和数千个请求的实时站点上对此进行了测试 - 没有性能问题。
最后，关于数据安全，因为商业报价包含机密信息：价格、折扣、条件、详细信息。 RFQ 模块的所有 API 端点都通过检查访问权限进行保护 - 客户只能看到他的请求，经理可以看到一切。 PDF 文件在服务器上生成并存储在无法通过 URL 直接访问的安全目录中。对话在传输过程中被加密，并且只有特定请求的参与者才能访问它们。这似乎是一个显而易见的要求，但我见过一些插件，其中销售提案的 PDF 存储在 wp-content/uploads/ 中，文件名可预测，任何人都可以通过在 URL 中替换不同的数字来下载竞争对手的提案。对于我们的系统来说这是不可能的。
我想以一个看似不明显的想法来结束。询价不是技术功能。这是与客户的接触点，是业务关系形成或破裂的时刻。每个 CP 请求都是一个已经感兴趣、已经找到您的产品并且已经准备好对话的客户。唯一的问题是您将如何方便、快速和专业地回答他。
当买家在提出请求后一小时收到一份设计精美的提案时 - 考虑到其数量、带有印章和详细信息，为他的团队提供准确的价格 - 他知道他正在与一家认真的公司合作。当他要等两天经理在Excel中手动组装CP时，他认为这家公司一团糟。第一印象是在第一分钟内形成的，与 CP 合作的工具是您的批发客户的业务形象。
WooCommerce 可以成为一个强大的 B2B 平台。不是取代 1C，不是取代 ERP，而是除它们之外，作为客户的展示和自助服务门户。但要做到这一点，需要正确的 B2B 层，而 RFP 是该层的关键要素。我们花了数百个小时来正确构建它 - 通过对话框、PDF、钱包和集成。如果您在 WooCommerce 上构建 B2B，并且希望您的客户不仅仅是滚动浏览目录，而是通过该网站实际购买 - 看看它是如何工作的。安装 COS WP Woo 电子商务，设置 CP 请求模块并向您的销售部门展示。经理们会感谢你的。