情景：实施电子商务商店

概述

"电子商务" 一词指的是一种商业模式，即卖方和买方同意通过使用网上市场买卖商品和服务。 通常，交易是通过使用计算机，平板电脑，智能手机和其他设备等电子介质完成的。 网购细分市场并不是一个新概念。 它在人气上持续加速，现在是购物的去法之一。

在这个市场部门提供的商品和服务种类是无限的。 几乎任何可以在砖头店找到的商品都可以在网上被发现，包括电子产品，书籍，杂货，时装，家具以及所有其他耗材。 服务现在也是常见的在线购物体验，购物者可以在其中预订课程，咨询或将附加服务作为电子商务交易的一部分。

电子商务的优势

卖家确实需要投入更多资源来站立服务器集群，以托管在线市场空间。 但是，与实体商店所需的投资相比，联机空间不会对托管服务器站点的位置施加任何物理约束。 此外，卖方不需要担心有足够的物理空间供购物者使用。 如果没有物理约束，如果购物者很容易发现销售者的在线市场，那么可以进入在线市场的购物者数量实际上是无限的，高度可扩展的。

考虑到运营成本，与设置实体砖瓦店相比，维护服务器硬件的成本要优化得多。 鉴于任何商店位置都无法确定成功与否，因此托管在线店面的沉没成本在可扩展性方面显然是经济且高度灵活的。

电子商务的挑战

在新的在线店面上看到大量在线购物者涌入固然是一个优势，但存在着两个商业挑战。 首先，您需要让购物者意识到购物场所存在。 其次，您需要为购物者提供无缝的产品搜索体验。 对于同质化的产品搜索，大多数在线购物者都缺乏耐心深入一个网站，寻找自己想要的产品。 如果这些购物者在搜索的前 30 秒内无法找到产品，那么他们会感到失望。 对于专业产品或品牌产品，购物者通常会更持久一些。 此购物者需要更多时间来搜索他们需要的内容，而移动到另一个网上商店站点只是为了寻找替代方法。

在线购物者降价率贯穿整个在线营销漏斗，从产品搜索开始，然后移动到产品详细信息页面，购物车页面，结帐页面和销售订单。

此图显示了电子商务转换漏斗的概念，通过快速显示在线购物者想要查看的内容，突出了购物者保留的重要性。

上图中显示的销售转化率仅为等式的一半。 电商卖家还需要解决产品能否实现。 要确保供货，卖方需要确保仅当供货网络中存在足够的库存或容量时才接受订单。 否则，订单可能无法实现，这会损害卖家的品牌声誉，侵蚀购物者的信任水平。 当卖方将其显示限制在只能在该日实现的商品，并提供有关产品交付日期的透明度时，可以进一步增强积极的购物体验。 当销售人员在购买前捕获过程中提前了解产品的来源位置和购物者选择的承运方服务时，他们可以获得更大的洞察。

交付选项首选项

在电商销售的早期阶段，大部分的购物体验都涉及到一个直接运到购物者门口的产品。 随着购物者将注意力转移到下一代电子商务体验中，他们会开发首选的实现方法。 这些首选实现方法可以包括装运，在商店中提货，卷边提货，甚至从多媒体终端提货。 其中每种实现方法都增加了销售人员的复杂性。 销售人员不仅仅是在装运产品，而是需要在使产品可供购物者提货时考虑实现成本。

积极购物体验的关键因素

培养积极购物者体验所必需的一些关键因素:

Sterling Intelligent Promising 如何加速电子商务成功

随着电子商务普及程度的提高， Sterling Intelligent Promising 的首要目标是加速卖方的电子商务转型。 这一转变在两个关键的产品方面得到了促进: 最小化配置时间和提供灵活的工具来支持电子商务实现工作流程。 Sterling Intelligent Promising 不是前端商店捕获应用程序，而是可以在何时何地销售商品的关键实现决定因素。 此信息使购物者能够自信地在商店站点上下订单，因为延期交货事件的风险已降至最低。

Sterling Intelligent Promising 可以使用以下因素提供实时实现估算:

Sterling Intelligent Promising 还可以支持端到端的电子商务订单前和订单后捕获工作流程，由以下步骤组成:

使用 Sterling Intelligent Promising 增强电子商务购物体验

存在许多实现电子商务工作流程的方法，但 Sterling Intelligent Promising 提供了有关如何使用承诺 API 来改善在线市场上购物者体验的这些准则。

产品搜索

可以根据卖方提供的产品目录的大小，以各种方式实施产品搜索。 实现此功能的最简单方法是允许购物者选择产品类别 (例如， Jeans) ，并将其重定向到产品列表页面以显示产品列表。 相比之下，较大的组织通常涉及多个销售人员或一个大型商品目录。 在此场景中，您可能需要在线市场上的复杂搜索功能，以帮助购物者缩小所显示的产品列表。

无论您采用何种方法，对于销售人员来说，最具挑战性的任务是将产品缩小到仅具有即时可用性或近期交付窗口的产品。 当购物者搜索产品并意识到前几个搜索结果中列出的每个产品都不可用时，这是一个糟糕的体验。 这种未经过滤的行为会损害整体品牌和购物体验。 因此，需要根据以下顺序条件对产品列表进行优先级划分，其中第一个列出的项是最高优先级。

产品交付日期和产品可用性日期是最重要的条件。 即使产品具有 100% 的评级，如果交货日期和供货日期与购物者预期不符，卖方也无法确保在购物者想要的日期交货。 因此，次优搜索结果需要被搜索系统过滤掉。

电子商务销售人员可以根据产品目录构建每日搜索索引，以确保仅包含可在所需时间范围内交付的可用商品。 此过滤可确保购物者始终看到他们可以立即购买的商品。 为了支持此行为，卖方可以利用 Calculate item delivery date API 预先计算最早交货日期或按日期订购的列表。 然后，在构建每日搜索索引时，卖方可以使用该信息作为过滤条件。 由于搜索索引是预先编译的，因此 Calculate item delivery date API 提供了参考时间概念，用于根据未来时间范围估算交付日期。 例如，如果计划明天实现搜索索引，那么系统需要在明天的参考时间内调用 Calculate item delivery date API ，以便可以提前构建索引。

有关 Calculate item delivery date API 的更多信息，请参阅 估算的项目交付日期。

虽然 Calculate item delivery date API 具有快速响应时间，但不建议销售人员在装入页面时查找交货日期。 Web 服务器需要执行更多可能影响购物者体验的过滤和排名逻辑。 要提供无缝的购物体验，请提前进行估算交货日期预计算，以提高整体产品搜索响应时间。

为了进一步提高可扩展性和性能，建议销售人员使用分布式商店 Web 服务器，并且每个 Web 服务器都处理其本地搜索索引，而不是使用中央服务器。 虽然 Sterling Intelligent Promising a 支持大量并发事务和大部分仅供货请求查询，但部署本地索引高速缓存可最大程度地减少估算请求数。 此外，本地索引高速缓存仅将请求限制为基本事务，例如，将商品添加到购物车，更改数量和结帐事务。

此图显示购物者搜索索引工作流程的简单构造。

搜索页面组件

这些组件用于构建搜索页面。

产品列表页面

产品列表页面根据产品搜索结果显示特色产品列表。 该页面可能在列表视图或网格视图中显示产品。 通常在整个电子商务商店站点中使用相同类型的视图。 由于购物者无法在线与产品进行交互，因此卖方可以通过在列表中显示每个商品的交货日期来补偿这种无法。 估算的交货日期有助于让购物者相信他们等待产品是可以接受的。

对于产品列表页面上的每个商品，卖方可以显示最早的估算交货日期，并显示需要订购产品以满足该交货日期的时间。 显示这些日期会使购物者产生购买产品的紧迫感。 当显示估算的交货日期时，卖方可以显示多个送货组的交货日期，例如标准送货和经济 (免费) 送货。

送货组是可供购物者使用的送货选项，提供估算的送货日期。 卖方可以配置一个或多个可作为电子商务 Web 站点上的选项提供的送货组。 通常，送货组由一个或多个满足指定天数的承运方服务组成。 卖方可以通过送货速度或按合同运费来组织承运方服务。 有关承运方服务的更多信息，请参阅 承运方服务。 有关装运组的更多信息，请参阅 装运组。

此图显示了产品列表页面的一部分，其中显示了包含订单 (按时间) 和提货选项的装运组交货日期。

卖方可以使用 Calculate item delivery date API 来获取两个样本送货组 (Standard 和 Economy Plus) 的估算送货信息。 估算的交货日期将返回每个装运组和项目的两个关键值，即最早的交货日期和需要下订单的日期。

卖方还可以显示每个项目的运输持续时间。 此替代方法包含在 "计算项目交付日期" API 中。

示例

如果两个裙子有多种尺寸，那么这些裙子也称为具有变体的商品。 每个变体都具有唯一的库存单位 (SKU) 标识。 具有变体的商品是由一个或多个模型或大小组成的不可销售的父商品。 每个子项都是具有其自己的库存的可销售单元。 父商品使卖方更容易跟踪具有相同设计或型号的 SKU 的集合。 例如，小型红色连衣裙和中型红色连衣裙各有不同的 SKU。 要正确显示送货信息，卖方需要多条信息，包括每个 SKU 的最早交货日期和最早订单日期。

在此示例中，红色连衣裙具有两种尺寸，并且卖方提供两种送货速度。 要获取显示的信息，卖方必须针对每个子 SKU 和装运组发出四个 API 请求:

然后，由卖方的 Web 服务器对结果集进行优化，以在服装尺寸之间得出最早的日期。 相反，对于没有任何变体的商品，卖方只需针对每个送货组发出一个 API 请求。

复杂性随具有差异的项数增加而增加。 为最大限度减少实时估算调用数，建议销售人员将交付信息作为 Web 索引高速缓存的一部分进行存储。 通过这种方式，可以随时获取信息，而无需针对每次页面装入重新计算信息。 大多数购物者只需要在产品列表页面上进行近似的交付估算。 购物者到达产品详细信息页面后，可以显示更准确的估算。 此策略既有利于销售人员的 Web Service 负载，也有利于购物者的体验。

有关更多信息，请参阅 Calculate estimated item delivery API。

产品详细信息页面

此图显示了产品详细信息页面的一部分，其中显示了装运组估算值和可用提货选项。

添加到购物车中

购物者将商品添加到其购物车中，以便他们以后可以结帐或购买该商品。 由于添加到购物车是未落实的购买，因此卖方通常使用业务规则来保证商品在结帐过程结束之前可用。 这些规则保证在短时间内对项目进行 "软预留" ，但超过该时间段将被视为购物车放弃，并且将释放项目预留。 其他销售人员可能会选择省略此步骤，并仅在结帐阶段之前捕获商品预留。

配送组是添加到市场目标区域或细分市场的装运节点的逻辑集合。 卖方可以根据其地理区域来引用配送组，而不是对单个发货节点进行寻址。 例如，一个 "东海岸组"。 配送组也称为网络。

对于处于未落实状态的商品，卖方可以进行网络级 (配送组) 预留以更加灵活。 在网络级别进行预留时，项目会保留一段时间，但不会显式应用于发货节点。 这样，卖方仍然可以确保商品在配送组中的至少一个发货节点中可用。 但是，建议不要使用节点级别预留，因为它会从节点上的可用库存中扣除，这会影响其他购物者的商品整体可用性级别。

销售人员可以使用 Create Reservation API进行网络级别预留。 要在网络级别保留项， Web Service 必须传递配送组标识。 要在节点上预留，卖方将传递发货节点标识。 进行预留时，建议卖方包含到期时间组件，以确保预留在指定时间段 (例如 5 分钟) 后到期。 当预留到期时，会将预留数量返回到可用性池，并且会自动取消预留。 卖方还可以设置缺省预留到期持续时间，因此 Web 服务器不需要对每个请求的持续时间进行硬编码。 可以使用 Update settings API来设置缺省预留到期持续时间。

此图显示了请求的数量大于可用库存时的警告消息示例。

车

当购物者浏览商店站点时，他们会将商品添加到购物车。 通常，添加到购物车的商品彼此相似或是相关商品，因此购物者可以进行比较，并在结帐前缩小其产品选择范围。 除产品外，购物者可能对可用数量以及他们可能收到每个购物车行的交货的时间感兴趣。 通过显示每个购物车行的估算交货日期，购物者可以轻松地比较他们想要的商品。 例如，在购物者决定在蓝色连衣裙和红色连衣裙之间使用的用例中。 如果红色连衣裙明天到达，蓝色连衣裙在两周内到达，卖家会根据他们预定的需求选择红色连衣裙。

与购物车与产品详细信息页面的一个不同之处在于，每个购物车行都包含商品的数量。 由于 Calculate item delivery date API 针对单个可用性和有效容量窗口进行了说明，因此无法为购物车行提供准确的估算。 因此， Sterling Intelligent Promising 提供 Calculate checkout assignments API 以支持此用例。 此 API 处理根据请求数量的送货速度确定最早交货日期所需的复杂计算。 卖方可能会意识到，当同一购物车行的商品数量增加时，整体交货日期可能会发生更改。 日期可能会更改，因为每个送货位置可能没有所有请求的数量或具有不同的可用日期。

建议卖方显示每个购物车行的预计交货日期。 然后，购物者可以对各个购物车行进行比较，以确定哪些商品符合其交付接受条件。 某些销售人员可能会在估算中包含所有购物车行，前提是购物者从一开始就知道自己想要的是什么。 此用例适用于具有小商品目录且主要提供旗舰商品或有限产品选择的销售人员。

对于购物车估算，卖方可以选择显示产品详细信息页面上可以显示的类似信息。 此信息可以包括送货速度和关联的最早交货日期，以及可以在附近商店提货的最早日期。

此图显示请求超过可用库存的购物车页面的示例。

要获取估算的交付信息，请使用 Calculate shipment assignments API。 Calculate shipment assignments API 提供最早的交付估算，并计算购物车行项的完整请求数量。 API 还会返回有关网络无法实现的任何延期交货或数量的信息。 因此，卖方需要主动验证数量是否完整，并向购物者报告任何延期交货金额。 此通信可确保购物者了解在进入订单捕获阶段之前无法实现的任何数量。

还可以使用 Calculate item delivery date API 和 Get node availability by dates API的组合来得出此估算值。 估算的交货日期还提供满足所报告的最早交货日期的供货节点。 通过使用此信息，卖方可以使用 Get node availability by dates API 来识别目标发货节点上的可用数量。 根据商品的库存阈值，卖方可以显示一条短消息，指示该商品只有有限的可用性来敦促买方更快地购买该商品。

付款

在购物者完成其购物车中的商品列表后，可以将购物车转发到结帐阶段。 结帐时，购物者将对购物车进行最终复审，该复审由多个购物车行和商品数量组成。 由于该购物者可能致力于购买商品，因此卖方需要提供整个购物车的送货估算。 此交货估算可确保购物者了解商品的总体交货日期。

购物车页面与结帐页面之间的区别在于，购物车页面包含为获取实现估算而一起考虑的所有购物车行。 如果同时考虑多个购物车行和多个数量，那么在可用性较低时，该购物车可能需要拆分装运。

在结帐页面上，购物者必须能够选择所需的送货速度，送货方法和供货首选项。 当卖家通过为购物车商品和数量提供准确的交付估算，让购物者获得承诺感时，购物体验得到进一步提升。 实现首选项可以由卖方预定义，也可以作为购物者的选项提供。 "实现" 首选项指示购物者接收已交付商品的方式，例如，所有商品一起交付或在可用时立即交付。 最早交付意味着一旦项目可用，装运就会离开发货节点。 一起交货是指调度所有购物车商品在同一尽可能早的交货日期到达。

基于成本的承诺进一步提升了购物体验。 现在，卖方不仅可以提供准确的送货预估，还能以最低的总体服务成本完成订单。 购物者可以选择 应用成本优化作为履行选项。 当购物者选择该选项时，卖家会通过计算每次购买的发货分配来承诺购物车中商品的发货，从而最大限度地降低总体服务成本。 当购物者选择应用成本优化选项时，使用成本计算结账任务 API 在推导购物车的交付日期时会考虑最低服务成本。 有关基于成本的承诺的更多信息，请参阅情景：计算预购装运分配并最小化服务成本。

Calculate shipment assignments API 在得出购物车的最早交付日期时，会考虑到所有这些因素。

与购物车页面类似，卖方必须确保在结帐周期的早期捕获 Calculate shipment assignments API 报告的任何延期交货数量，以便购物者了解缺货情况。 此通信可最大限度减少负面实现体验。

此图显示了一个结帐页面，该页面显示了一个装运组，该装运组根据装运与提货之间的交货方法，具有交货日期和行细目。

Calculate shipment assignments API 返回以下信息，以支持购物者所需的关键信息。

购物车或购物车行中的项目很可能被分成多个货件，因此 Calculate shipment assignments API 响应包括最早和最晚交货日期。 因此，卖方可以同时使用这两个值或仅使用最早的交货日期。 在后一种方案中，交货细目显示在装运详细信息页面上。

计划支持提货选项的卖方需要将购物车分为两个不同的请求，一个用于装运交货方法，另一个用于提货交货方法。 Calculate shipment assignments API 不支持在同一请求中混合取货和发货。 提货的性质与装运不同，因为它不涉及最后一英里交货。 此外，大多数销售人员会根据购物者的首选商店位置来发布可用日期。 例如，如果购物者的购物车包含一条装运行和一条提货行，那么卖方必须在装运和提货之间显式拆分购物车。 通过这种方式，可以对每种交付方法发出隔离请求。

在此示例中，将购物车拆分为提货和装运。

卖方为 SHIP1 购物车线路运行 Calculate shipment assignments API 。 对于 PICK1 购物车行，卖方必须请求 Get node availability by date API 以检索所选运输节点的可用日期，并使用 Create Reservation API 为定义的商店预订库存。 在这一阶段，卖方可能希望根据 Calculate shipment assignments API 提供的指定船舶节点进行 "硬预订"。

当用户提供付款并完成结帐交易时，卖方可以使用结帐流程中的 Order Management System 或记录需求来创建订单。 在此示例中，将在检出过程中创建两个需求，每个购物车行 (SHIP1 和 PICK1) 一个需求。 对于 PICK1 方案，卖方必须使用购物者的提货日期作为需求请求的发货日期。 有关更多信息，请参阅 复审装运详细信息。

复审装运详细信息

当购物者进入结帐流程的最后阶段 (例如付款捕获) 时，建议卖方显示购物车行的装运分手。 此装运拆分可帮助购物者了解要交付的包裹数量。 根据其实现首选项，可能存在多个装运。

如果一个购物车有多个购物车行，每个都有不同的数量，那么购物者可能会收到来自卖方的多个包裹，尤其是当它们源自不同的发货节点时。 装运拆分的一些示例场景如下所示。

• 一个购物车行由单个装运中的单个装运节点实现。
• 一个具有多个数量的购物车行可以在不同装运节点的不同包裹中装运。
• 多个购物车行可以共享一个装运。
• 多个购物车行可以共享多个装运以满足完整的请求数量。 例如， Line1 和 Line2 可以根据可用性调度共享 Shipment1 和 Shipment2 。

在此示例中，发货节点具有有限的可用性，因此 Sterling Intelligent Promising 通过根据最早的交货实现首选项将购物车拆分为两个装运来优化可用性。 每个装运指示分配给装运的数量。

在购物者确认订单之前，卖方需要创建一个简短的库存预留，直到结帐完成为止，因此库存不会被另一个过程消耗。 上述图像还指示当前检出屏幕到期之前的时间量。 到期后，卖方需要通过创建新的预留来更新预留。 如果任何请求项存在缺货情况，那么将通知购物者该数量不再可用。

订单确认后，卖方有两种选择来捕获订单:

• 使用 Calculate shipment assignments API 提供的分配，包括承诺日期、运输节点和承运商服务。
• 使用 Order Management System 并记下已落实的交货日期，以便在向购物者显示这些日期时显示这些日期。

要使用 Calculate shipment assignments API 提供的分配，卖方必须执行以下所有步骤：

1. 使用 Adjust Demand API 为指定数量和装运节点分配创建库存需求。
2. 使用此 API 来使用预留，并传递预留标识。
3. 通过在分配的发货节点上使用承运方服务来处理实现请求。 卖方可以使用外部集成解决方案或 Order Management System 来管理发货节点任务和操作。

无论使用何种方法，由于交货日期已呈现给购物者，因此此日期将成为承诺日期。 卖方必须确保不违反此日期以避免客户不满。 虽然此承诺日期用作交付基准，但随着更多需求到达系统中，卖方也可以使用此数据来执行另一层实现优化。 通过这种方式，卖方可以在所有节点之间实现最佳装运平衡。 即使将购物车行分配给发货节点，如果维护了交货日期，卖方也可以更改发货节点和承运方服务分配的成本更低的选项。

承诺服务的先决条件核对表

为确保 Sterling Intelligent Promising 正常工作， IBM 建议您验证租户帐户是否存在以下所有配置数据。