闭环
货架 → 手机 → 商品目录 → 对话 → 收银台
无需应用 · 无需硬件 · 无银行卡数据
章
01
顾客界面
是对话，不是搜索框。
顾客扫描二维码，用自己的语言开口。助手询问要完成的任务，对商品目录排序，并把取舍保留在视野中。无需安装、账户或排队。
顾客界面
手机协助，收银台成交。
浏览器会话从二维码打开。顾客可以输入或说话，同一个助手都能作答。价格和库存由实时商品目录呈现，而非由模型回忆。
- 语音或文字，同一个助手
- 在上下文中呈现组合
- 转接时带上完整对话
顾客保留自己的手机。零售商保留自己的 POS。
在顾客手中
演示
语音或文字
直接说出来。
点按麦克风或输入。同一个助手都能在顾客自己的手机上作答。
有温度的转接
重要的时刻交给真人。
商家设定转接点。完整对话随顾客一起交给店员。
对话一并转交 →
29
种语言支持
演示中启用了全部 29 种受支持的语言。
上下文中的组合
附加商品属于答案的一部分。
配件和兼容商品出现在对话中，而不是一条泛泛的推荐栏。
非营业时间覆盖
周日的班次也有同样的答案。
助手不会打卡下班。商家仍然决定它可以回答什么，以及何时由真人接手。
章
02
依据链路
让商品目录先开口。
检索先于生成。模型可以选择商品 ID 并撰写理由；它不能编写价格、库存水平或政策。
依据链路
生成之前先检索- 01
查询
顾客用自然语言提问。
- 02
检索
服务器选出候选商品。
- 03
选择
模型选择 ID 并给出理由。
- 04
验证
候选集之外的 ID 会被丢弃。
- 05
呈现
服务器写入价格、库存和规格变体。
服务器呈现的记录
SKU · T5-014Trail 5K Pack
- 价格
- £39.00
- 库存
- 店内 6 件
- 尺码
- UK 6–12
示例记录 · 请求时呈现
被拒绝的 ID
不在候选集中。
模型选择了一个服务器未检索到的商品。该 ID 会在答案呈现之前被丢弃。
ID 不在检索集中
模型的边界
它从不自行给出价格。
它从不自行给出库存水平。
它从不自行给出规格变体。
它从不自行给出政策。
0
开放网络查询
商家实时商品目录是唯一来源。
设计如此
100%
价格和库存由服务器呈现
靠架构，而非提示词。
设计如此
01
检索优先
在向模型提出任何问题之前，服务器先从商家目录中检索候选商品。模型从不搜索开放网络。
02
模型选择，服务器呈现。
价格、库存、规格变体和优惠均由服务器根据目录记录呈现。模型文字中的数字绝不是事实来源。
03
ID 经过验证
模型选择的每个商品都必须存在于检索到的候选集中。无效 ID 会在答案送达顾客之前被丢弃。
04
诚实拒绝
如果目录中没有答案，助手会如实说明并提供人工转接。未配置模型或模型不可用时，助手会说明自己无法回答；顾客可以重试或询问店员。
章
03
二维码管理器
有任务的二维码，不是一张贴纸。
按通道命名二维码，指向品类或商品，用你的颜色设计，并下载 SVG 或 PNG。停用二维码，但不会丢失它已获得的扫描记录。
Salewise
1 号通道问问跑步装备。
扫描 · 提问 · 比较 · 在收银台付款
示例货架卡片。二维码指向演示商品目录。
二维码管理器 · 示例
启用- 标签
- 1 号通道 · 跑步
- 目标
- 品类 · 跑步
- 设计
- H · 标志“SW”
- 导出
- SVG · PNG · 打印卡片
按二维码统计使用情况
示例周入口 · 门店
入口
412 次扫描 · 188 个问题 · 41 次转接
启用1 号通道 · 礼品
1 号通道
268 次扫描 · 96 个问题 · 12 次转接
启用2 号通道 · 跑步
2 号通道
203 次扫描 · 74 个问题 · 9 次转接
暂停示例控制台。二维码采用停用而非删除，因此扫描历史得以保留。
二维码不是一场营销活动。它属于决策发生的地方。
货架边缘、陈列、柜台或工作台——以它所服务的通道命名。
设计控件
颜色、标志和说明文字，均经过校验。
控制台会在生成 SVG 和 PNG 之前校验颜色、标志类型和尺寸。
按二维码统计使用情况
每个二维码都有自己的记录。
扫描、会话、提问、回答和转接均按通道和二维码记录。
章
04
对话记录
通道里究竟问了什么。
每个会话都带有发起它的二维码和通道标签。商家能看到问题、答案、推荐商品和转接——而不是一堆匿名点击的仪表盘。
会话 014 · 2 号通道
语音 · 英语
如果是首个半马，日常训练鞋更合适。它为长距离提供更多缓震；竞速训练鞋更轻，但脚感更硬。
Road Trainer 2
£110 · UK 9 有货
Tempo Trainer
£125 · UK 9 有货
价格和库存在请求时呈现 · 示例商品目录
2 号通道 · 一周
示例203
扫描
74
提问
9
转接
数据并非来自真实商家。它们展示记录的结构。
转接队列
步态分析 · 2 号通道
“哪双鞋更适合首个半马？”
需要真人
保修申请 · 服务台
“左耳机的充电功能坏了。”
模型已收集问题
每个顾客问题和助手回答都带有发起该会话的二维码和通道标签。
章
05
收银台关联
通往收银台的一条线，连接处清晰可见。
归因是对话与销售之间的匹配。商家可以看到它是精确匹配还是建模匹配，以及置信度是多少。
关联
会话 → 销售01
扫描
二维码为会话打上门店、通道和时间标签。
02
提问
问题、检索到的商品和推荐都会记录。
03
核销
助手提供一个与会话绑定的短码。
04
收银台
销售记录在 Sage 中。匹配结果为精确或标注为建模。
精确匹配
1.00
核销码从会话带到销售。建模标记为 false。
建模上限
≤ 0.92
两小时窗口内同店购物篮重叠，在任何报告中都标注为建模。
匹配方法、置信度和时间窗口随匹配一起保存。商家可以审计这次关联。
第 1 层 · 确定性
置信度 1.0核销码
销售携带来自会话的核销码。这是精确匹配：建模标记为 false，直接归因。这是对话与交易之间最强的关联。
第 2 层 · 建模
置信度 ≤ 0.92购物篮重叠
没有核销码时，系统会查找两小时内、包含助手推荐商品的同店销售。该匹配在商家报告中始终标注为建模。
为何重要
核销码给出精确匹配。否则，带时间窗口的购物篮重叠会作为建模结果报告，绝不当作事实。
每次匹配都保存其方法、置信度和时间窗口。精确匹配就是精确的。建模匹配在所有出现的地方都会标注。商家可以审计这次关联；归因不是收入项，订阅费是唯一费用。
章
06
诚实标注
已上线就是已上线。
适配器按今天可用的状态标注，而不是按路线图幻灯片上的承诺。同一条规则也适用于助手的边界。
能力标注
26 个适配器 · 5 个可用已上线
1商家今天即可使用。
- Salewise
原生主密钥集成。今天即可使用。
测试版
4适配器已构建，正在商家环境中测试。
- Shopify POS
从 Shopify 同步商品目录、库存和门店位置。
- Square
面向 Square 卖家的商品目录、库存和门店位置。
- Epos Now
EPOS 商品目录和销售导入。
- WooCommerce
WordPress 商品目录、库存和门店位置同步。
即将推出
21已列入计划或正在开发，商家今天尚不可用。
- Lightspeed X-Series (Vend)
- Zettle by PayPal
- Clover
全部 21 个计划适配器
- Lightspeed X-Series (Vend)
- Zettle by PayPal
- Clover
- SumUp Payments
- SumUp POS (Goodtill)
- BigCommerce
- Lightspeed R-Series
- Loyverse
- ERPLY
- Heartland Retail
- Adobe Commerce (Magento)
- PrestaShop
- Revel Systems
- Toast
- TouchBistro
- NewStore
- Mercaux
- Bepoz
- Ascend Retail
- Odoo POS
- Microsoft Dynamics 365 Commerce
已上线意味着适配器今天可供商家使用。测试版意味着适配器已构建，正在商家环境中测试。即将推出意味着适配器已列入计划或正在开发，商家今天尚不可用。注册表中共有 26 个适配器；目前有 5 个可用。
聊聊你的 POS边界
Salewise 不做什么。
- 01
顾客手机上的支付。交易仍由你的 POS 完成。
- 02
取代门店员工。助手会把真正重要的时刻转接给真人。
- 03
定制集成工程。新适配器单独评估并另行约定。
- 04
按归因销售额抽取佣金。订阅费是唯一费用。
- 05
它不会依据开放网络、供应商 PDF 或模型记忆作答。
- 06
它不会在顾客手机上安装应用。
- 07
它不会取代药师、机械师、临床医生或任何受监管的顾问。