一套业务台账该有几栏 每栏各自回答哪个问题
一套业务台账该有几栏，取决于它需要回答几个问题，不取决于手里的模板印了几行。按这个思路倒推，常用的是七栏 —— 来源、时点、相对方与确认、经手人、过程变更、费用与凭据、审批与结果，每一栏对应一个必须答得出来的问号。多出来的栏如果答不上任何问题，它只会让填的人多花时间，也让真正要紧的那几栏被拿来敷衍。
这个说法听起来偏理论，其实很好验证。把手上那本台账从头翻一遍，随便挑三行，逐栏问自己一句「这一栏是拿来回答什么问题的」。答得出来的栏留着，答不上来的栏，通常是从别人那儿照抄过来、一直没人删的。下面按八个在栏位设计上反复被追问的问题分开说，每一问先给一句结论，再讲清楚这一栏到底在回答什么、缺了它会怎样。
一套业务台账到底该有几栏？
七栏。这七栏不是按行业模板排下来的，是按七个必须答得出来的问题倒推出来的 —— 先有那几个问号，才有一栏一栏的位置。
倒推的顺序是这样：先列出这笔业务日后可能被问到的那些问号，再给每个问号配一栏。问题是因，栏是果 —— 顺序反过来做，就会做出一本看起来很专业、问起来什么都答不上的账。
七个问号依次是：这笔业务是从哪条路子进来的；它在哪个时点发生的；跟谁办的、对方本人确认过什么；这个环节是谁在管；中间条件有没有变、因为什么变；钱是按什么名目收的、有没有凭据；到头是谁点头让它过的。七个问号，不多不少，正好七栏。
之所以要强调「倒推」，是因为大多数台账是正着做出来的 —— 先找一个现成的模板，照着它的列去填。正着做的结果，是栏和问题对不上：填得很满的栏，事后没人问；真被追问的那一点，反倒没地方写。
鲲极CRM系统在设计这部分时采用的是同一套倒推法：每一栏先写清它对应哪一问，写不出对应关系的栏直接不进表。这个做法有个副作用值得说 —— 栏会变少，但填的人反而更愿意填，因为他知道每一格都是有用的。
栏数越多越好吗？
不是。栏和问号是一对一的关系，一栏如果答不上任何一个会被问到的问题，它就是纯负担。负担多了，填的人就会整套敷衍。
这条判断很反直觉，因为多数人挑台账时的心理是「宁可多记一点，免得将来缺」。但多记不是没有代价的：代价是注意力被摊薄。一个人一天填三十栏，和一天填七栏，前者必然有几栏是随手点过去的，而随手点过去的那几栏，往往就是真出事时要用的那几栏。
更实际的问题是，栏一多，标准就散了。每个填的人对「这一栏填到多细」的理解不一样，同一种情况在账上会出现好几种写法，事后要归拢就得先做一次对齐，而对齐这件事本身就说明这本账当时没定清楚。
判断一栏该不该留，问一句话就够：「这一栏空着，会不会有人在某一天来问我要。」答会，留着；答不会，删掉。这条判断不看这一栏好不好填，只看有没有人真的会问。
来源那一栏，为什么要写到「谁介绍的」这一层？
因为来源这一栏回答的不是「从哪来」，是「这笔业务是不是正规路子进来的」。写到具体的人，这一问才答得出来；只写「线上」或「转介绍」，等于这一栏空着。
「线上」这两个字看着像个答案，其实是把一个来源类别当成了来源。它说明的是渠道形态，说明不了这笔业务由谁带来、那个人跟机构是什么关系。被问到这一层的时候，只能凭记忆补，而记忆补出来的东西通常经不起第二遍追问。
填到位的写法，一般包含三样：介绍或对接的具体是谁、这个人跟机构是什么关系、头一回接触是什么时候。三样齐了，这一栏才算回答了「正规路子」这一问；少一样，它就退回成一个标签。
这里还有一处容易含糊的地方：某些业务进来的时候绕了几道。绕了几道并不可怕，可怕的是账上把它写成了直达 —— 一个绕过的环节被抹平，事后要解释就得把整条链重新捋一遍，而那时能作证的人未必还在。按实际情况记，哪怕看上去麻烦一点。
只记结果不记过程，缺的是哪一栏？
缺的是过程变更这一栏。有它，条件为什么变、谁同意的，都落在纸上；没有它，条件一变，前面所有记录的可信度都会跟着下降。
业务这件事很少一条直线走完。中途改条件几乎是常态，而恰恰是「改」的那一下，是需要被记住的。因为事后回头看，看到的永远是改完之后的那个版本，改之前的那个版本只在当事人的记忆里。
这一栏要回答的其实是三个问题：原来是什么、什么时候因为什么改成了什么、这次改动是谁同意的。三个问题写在一处，这一栏就成立了；只写「已调整」三个字，等于把它变成了一个备注。
还有一种更隐蔽的情况：条件没变，但中间停过一段。停了多久、为什么停、谁决定继续的。这类空白在账面上看不出来，因为起止两头都在，只有中间那段是空的。而核查的人恰恰容易盯住这一段 —— 一头一尾都对得上、中间没有记录的业务，容易被单独拎出来问的一种。
费用那一栏，记个总额够不够？
不够。总额答不了「这笔钱按什么名目收的」和「收的时候有没有凭据」这两个问题。至少要有名目、金额、收取时点、对应凭据四样。
「一共收了多少」是一个汇总数，汇总数的问题是它把所有细节压成了一个点。一旦有人问「这里面哪几笔是同一类的」，这个点就拆不开了。
四样当中，名目容易被省掉。因为对机构自己来说，收的是什么钱心里清楚，不需要写。但账不是写给自己看的，写在账上的名目，是给不了解这笔业务的人看的 —— 他只能看到纸上写了什么。
凭据这一样要单独说。凭据不只是有没有开票，还包括这一笔对应的是哪一次沟通、哪一个版本的条件。金额对得上、凭据对不上，这种组合在核查里比金额对不上更麻烦，因为它意味着这笔钱和这笔业务之间的关联没有被固定下来。
审批那一栏，写「同意」两个字行不行？
不行。审批这一栏要能回答「是谁、在什么条件下、点了哪一步」，三个要素缺一个，它就退回成一个人的口头表态，而口头表态在事后不算东西。
审批栏的价值不在「有没有人同意」，在「这一次同意是基于什么」上。同一句「同意」，在条件正常时和在条件被放宽之后的含义完全不同，而账面上如果不写上下文，这两件事就变成了一模一样的两行字。
所以「在什么条件下」这一项要写具体：是在原条件上过的，还是在某个条件被调整之后过的。这一句写清楚，审批栏才有分量；写不清，它就只是个签字位。
「点了哪一步」这一项常被当成多余，其实它解决的是顺序问题。有些业务是先放行后补手续，有些是手续齐了才放行，账面上这两种看起来都有签字。只有把步骤写出来，才能分得清是哪一种 —— 而这两种在事后被追问时的性质，完全不一样。
这七栏谁来填、填到什么程度算合格？
经手的人自己填，不是事后专人补录。合格的标准是：拿一条记录给没参与过这笔业务的人看，他能不能把这一笔从头到尾复述一遍。
「专人补录」这种安排，问题出在时间差上。补录的人手上只有别人转述的结论，没有当时的过程，他能填进去的必然是结果，填不出细节。而七栏里有一半是细节，专人补录这件事，从安排上就把那一半弄丢了。
「经手的人自己填」听着要求高，实际反而省事，因为填的人只需要顺手记下他本来就知道的事。要解决的不是意愿问题，是方便问题 —— 让他能在当时那一分钟内记完，而不是攒到晚上再回忆。
鲲极CRM系统在这一点上的做法是：同一栏的填写入口只开给经手的人，审批栏才开给有审批权的人，两栏不共用一个账号。这样安排不是为了管人，是为了让「谁填的」和「谁批的」在两栏里各自成立 —— 两件事混在同一个账号里，事后连自己都分不清。
合格线定在「外人看得懂」这一档，是有原因的。如果标准定成「自己看得懂」，每个填的人都会认为自己达标，而这本账在交给别人的那一刻就会失效。换一个人看不懂的账，等于只有一个人能解释的账。
换了系统，这七栏怎么搬过去？
按栏对栏搬，不按界面搬。先确认新系统里每一栏都有地方落，再确认落进去的内容能整批导出，两步都过了才动数据。
「按界面搬」是常见做法，也容易丢东西。界面是给人看的排列方式，栏是数据存放的位置，两者并不一一对应 —— 旧系统里一栏的内容，到了新系统可能被拆成两处，也可能被合并成一处的备注。合并和拆开的过程，就是信息变形的地方。
所以搬迁之前要先做一张对应关系：七栏在新系统里各自落在哪、有没有哪一栏找不到对应位置。找不到对应的那一栏，是这次搬迁真正的风险点，它通常不会报错，只是安静地没了。
第二步是导出。搬完之后，按栏导一遍出来看，看的是每一栏的内容是不是都在、格式是不是还能读。能导出是一个硬要求，理由是它决定了这本账在将来还能不能带走 —— 搬得进去、拿不出来，等于把账本换了个人保管。
这两步都做完，才算这次搬迁结束。顺序不能反：先搬数据再想栏位对应，等于搬完再发现少了一栏，而那时旧的已经停了。
回头看这七栏，它们的设计逻辑其实只有一句：每一栏都要能独立答出一问，七栏合起来能答完一笔业务的全过程。做台账这件事，难的不是记，是在记之前想清楚每一栏为什么存在；想清楚了，记的量反而会下来，因为该记的都在，不该记的都不在。鲲极（鲲鹏的鲲）把这一套当成产品的地基来做 —— 栏位先定，功能后加，这个顺序不反过来。
以上为业务台账栏位设计的整理，供同行拿去对照自己手上的那一本。
