如果不考虑电子商务和系统，仓库里减库存的实际动作一定是发生在“卖家发货”时。后来，有了IT系统，系统的优势就在于能提前知道一些事情，从而预判，以便做出更好的管理决策。所以，系统一定是在真实的减库存发生之前，先做预留库存的动作。于是，争议的焦点在买家“拍下减库存”与买家“付款减库存”之间。
“拍下派”的主要观点：
买家既然拍下，就是有购买意向，应该把库存给他留着；否则，拍了以后，过一段时间付款却被告知缺货，买家会很恼火。“拍下派”会碰到的问题，是“拍了不买”，这个问题最极端的表现就是“恶拍”。比如竞争对手，我把你的商品所有库存全拍掉，也不用付钱，你就全下架了。
“付款派”的主要观点：
他们认为买家拍下也不一定会买，有人把拍下当收藏夹用，导致卖家无法准确预估库存，并且真正想买的人反而买不到。买家付款成功以后，才是真的确定要买了，这时才留一个库存给他。“付款派”会碰到最严重的问题，是“超卖”。因为系统在付款成功之前，都不减库存，所以总是会发生“短时间内多人都拍下，甚至钱都付了，但是系统却发现库存不够了”。这很可能带来很多投诉，让客服的工作量，甚至公关部门的工作量剧增。所以，产品经理一定要有大局观，可能因为你的一个简单设计，导致其他团队加班，甚至要多招几个人。
我们发现，表面是拍下减库存还是付款减库存的选择，背后其实是犹如“豆浆甜咸两党之争”的严肃问题，买家和卖家都是淘宝的用户，淘宝到底亲买家，还是亲卖家？而这个决定的背后，又是对市场供求关系的判断。相对而言，如果一个市场是卖方市场，那么我们就要多帮帮买家，反之亦然……而这个市场，也一定不是把整个淘宝统一判断，而是分开来看的。
好，现在我们先来看看各自问题的对策。
首先是对付“恶拍”的几个办法。系统可以增加“库存保留时间”，聚划算及很多独立B2C都这样做了。具体的做法是“拍下减库存，但是如果你在N分钟内不付款，就取消订单，库存回加”。但对于秒杀这种业务没用，因为所有的拍下都发生在几秒内，系统总不能把库存保留时间设置为几秒吧，这样的话，正常的交易行为都来不及付款。所以，限购是另一个办法。
限购，是指用各种条件来限制买家的购买件数，比如一个淘宝账号、一个IP……只能买一件。这样的话，恶拍的成本被大大提高。而对于秒杀，可以假想一下，其实卖家不在乎卖给谁了，要的是人气。此外，我们还可以通过一些安全策略来对付恶拍的问题，比如对恶意账号，通过模型判断，直接干掉，或者禁止购买。
再聊聊对付“超卖”的几个办法。
我们先分析一下超卖的本质，买家拍下后，付款的动作拆解开来是这样的：先确认订单，再到支付宝，再到网银（非必需），网银支付成功，返回信息给支付宝，支付宝再返回信息给淘宝，再减库存。所以这个过程一定是有时间差的，最后一件宝贝可能有三五个人同时确认订单，进入支付宝……为了付款成功后减库存，所以可能这三五个人同时买下这个宝贝，都付款成功。只要付款的动作是在几个不同的系统之间传信息，时间差就肯定存在，“超卖”就肯定存在，特别是对于那种超级火爆的商品。
解决的办法也有很多，最容易想到的就是在付款动作过程中，尽可能晚地验证是否有库存，比如在用户确认订单要付款的时候，再验证一下（相对拍下的时候而言），但彻底解决不可能，除非各种网银和淘宝、支付宝的系统完全打通。你也可能想到把减库存的时机提前，比如在“确认订单”的时候减。但严格意义上来说，只要付款未完成，都不能算“付款减库存”，会遭遇拍下减库存的问题。我们采用的另一种办法，就是各种提示，在商品详情页面、订单里的各个步骤页面，都告诉用户“这个商品比较火爆，如果不及时付款，不能保证有库存”云云，技术成本很低，但能减轻很多客服的压力，也是个好办法。
对上述两种问题，还有一种不那么正规的解决方案，就是设置安全库存。比如你有100件，但在系统里写80件，这样如果有小于20%左右的超卖发生，你依然有库存发货。同样，恶拍的问题，也可以用这个办法部分缓解，对于你有100件的商品，设置成120件即可。但我们认为这不是一个好办法，它会妨碍卖家做大，因为越大的卖家越需要规范化管理。试想如果连系统库存和真实的库存都是一笔糊涂账，怎么能做上规模？
对于淘宝来说，对这两种减库存各自的优劣是比较清楚的，到底应该怎么做？或者说，需要我们来决定用哪种方案？所以，最后我们干脆提供了一个可说聪明、也可说无奈的办法——把选择权交给卖家。然后，告诉卖家两个方案各自适合的应用场景。而这个决定背后，产品经理思考的是“控制”还是“放手”。淘宝作为一个平台，应该自己定规则吗？还是只提供基础设施，让更熟悉某个细分市场的卖家来决定自己的规则？这又是一个从“控制”到“放手”的故事。
