三个真实的案例
案例1
最近面试的将近20位产品经理里面，我都会问一道问题：请您为我公司的订单系统设计一套订单号的生成规则。应聘者里面有一两年的职场新人，也有工作将近十年的老鸟，当然也不乏运营或者开发转岗到产品的，有些甚至还做过订单与支付系统，但几乎所有的面试者都没能说的很全面。
案例2
去年的某个时间，朋友A所在的公司订单系统改造升级，开发在没有知会运营和市场的前提下将订单号长度由14位改到了19位
（事后得知产品人员当时也不知情）
，而公司现有的用户至少70%都在使用货到付款的刷卡支付，即每次刷卡前都需要输入订单号，然后你懂的，整个市场炸锅了，开发于是紧急发版，又把订单号的长度改回了14位。
案例3
再说说6年前的一个经历。当时朋友
（简称为C吧）
在一家游戏公司做PHP网站开发，C和其他几位开发完成了整个游戏的在线支付系统，并且联调成功了。系统运行后发现了一个情况，某游戏玩家充值了5万块钱，当时运营人员想查下是什么时间充值的，但后台系统里面没有记录充值时间，无奈之下只能去数据库查到了时间戳，然后根据时间戳反查出来了充值时间。
近20位产品经理给出的答案
再回到上述案例1里面的问题，其实题干里面还隐含了一个关节信息，即该系统是为我公司设计的，而不是其它公司设计的
（我公司现在做酒饮类B2B，未来可能会做B2C或其它）
。但回答者几乎都忽略了这一点。
这些应聘者的原话记不清了，但主要就以下这些思路及其组合，括号里面是我的点评
（吐槽）
：
那么问题来了，一个好用又好看的订单号，应该具备哪些规则和依据呢？
在此，我说点自己的理解。
订单号怎样生成才好用
回到问题的本质，订单号是拿来干嘛用的？谁会关注订单号？简而言之，订单号是用来标记/查询订单
（查询的时候可能更关注于物流单号）
用的，一般会在订单有支付/售后/异常问题的时候会用到，也就是说订单号主要是拿给客服/运营/开发部门用的。
那么客服在处理一笔订单的时候，什么格式的订单号才会好用呢？首先订单号中最好避免数字以外的其它字符类型，订单号尽量短，订单号尽量能结合当前的业务情况有特定的标识，如渠道编号
（包括平台、下单渠道、支付方式）
、业务类型和时间信息等。为了便于理解，下面还是举例说明：
平台：
这个以游戏举例，目前很多手游除了官方服务器外，还有一些是和其它平台比如小米、腾讯联合运营的，但是充值有可能是用的同一套，这种情况就很有必要在订单号中标记平台；
下单渠道：
目前很多电商产品都涵盖多平台，包括WEB、APP
（Pad）
和门店
（比如1919和苏宁等）
，比如通过订单号发现近期反映的问题都来自于APP，则理论上可以推断出APP渠道有问题。
支付渠道：
如上文案例2所说，不同支付方式会遇到的问题也是不一样的，比如货到付款的刷卡支付仅POS机错误代码就几十项，而支付宝基本不会有这些。比如APP不支持公司转账，如果某订单有了代表公司转账的标识位，不用后台查询即可知道这是一笔来自WEB的订单等等。同样，用户反映该订单号无法使用红包，客服人员也可以通过支付渠道标识位来识别出是因为红包功能在APP上没有上线造成的；
业务类型：
以前在游戏行业的时候，我们一般会把订单号的某一位用来标识游戏名称，比如梦幻西游、魔兽世界和阴阳师分别用1、2、3来标识。这样遇到相关问题时，不用后台查询即可快速识别出问题并把其转给相关游戏团队。同理的还有零售和团购，自营订单和入驻商家订单，2B业务订单和2C业务订单；
时间信息：
有时间信息会让客服/运营人员看到订单时不需要经过后台查询即可知道该订单时哪天产生的，可以简单的判断问题的紧急程度。同时在B2B业务中，我们也可以根据该时间推算出大致的清分结算时间等等。所以我的建议是如果业务类型决定了客服类问题比较多，则有必要在订单号里面加上这个信息。但时间的完整格式2016年11月11日 11点22分33秒这样的显示出来就是20161111112233，年和时分秒信息略显多余，只记录月和日即可；
综上，我给出的好用的订单规则是这样的：
下单渠道1位+支付渠道1位+业务类型1位+时间信息4位+下单时间的Unix时间戳后8位
（或是这8位数字加上随机码和随机规则进行随机后的数字）
+用户user id后4位。
然后你会说，这样算下来就订单号就19位了啊？一点都不精简啊，不好记不好念不好输的。但我说的上面的这些业务标记，你不一定要全部加上啊。
