这家店今天的样子。
截图取自线上网店，不是效果图或设计概念稿。品牌、摄影和文案语气属于客户，底层引擎属于我们。
改版后的首页，一张活动图承载当前的行李箱促销，紧接着就是商品集合。改版先在草稿中完成，并在私密预览链接上审阅通过后，才替换线上页面。品牌与迁移前一致，底层换了引擎。
商品页评价墙。从旧店迁来的评价与此后新收集的评价并列展示，带已验证购买标识，星级分布直接写进页面，而不是靠小部件临时加载。
同一个首页在 390 像素宽度下的效果。活动图放在标题上方而不是压在背后，重要内容没有被隐藏，也不会出现横向滚动。
一家为自己的功能付租金的 Shopify 网店。
San Michelle 来找我们时用的是 Shopify，也是大家熟悉的那套模式，先付平台费，然后网店每需要平台多做一件事，就再加一份单独的月度订阅。评价就是其中一份订阅。结账流程默认做不到的事，要么又是一份订阅，要么根本无法实现，因为 Shopify 允许商家修改订单定价方式的那部分功能，只在最高档套餐里开放。这家店想对店面有更多掌控，也想让每月账单最后那个数字小一点。
因此，迁移本身就是第一个硬性要求。所有东西都必须带过来，包括完整的商品目录及其变体、图片和集合，以及这家店在 Judge.me 上积累的评价记录。一家网店搬到新平台后如果商品页空空如也，不管发票上写着什么，它其实都是从零开始。所以我们把评价当作库存的一部分来对待，而不是一项以后再说的锦上添花。
一家网店，以及支撑它的整套机制。
完整的电商内核
商品与变体、集合、搜索、购物车、结账、Stripe 支付、订单管理和配送，全部来自平台本身，而不是来自四家彼此从未沟通过的供应商。需要修改时，只需要理解一套系统，而且整套系统都归我们所有，不必等任何第三方点头。
评价迁入，历史完整
Judge.me 中收集的评价连同评分、日期、署名和照片一起导入，并对应到相应商品上，所以这家店在新平台开张时，口碑展示已经就位。此后邀评自动进行，订单送达后系统会发出一封邀评邮件，收回的评价可以标记为已确认购买。
自动维护的商品集合
一家有这么多尺寸、颜色和系列的店，不可能长期靠手工把每件新品归入每一个相关集合。Smart Collections 让网店用规则来描述一个分组，商品上新、改价或售罄时，平台会自动更新集合成员。店里其他部分读取的都是同一份清单，第一次针对某个分组做折扣时，这一点就显出了分量。
草稿与预览工作流
改版工作在草稿中进行，草稿有自己的私密预览链接。店主在自己的手机上看到的是真实效果，标出想改的地方，而顾客正在下单的线上网店，在所有人满意之前纹丝不动。这就是审阅一个网站和审阅一张网站图片的区别。
这家店提出需求时，会发生什么。
这部分内容写不进功能清单。在大多数平台上，这类需求最后会变成去找一个差不多能用的 app。在这里，它会变成对平台本身的一次改进，其他所有网店也一并获得。
一张补差价的账单
需求。一位顾客想把一件缺货商品换成一件更贵的，而这家店没有办法在线收取差价，剩下的唯一办法，就是在电话里让顾客把卡号念一遍。
我们的做法。我们把订单编辑功能做进了平台。已付款订单的商品行可以修改，系统会为差额生成付款链接，并与原订单自动对账。功能在同一张工单内上线，如今 WebForger 上的每一家网店都可以使用。
按规则定义的商品集合
需求。这家店问，能不能像以前在 Shopify 上那样，用条件来定义一个集合，而不是每来一款新箱子都要手工归进去。
我们的做法。我们当天答复，并上线了 Smart Collections。您写好条件，平台重新计算集合成员，折扣、角标和店面读取的都是同一份清单，而不是对同一个问题给出三个不同答案。
改版期间照常营业
需求。店主指着一个他们欣赏的国际行李箱品牌网站，希望网店朝那个方向改版，而且一天都不能关店。
我们的做法。我们在草稿中工作，每改一轮就发一次预览链接。版式、摄影和文案来回调整了十几次。线上网店全程照常销售，只更新了一次，就是大家一致认可的那一版。
这家网店正在运行我们的两个应用。
平台上的每一个应用，每个网站都包含，不收月费。这家店打开了与信任相关的两个。
Product Reviews
免费
迁入的历史评价加上此后收集的全部评价，在商品卡和集合卡上显示为星级标识，另有一面完整的评价墙，带已验证购买标识。订单送达后，邀评邮件自动发出。
Google Reviews
免费
顾客对实体门店的评价，从 Google 商家资料中拉取，在首页以独立区块呈现，使用网店自己的字体和配色。商品评价证明商品好，这些评价证明店靠谱。