编辑导读：对于B端产品来说，批量导入是一个常见的功能。尤其是在历史数据很多的情况下，批量导入能减少很多工作量。但是，批量导入看似简单，实则是个大坑。本文作者基于自身工作经历，梳理了批量导入应该避开的四个大坑，希望对你有帮助。

看了好多文章，都在讲如何进行批量导入，不过实在是最近被批量导入坑得太惨了，所以这篇文章是劝退的，没想好这几个问题点，建议批量导入的功能先缓缓，您先冷静冷静再决定要不要做。

诚然，对于B端产品来说，好像很多地方都会用到批量导入。尤其是在系统冷启动的时候，商家会有一堆理由与说辞让你觉得，好像确实有做批量导入的必要，如果不做批量导入对商家很不友好，大批量的历史数据不能尽快录入系统的话，那商家可能就会说要考虑考虑要不要用你这个系统了。

这时候，为了让甲方爸爸们买单，我们就妥协了。然而，你以为做了这个功能就结束了，天真，之后你才会发现，这只是个开始。

以CRM系统为例，历史客资的导入基本上是避开不了的议题。或者是仓库系统，历史物料的快速录入也是个不得不考虑的问题。

但不管是哪种，其实做批量导入的大部分场景都是为了解决商家冷启动的问题，但是由于系统在不断迭代，批量导入的逻辑也需要一直跟随修改，基本需要和线上保持完全一致的逻辑，毕竟这是一个可能三五个迭代不会有人用，但是一旦用起来体验糟糕或者逻辑跑不通那就是死罪了。

所以整理了以下几个问题点，各位看官好好考虑。

灵魂拷问一：开发资源是否足够？

其实这是个过于实在的问题了。就问一句，各位产品有没有经历过由于开发资源不够所以需求被延期的情况。

有一说一，迄今为止我碰到的产品就没有一个说每次功能都是开发说能做但是他自己给砍掉了的。

开发资源在绝大多数公司都是紧张的，所以产品核心能力有一个是排需求优先级，但是批量导入是一个你一旦做了那之后没有办法考虑优先级，必须每个版本跟着你迭代逻辑同步修改的功能。这就导致，一旦有涉及到字段调整或者是相关逻辑调整的情况，你必须做同步，这点没商量，就必须占用一定的开发资源。

如果只是版本微调还好，基本也不会修改太多。但是一旦涉及比较大的功能调整，本身开发任务就是很重的，这时候你还需要考虑批量导入的每个字段逻辑以及导入逻辑是否有关联影响，需要做对应的调整。

当然，有人会说，这些应该是默认跟着系统逻辑走的，恕我直言，会用批量导入的系统部分逻辑还是比较复杂的，往往做不到完全自适应。除非是最基础的字段导入，涉及逻辑很少，就只是展示，不关联导入后数据状态变更的一些问题，如果这样，你可以到下一步了。

灵魂拷问二：你准备好因为他加很多特殊逻辑了吗？

这个问题也是最近几个月折磨了我好久的问题。

第一次做批量导入就是做CRM系统里的历史客资导入，本以为这个需求很简单，无非就是客资字段的导入，如果格式不匹配报错就好了，第一版上线后，csm小伙伴跑来跟我说，客资导入成功率不足5%，我？？（黑人问号脸），我都给示例数据了还看不懂吗？我都按照各位产品大佬的意见来了呀，注释也告诉他们什么字段有什么填写要求了，每一步该干嘛也引导了，为什么还失败率那么高。

跑去看数据，原来是本身平台有填写限制的一些字段直接被商家无视了，比如某个字段，因为涉及到后续内部员工的绩效问题，所以填写的要求是需要商家填入在当前企业的员工。但是，商家给了一份攒了十年的文件来导入。

十年啊！兄弟们，都够从我不认识你，你不属于我到我们是朋友了。这里面有好多老板都记不起名字的曾经的员工，他表示肯定要导入，而且数据不能乱改啊。

虽然我一度质疑过十年前的数据拿来有什么用，但是一旦被甲方爸爸说出那句“如果你们不能实现这个功能我就要退款。”这种一听就想甩手走人的话来就只能妥协了（当然，因为我们平台刚做不是很久，所以很珍惜每一位甲方爸爸，平台大一点的话这种要求应该可以拒绝，不过这只是一个示例）。

甲方爸爸都说要了，想办法加呗，那就正常录入的时候不能自己填，但是批量导入的时候可以，先校验这个人是不是在企业里，如果有正常导入，如果没有，则作为文本字段特殊导入，导入后对应位置需要可以展示，一旦修改则只能修改为当前企业下的员工。

还有我们要求部分字段只能填固定的几个选项，商家说我就是有另外一个，为了提高导入成功率，加呗，如果识别到没有，直接在设置里添加，哪怕原来这个字段编辑有权限控制，在批量导入这儿也开放了，不做鉴权……

诸如此类，其实会有很多。大家都应该知道，平台越复杂，特殊逻辑应该要越少，因为特殊逻辑往往治标不治本，而且等于在平台上埋地雷，一旦哪天不小心碰到，就是炸。但是批量导入就是为了提升效率，所以往往会做很多兼容，相当于是在挖坑了。

灵魂拷问三：你真的能够做到不遗漏逻辑吗？

有些时候吧，甚至觉得开发资源嘛，挤挤总是有的；特殊逻辑嘛，加就加吧，能导入就行。

但是，你每一个版本迭代的内容真的你都能记得往批量导入同步吗？你这边可能只是顺手改了个字段的格式，没准儿只是从多行文本变成了单行文本，填入字数限制从100变成了20，或者是限制不能填入某个敏感词。如果你漏了批量投入，可能导入就报错，并且可能是之前你没有考虑到的错误原因，商家导入，报错，错误原因，未知，再导入，再报错……“

什么垃圾功能！”我都能想象到商家的气愤，并且说了，批量导入很多就是解决冷启动的问题，所以那时候商家迁移成本很低。因为并没有太多数据在你平台里。所以，出现这样的问题可能让商家对平台的初始印象就不好，后续对接真的会耗费更多精力。所以，你必须保证随时批量导入是可用状态，因为随时可能有新签商家。

所以，批量导入真的是耗费资源的一件事，不止开发资源，还有你的精力。

灵魂拷问四：你认为的简单真的商家也觉得简单？

开发资源，有！特殊逻辑，加！迭代内容，跟着走！

到现在了，你觉得商家总该没有问题了吧。但是，商家真的会看你那一堆文字注释，按照要求修改每个字段？商家真的能理解，为什么只是导入一批数据而已，设置里却多了那么多可能是几年前用的一些选项？商家真的知道每个字段匹配上之后对应的数据状态会变成什么样？

在字段没办法完全匹配的情况下，商家真的能理解他源文件里的一些字段我们真的无能为力了，就是导入不了，因为我们没有对应的位置或者功能去使用到这个字段？部分情况下是不会的，商家不会看你的注释，除非是一些常规搜集的文件，可能按照你的要求来填写，但是如果是纯历史数据，肯定是大量的情况下商家才会用批量导入，你让他挨个核对完再导入他不会认为这是个提效的方法。

如果有字段真的导入不了，他会问你，这样我的数据是不是就有丢失啊……

商家有时候是真的不聪明，有时候是聪明但是懒，懒到他觉得这东西丢给你就是能完全兼容处理，不能处理就是你的问题。如果操作失败率高，也是你的问题。

你真的准备好接受这些问题的洗礼了吗？

以上，差不多就是我认为批量导入四个很关键的问题了。

当然，不要太悲观，做好了真的感觉还是很开心的，我从最开始导入成功率不足5%做到现在基本都能成功也是很不容易的，看着导入成功10000条这种感觉还是很棒的，瞬间觉得“哇自己真的给商家省了好多事情诶。”感觉贼6，还是比较有成就感，虽然这个成就感来得有些艰难。

虽然如此，其实建议大家能不做批量导入的地方最好还是不要做，太多坑了，如果是一个有行业通用点的库，其实提供给商家所有可选的可能比让他批量导入更合适，最近准备试验这个方案！看看能不能脱离批量导入的坑。

本文由@一白 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议