这家店今天的样子。
截图取自线上网店，不是效果图或设计概念稿。商品照片属于客户，是他们带着自家装备在真实车辆上实地拍摄的。围绕照片的店面属于我们。
首页。质保、发货速度和付款方式都写在最上方，因为露营者在购买一顶装在车顶上的帐篷之前，关心的大多是下单之后会发生什么。
集合页。价格和库存筛选、完整分类树和商品网格全部由平台提供，分类结构从旧店原样带过来，而不是凭记忆重建。
同一个首页在 390 像素宽度下的效果。通栏按钮、清晰易读的正文、没有任何横向滚动，对一家顾客常在营地里浏览的网店来说，这一点很重要。
一家靠插件勉强撑着的 WooCommerce 网店。
Intenze 来找我们时用的是 WooCommerce，这也是大多数新西兰独立零售商最终会走上的路。网店本身免费，然后网店需要做的每一件事都是一个插件，得有人挑选、付费、配置并持续更新。筛选是插件，首页通知是插件，把订单交给快递也是插件。一旦某个插件在更新后罢工，最先发现的是店主，而不是供应商。
帆布生意的商品目录也比较棘手。遮阳篷、替换用的升顶帆布、罩子和支杆都有各种尺寸和适配规格，顾客要对照自己的具体车型来挑，所以商品结构和分类树承担着实际作用，而不是摆设。所有东西都必须完整带过来，包括商品及其变体和图片、集合，还有搜索引擎和论坛帖子早已指向的页面地址。一次悄悄丢掉一半内容的迁移，不是把店搬了家，而是让店从头再来。
一家网店，以及支撑它的整套机制。
商品目录是搬过来的，不是重建的
商品、变体、图片和分类结构作为一整套数据从 WooCommerce 迁移过来，而不是变成一份要有人对着键盘逐条处理的待办清单。集合页、按价格和库存筛选以及站内搜索读取的是同一份目录，所以一件商品有变动，各处同时更新，而不是像插件堆叠那样，要在四个各自缓存的地方分别生效。
结账和订单由平台提供
购物车、结账、通过 Stripe 的银行卡支付、订单管理以及顾客收到的各类邮件，全都是平台的一部分，而不是四个独立的扩展。订单确认和发货通知以网店的名义和配色发出，顾客回信的地址也是一个设置项，这一点的重要程度往往超出所有人的预期。
发货无需重新录入地址
已付款订单会自动转交快递系统。运单号回传后，订单自动变为已履约，顾客会收到一封带有网店自有品牌的物流跟踪邮件。没有人需要打开两个标签页，把街道地址从一个复制到另一个。这是小型零售商一天中最容易出错的一分钟，一旦出错，就要多付一笔重新派送费。
店铺通知只是一个设置项
当网店需要告诉每一位访客某件事，比如歇业、暂停发货、订单处理方式有变，那就是一条带文案和截止日期的通知，而不是一个要安装、事后还得记得卸载的插件。它每次访问只显示一次，手机上同样好用，并在设定日期自动关闭。
这家店提出需求时，会发生什么。
这部分内容写不进功能清单。在插件堆叠的方案里，每一项都意味着一下午的搜索、安装和测试。在这里，发一条消息，事情就办好了。
一个已经不存在的邮箱
需求。网店的一个邮箱已经停用，再也无法收信。可它仍然印在联系页面上，仍然是订单确认和发货通知的回信地址，也仍然在接收每一张新订单的抄送。
我们的做法。我们一次性全部改掉，包括公开页面、网店发出的每一封交易邮件的回信地址，以及内部通知抄送。如今顾客回复发货邮件，就能联系到真人。在插件堆叠的网店上，这类问题往往悄无声息地坏上好几个月。
歇业一周，照常接单
需求。网店要歇业一段时间，希望每位到访的顾客都能看到用店主原话写的通知，欢迎照常下单，但要等网店重新营业后才会发货。不要一条没人看的横幅，也不要干脆关店。
我们的做法。通知第二天就上线了，网店的措辞原样保留。它每次访问只出现一次，手机上同样好用，并在重新营业当天零点自动关闭，没有人需要记着去撤下它。
第一家用上我们配送应用的网店
需求。包裹一直是手工预订的，一单一单地在一个完全不知道网站存在的快递后台里操作。网店希望把两端打通，并且愿意做第一家在正式环境中运行它的网店。
我们的做法。我们在平台上做出了 Shipping 应用，并把这家网店接入 Starshipit，借此可以对接新西兰和澳大利亚的大多数快递公司。订单发出，物流信息回传，顾客收到通知。因为这家店率先提出需求，如今 WebForger 上的每一家网店都可以直接开启它。
这家网店正在运行我们的两个应用。
平台上的每一个应用，每个网站都包含，不收月费。这家店打开的两个，一个负责把订单发出去，一个负责告诉大家最新情况。
Shipping
免费
连接已付款订单和打印面单那一端的桥梁。这家网店使用的是 Starshipit 连接，订单推送过去，运单号回传，订单自动标记为已履约，物流跟踪邮件以网店的名义发出。
Announcements
免费
全站通知，可以是横幅也可以是弹窗，各自设定开始和结束日期。在后台写一次，任何设备上的到访访客都能看到，日期一过自动下线，而不是等有人想起来再撤。