如何帮助客户在一个大型或技术目录中找到正确的产品

为何普通类别菜单让技术买家失败

分类菜单假定客户已经了解了卖方如何组织目录。 这对简单的范围有效,但当买家开始使用机器模型,尺寸,操作条件,相容性问题或替换部分编号时,它就会崩溃. 客户可能认出问题,而不知道哪个内部类别载有答案.

被引导的发现者扭转了旅程 它从顾客所知道的开始,只提出缩小有效选择范围的问题,并退回一份有目录证据支持的短名单。 搜索和过滤仍然很重要,但它们成为更广泛的决定路径的一部分,而不是目录中的唯一方法.

从客户决定开始,不是每个可用的字段

在建立发现者之前,选择一个必须帮助某人做出的决定. “为这台机器寻找正确的替换带”是可以检验的。 “使目录更容易”不是。 观察客户向销售人员提问的问题,支持团队要求的细节以及产品被退回或放弃的原因.

把这些观察变成一个简短的决定树。 首先询问高值问题并隐藏不改变推荐的字段. 如果机器制作和模型确定相容家庭,在彩色或交付偏好之前询问. 如果测量的大小是必需的,请解释如何进行测量以及使用哪个单位.

• 顾客到时通常知道些什么?
• 哪一个答案可以去除数量最多的不合适的产品?
• 哪些兼容性规则绝不可视为优先?
• 除了建议之外,还应提供哪些证据?
• 发现者何时能停下来寻求人类的帮助?

构建结构化产品事实的查找器

一个可靠的建议需要字段,在整个目录中意味着同样的事情。 规范化单位,属性名称,品牌和模型参考,产品类型和相容性关系. 保持显示副本与用于匹配的值相分离,因此措辞变化不会改变基本规则.

稳定的识别资料同样重要。 GS1解释说,GTIN独有地识别出一个贸易项目。 在GTINS适合的情况下,与平台产品和变体ID,厂商参考和内部SKU一起保存. 不要依赖可编辑的标题作为推荐或更新的产品的身份.

1. 列出客户用来区分合适产品的要求.
2. 将每项要求映入核准的目录领域或关系.
3. 在写入匹配规则前规范值和单位 .
4. 在每个结果上保持稳定的产品和变异标识.
5. 旗下缺失或相冲突的事实来审查而不是猜测.

从偏好中分离出硬相容规则

硬规则决定产品是否有效. 偏好有助于对若干有效产品进行排序。 不适合客户机器的部分不应该出现,因为它很受欢迎,股票或商业上具有吸引力。 一旦取消无效的选项,品牌,价格范围,交付时间或材料等偏好可以订购所剩结果.

使排除情况可以理解。 “与2022年示范年不相容”比默默地消失的结果更有用。 当目录中没有足够的证据可以安全回答时,说出所缺少的东西,并提供明确的支持路径. 诚实的无结果路径比发明的推荐更能保护信任.

使用过滤器和搜索作为引导行程的一部分

Shopify的官方指南允许商人配置商店前置过滤器,并通过Search & Discovery定制产品发现. 当产品数据完整,客户了解现有属性时,这些控制是有用的。 发现者可以使用同样的经批准的产品事实,同时在订单中将这些事实作为问题提出,买方自然予以答复.

保持两个经验的联系. 通过搜索抵达的客户,应当能够通过兼容属性来完善. 发现者的结果应该链接到真正的产品或变体页面,而不是重复的登陆页面. 如果Shopify是商店前端,则使用授权的商店连接,并在整个匹配和交接过程中保留其产品和变种身份.

一个具体的例子:选择替换部分

想象一下一个目录,里面有数千个横跨草坪设备,摩托车,工业驱动器和车辆的带子. 买方搜寻“123型号的带子”,但若干制造商使用类似的型号名称。 发现者首先要求工业,然后是制造商和产品类型,然后是准确的型号. 它只有在模型记录不完整时才能请求维度.

结果是搜索页面不长. 这是一份经批准的兼容性记录与答案相符的产品简表. 每个结果都显示对应的机器、相关尺寸、产品参考和客户必须检查的任何资格。 如果两个产品仍然是可能的,发现者会解释区别而不是默默地选择.

设计结果页以支持自信的决定

显示为什么选择每个产品 。 重复客户的重要答案,突出匹配和区分所需检查与可选偏好的属性. Google的产品变异文档描述了表达母产品变异的方法;目录中同样学科是有用的,因为大小,材料或图案必须始终附在正确的可选变体上.

良好结果页也保留了正常的商业行为:当前可用性,价格,交付信息,产品图像,以及通往正确产品细节页的直接路径. 不要将建议变成死胡同,迫使客户重复搜索.

• 简要解释结果为何合适
• 确切的产品或变种身份
• 匹配的相容性事实和维度
• 任何需要客户验证的条件
• 目前来自商店前端的商业信息
• 模糊案件的人帮路线

测量发现者是否真正有用

追踪完成的寻找者行程,无结果原因,改进,产品点击和请求帮助. 在同意和平台能力允许的情况下,将这些信号同加载、购买和返回结果进行比较。 目的是找出目录漏洞和混淆问题,而不是声称每次点击都证明了正确的建议.

与目录和客户服务小组审查失败的旅行。 频繁的无结果可能表明产品关系缺失、客户名词不明或真正没有支持的要求。 改进应更新所规范的产品事实或问题路径,以便一致解决下一个客户的同一问题.