Balancing Capability and Product Compromise in Light Customization

Context#

We are currently developing the Light Customization project on Alibaba.com. Within the team, there are two major schools of thought:

Full transactionalization. This view argues that we should require sellers to upload complete product and customization data onto Alibaba.com, building a more advanced and structured Editor. The goal is to enable users to place orders or complete customizations without any communication.
Lightweight entry. This perspective suggests the platform should focus only on being an entry point, providing matching and filtering tools while leaving detailed customization and communication to sellers themselves.

This document discusses how we should balance between capability compromise (platform and tool limitations) and product compromise (experience and flow trade-offs) during the development of Light Customization.

Follow-up Product Strategy#

The guiding principle for our product direction and trade-offs should be “full transactionalization.”

Before the order is placed, we should minimize communication latency. Ideally, users can complete customization and transaction instantly, with little or no interaction.

Seller Incentives vs. Seller Boundaries#

When making decisions that involve seller input (e.g., defining customization attributes per product or via templates), we should not prematurely assume that sellers “won’t cooperate.”

Seller incentives should be explored through traffic control mechanisms, not rigid assumptions.
The key question to validate is: At what point does a seller requirement become too cumbersome to scale?

Building Seller Capabilities vs. Historical Burdens#

Since full transactionalization has become a firm direction, seller capability-building and tool design should be defined under the premise of transactional efficiency.

In cases like “new customization fields are incompatible with previous ones,” we should design for the post-transactional future, rather than compromise for backward compatibility.

Product Scope Compromise vs. User Flow Compromise#

As a full-category trading platform, Alibaba.com cannot instantly deploy every capability or achieve every long-term goal. When current platform capabilities cannot support the ideal user journey, we should:

Redefine the covered product or service scope, rather than compromise the long-term vision.
For example, if our Editor cannot yet support complete customization expression and users must still inquire, we should focus on categories or sellers capable of minimizing communication, rather than abandon the pursuit of “communication-free light customization.”

User Behavior Migration to the Platform Should Be the Top Priority#

Payment represents the strongest form of user intent and is the anchor for improving conversion. When balancing user experience against data collection, we should lean toward actively capturing user behavior on the platform, as long as it does not harm user experience.

After a user expresses customization intent, we must offer payment capabilities and use payment data to identify bottlenecks in the current flow, not give up on guiding users toward completing payment.

Implications for the Light Customization Project#

Clarify stage goals and define “Light Customization.”
- In the current stage, the goal is to enable structured communication and reduce communication latency.
- The long-term goal is “zero communication, fully transactional customization.”
Provide posting capabilities based on future seller efficiency.
- Build batch template posting instead of per-product modification.
Clearly define the scope and target industries for Light Customization.
- Provide certainty in customization capability, logistics, and pricing.
- Do not abandon efforts to structure and reduce uncertainty; we should not hand information certainty entirely over to sellers.
Increase certainty and confidence on the product detail page.
- Help users reduce the latency between having a customization need and passing that need to the seller.
Enable payment and expand payment-ready scenarios.
- Provide the ability to pay directly, fix bad cases within the current flow, and continue expanding the set of light customization scenarios where payment can be completed immediately.

背景#

我们目前正在 Alibaba.com 上推进轻定制项目。团队内部存在两种主要观点：

**全交易化。**这一派主张，我们应当要求卖家把完整的商品与定制数据上传到 Alibaba.com，并构建一个更先进、更结构化的 Editor。目标是让用户无需任何沟通就能下单或完成定制。
**轻入口。**这一派认为，平台只需专注做好入口，提供匹配和筛选工具，把具体的定制与沟通留给卖家自己完成。

本文讨论在轻定制的建设过程中，我们应如何在能力妥协（平台与工具的局限）和产品妥协（体验与流程的取舍）之间取得平衡。

后续产品策略#

我们产品方向和取舍的指导原则应当是**「全交易化」**。

在下单之前，我们应尽可能压缩沟通时延。理想情况下，用户只需极少的交互甚至零交互，就能即时完成定制和交易。

卖家激励 vs. 卖家边界#

在做涉及卖家投入的决策时（例如按商品或按模板定义定制属性），我们不应过早假设卖家「不会配合」。

卖家激励应当通过流量调控机制去探索，而不是靠僵化的假设。
需要验证的关键问题是：对卖家的要求繁琐到什么程度，就无法规模化了？

卖家能力建设 vs. 历史包袱#

既然全交易化已经成为明确的方向，卖家能力建设和工具设计就应当在交易效率的前提下来定义。

在「新定制字段与旧字段不兼容」这类情况下，我们应当面向交易化之后的未来去设计，而不是为了向后兼容而妥协。

产品范围妥协 vs. 用户流程妥协#

作为全类目的交易平台，Alibaba.com 不可能一步到位地铺齐所有能力，也不可能立刻实现所有长期目标。当平台现有能力无法支撑理想的用户旅程时，我们应当：

重新定义所覆盖的商品或服务范围，而不是在长期愿景上妥协。
例如，如果我们的 Editor 暂时还无法支撑完整的定制表达，用户仍然必须询盘，那么我们应当聚焦于有能力把沟通压到最少的类目或卖家，而不是放弃对「免沟通轻定制」的追求。

用户行为向平台迁移应是第一优先级#

支付代表了最强的用户意图，也是提升转化的锚点。在用户体验与数据收集之间做权衡时，只要不损害用户体验，我们就应当倾向于主动把用户行为沉淀在平台上。

在用户表达出定制意图之后，我们必须提供支付能力，并用支付数据去定位当前流程中的瓶颈，而不是放弃引导用户走完支付。

对轻定制项目的启示#

明确阶段目标，定义「轻定制」。
- 现阶段的目标是实现结构化沟通，降低沟通时延。
- 长期目标是*「零沟通、全交易化的定制」*。
基于卖家未来的效率来提供发品能力。
- 建设批量模板发品，而不是逐个商品修改。
清晰界定轻定制的范围和目标行业。
- 在定制能力、物流和价格上提供确定性。
- 不要放弃结构化和降低不确定性的努力；我们不应把信息的确定性完全交给卖家。
提升商品详情页的确定性与信心。
- 帮助用户缩短从产生定制需求到把需求传递给卖家之间的时延。
打通支付，扩大可支付场景。
- 提供直接支付的能力，修复当前流程中的 bad case，并持续扩大能够即时完成支付的轻定制场景范围。