支持餐饮、零售、预约与票务等商户场景。
P I S E L L · S T O R E D E V I C E · K I O S K
不只完成点单，
还要把餐交到对的人手里。
我参与并主导 Kiosk 自助点单体验，把堂食、外带、桌号牌、呼叫名、取餐器和取餐位置整理成可配置的现场履约规则，并把这些规则接回商品、订单、支付与门店终端。
KIOSK · FOUR-STEP SELF-SERVICE FLOW
查看完整操作链路 ↘
01 / CONTEXT
用户看到的是点单页，门店需要的是一条可执行的履约链路。
Kiosk 是 Pisell 全渠道 SaaS 在门店现场的一块消费者终端。它既要让用户站立、触屏、快速完成操作，也必须向后传递准确的用餐方式、取餐位置、识别凭证、附加费和支付状态。
负责业务梳理、交互、视觉、状态与规范交付。
不是孤立设备，而是 Merchant Core 下的一段门店链路。
把“谁、在哪、用什么凭证取餐”变成系统可读的数据。
02 / FULFILMENT MODEL
同一笔订单，会因为入口、用餐方式和现场条件走向不同路径。
下面的模型按真实设计稿整理。切换场景可以看到每种路径所需的信息、系统判断和对应界面，不再把所有用户都塞进同一套流程。
KIOSK · DINE-IN · TABLE SERVICE
堂食并送到桌：先拿到可执行的桌号凭证
用户选择堂食后，系统继续确认座位区域，并要求输入桌号牌。订单进入后厨时已经带有服务位置，员工不需要再次询问。
- 选择堂食
- 确认 Inside / Outside
- 输入桌号牌
- 结账并把桌号写入订单
界面证据来自 Kiosk Figma 源文件中的 Meal type、Pickup identifier、Pickup location、Seating area 与 Buzzer 流程。本页只整理与案例叙事相关的关键界面。
03 / DESIGN JUDGEMENTS
把业务分支放在该判断的位置，不让用户为系统补数据。
我把设计判断集中在三件事上：先分流，再收集履约标识；让价格变化在确认前出现；用同一套底部操作区维持长流程中的方向感。
01 · ROUTE FIRST
先分堂食与外带
这一步决定后续是否需要座位区、桌号、取餐位置或取餐凭证，应该出现在支付前，而不是订单完成后再补问。
02 · PRICE BEFORE COMMIT
附加费跟着选项出现
当用餐方式改变价格，界面同时显示总附加费和单项费用，让用户在 Checkout 与 Confirm 之前完成判断。
03 · IDENTIFIER MATCHES HANDOFF
取餐凭证必须匹配现场动作
送到桌使用桌号，柜台取餐使用呼叫名或取餐器。凭证不是附加字段，而是后厨和前场完成交付的关键数据。
04 / END-TO-END JOURNEY
从进入 Kiosk 到支付完成，操作和订单状态持续对应。
履约判断不是单独一页，它嵌在完整的发现、选择、配置、确认、支付与完成流程中。这里保留原项目中能说明链路的真实界面。
先选业务，再进入流程
把餐饮、购票和线上票兑换放在终端第一层，避免不同业务共用一条冗长路径。
站立触控下快速选品
左侧分类、顶部二级筛选和固定购物车，把大屏上的浏览范围与下一步持续放在视线内。
规格、套餐与缺货反馈
必选、可选、价差与售罄状态沿页面顺序展开，底部持续保留数量和加入购物车动作。
结账前核对完整订单
商品、数量、规格、备注、税费和总价在同一页对齐，并允许用户就地编辑或移除。
扫码登录与会员权益
在设备能力与人工输入之间提供两条明确路径，让 Wallet Pass、积分和优惠接入订单。
完成后给出取餐动作
明确打印状态、取餐号与返回首页倒计时，让支付完成真正落到门店交付。
EXTENSIBLE TERMINAL
同一套终端骨架，也能承载票务、储值与辅助服务。
这些不是额外拼贴的页面，而是同一 Kiosk 信息架构、底部操作区、选择组件和状态反馈在不同业务中的复用结果。
票务时长与人数配置
将入场时长、儿童与成人数量、免费票和附加票组合成清晰的购票任务。
储值和代币套餐
余额、单选套餐、数量与价格变化共用结算骨架，适配游乐场和会员储值业务。
扫码兑换现场权益
扫描设备与手动输入互为兜底，适合线上购票、优惠券和会员权益在现场核销。
语音帮助和高频问答
用语音唤醒和任务标签承接找票、优惠、设施位置等高频现场咨询。
语言入口始终可见
语言选择固定在入口右上角，不让用户进入流程后才发现无法理解当前页面。
品牌活动与业务入口共存
品牌视觉负责吸引注意，底部业务入口负责把用户快速送往餐饮、票务或兑换任务。
以上 12 张界面均为 Kiosk Figma 源文件中用户指定节点的完整画板导出，未使用旧版占位截图，也未对界面进行拉伸或裁切重组。
05 / STATES & BOUNDARIES
无人值守设备要把异常写进流程，而不是留给现场员工兜底。
案例除了主流程，也覆盖输入、价格、库存、支付、超时和返回等边界。重点不是展示所有弹窗，而是说明每种错误如何恢复到可继续的位置。
桌号或取餐器为空 / 格式错误
确认按钮保持不可提交，并在输入控件附近说明要求；修正后保留前面的商品与用餐选择。
用餐方式触发附加费
费用变化跟随选项出现，并同步到 Item total，避免用户到最终支付页才发现价格不同。
设备未响应 / 支付失败
明确区分等待、失败和取消，给出重试或更换支付方式，避免重复扣款和重复下单。
长时间无操作
先提醒，再安全清空临时订单并回到欢迎页；用户主动返回时只回退当前判断，不直接丢失整单。
规格或商品售罄
在用户继续前说明不可用项，保留其他已选商品，并提供替换或删除动作。
站立触控与语言差异
大字号、大点击区、固定底部主操作和多语言入口共同降低短时、高频操作的负担。
06 / DELIVERY
这次交付沉淀的是一套门店终端规则，不是一组孤立页面。
我把用餐方式、座位区域、取餐位置、履约标识、费用、支付和结果状态整理成可复用的页面结构与配置规则，并与 Pisell Design System 的底部操作区、选择卡片、表单、键盘、弹层和状态反馈保持一致。后续新增门店业务时，可以继续复用这套骨架，而不必重画整条链路。