企业往来结束，不代表联系数据立刻失去用途；仍有交易处理、后续服务或帐务核对时，也不能以「先留着」当作永久理由。有效查看要把联系数据的用途、保存理由、负责人和下一次检查点写清楚，并把另有保存要求的帐务及法定业务纪录分开判断。查看结果可以是继续使用、缩减字段、限制访问、移交正式纪录流程或清理副本；每一项都需有可追踪的负责人与理由。本文提供营运盘点方法，不设置通用法定年限；具体保存要求须按文档性质及适用情况向合适专业人士核实。
先盘点哪些个资数据集？
先以数据集而不是单一客户作为盘点单位，避免一开始把全部姓名、电话或证件号码拷贝进另一张总表。从 CRM、询价表单、业务试算表、共用云端文件夹、客服信箱标签、通信软件导出档、纸本名片和脱机备份逐处找。每一集合记录系统或位置、数据种类、来源、窗口、最后一次实际使用、可访问角色、导出副本位置，以及有没有其他系统仍会读取；盘点摘要以字段名称和必要笔数为主，不另外制造含完整个资的副本。
接着画出数据流：谁先收集、何时更新、是否交给代理商或外部平台、从主系统导出的副本存在哪里、离职交接由谁接手。相同客户可能同时出现在潜在名单、已成交客户、活动报名和帐务系统，不能只检查 CRM 就宣称全数完成。指定每个集合的窗口；若来源不明或系统权限不足，标为待确认并记下查核方式，避免把「找不到」写成「不存在」。
例如，营运主管可先列出询价清单、客服信箱标签和活动名单三个集合，各请一位窗口核实用途与副本；帐务窗口另列交易文档，不混入行销名单。盘点完成的判准，是每个集合都有位置、来源、负责人、用途初判和下一步，不是当天就删掉所有旧数据。若导出档是否仍被流程引用不明，先查表单链接、共用权限或负责人，再决定留、停用或清理。即使备份内容暂时无法逐笔查看，也要记下备份系统、管理人和可安排的核实点，让未知留在清单中而不被误当成已清理。每次盘点也记下查核日期和范围，让后续接手的人知道清单反映的是哪一次查看。
每项数据仍用于何事？
用途查看要回到收集当时及目前的实际流程，逐个字段问：这项数据支持哪个工作、谁会在何时使用、下一个必要步骤是什么？例如电邮可能用于回复询价，电话可能用于已预约的回电；若一栏没有明确使用情境，就不应只写「日后可能有用」。把答案记成可核对的动词和事件，例如「回复本次报价」「处理尚未完成的交付」「依客户要求提供售后联系」，避免用「客户管理」之类无法验证的大标签。
接着区分仍在用、已完成、用途待核实三种状态。仍在用要指出责任人和下一次动作；已完成就检查是否仍有未结案服务、退款、争议、保固或帐务链接，不能以「客户很久没联系」单一条件决定删除；待核实则限制使用权限，设置负责人与回复期限。若只需辨识交易而不需继续联系，可评估缩减字段、分离联系方式或以内部代码链接，不要为了方便把所有数据留在可群发的名单。
例如，业务表中某列仍有公司名称、联系信箱、个人手机和职称，但下一步只是核对一张未完成的报价；窗口可先确认是否只需公司识别及联系信箱，把手机与其他字段标记为不再需要，并确认报价文档本身另有纪录。这只是工作流示范，不表示任何法定保存结论。查看目的也不是替数据找新的用途：若要改用于不同消息或广泛推广，先确认适用的告知、选择和内部规则，再决定是否另行取得依据。每次覆核保留「用途、字段、用户、决策、依据」五项，下一位同仁才能重做判断。更新用途时也记录日期及核准人，让后续查看能看出理由何时改变。
法定帐务文档如何区分？
联系数据与帐务或法定业务文档常在同一客户文件夹中，但文件夹相同不代表保存目的相同。先按文档本身分类：可直接联系个人的电话、电邮、职称和偏好属于联系数据；合约、报价、发票、付款凭证、对帐或交付证明则可能属于交易或帐务流程的记录，须依公司已核实的保存要求独立管理。本文不推定法定年限、起算点或适用例外，也不以一般个资查看表取代会计、税务或法律判断。
实务上创建两条清单与两个决策责任：业务窗口评估联系字段是否仍服务原定流程；帐务或合适专业窗口确认哪些文档另有保存或查核需要。若一封邮件同时含客户电话及交易指示，不要整封信一律归成可删的行销数据，也不要因为帐务文件要留，就连同所有副本和联系字段永久保留。先辨认正式纪录在哪里、谁有权核准处理，再只对多余联系副本采取适当处置。
假设同一客户的报价已结束、付款文档仍在核对，而业务名单不再需要追踪：可以把名单的处理交回业务窗口，把付款文档的保留决定交由帐务窗口，不互相代替。留存的理由要写到文档类型和流程，例如「待帐务窗口确认的付款佐证」，不要写成「所有客户数据都必须保留」。若不清楚某文档是否属正式帐务或法定纪录，先封存其处理决定、限制非必要访问，向负责的会计、税务或法律专业人士核实适用要求后再处理。这个分流动作能避免把联系数据调度直接套用到证明交易的文档，也避免把帐务保存理由扩张成整份客户文件的理由。
到期文件如何覆核？
到期日期只是启动覆核的提示，不是系统自动删除的指令。日期可由既有流程设置，例如询价结束、活动结束、项目交付或合约关系终止；查看时仍要问：用途是否已完成、下一步谁负责、是否有未结案件、文档是否属另一保存清单、客户要求或内部限制是否待处理。没有通用时限可直接套用时，记录公司采用的触发事件与核实来源，避免把固定年数写成适用所有数据的答案。
可用一张覆核清单分出处理方向：维持原用途并确认最少字段；删除不再需要的副本；限制访问并等待确认；转入帐务或其他正式文件流程。每项都填数据集、决策人、理由、操作人、覆核日期和证据位置。把「留待日后」改成具体触发条件，例如等某份交付验收完成或帐务窗口确认分类；若事件没有可预期日期，也要指定重新联系负责人的时间点。覆核后要更新清单状态与窗口，避免期限过期却无人接手。若原用户已离职，先找出承接流程的人，再请其确认是否仍需联系数据。
以下为纯假设的名单示范：30笔旧询价联系数据完成逐笔核对后，18笔仍对应未结的报价或服务事项，7笔已确认是可由主档替代的重复副本，5笔用途或交易状态仍待窗口确认；18＋7＋5＝30。窗口可把18笔留在受限的工作清单并记下下一步，7笔在确认主档完整后安排清理，5笔先限制访问并列入例外追踪。数字只演示分类方式，不是保存比例或建议期限。覆核人应抽查分类依据是否一致，特别是同一数据集内包含不同来源或文档类型时；不确定的个案退回核实，不以多数决。
清理操作如何留证？
清理前先把核准范围写成可运行清单：数据集和系统位置、字段或纪录类型、筛选条件、预计处理笔数、排除项目、运行人和覆核人。先由窗口检查清单是否混入帐务文档、未结交易或待核实例外，再由另一位有权人确认范围。不要把完整个资贴进一般工作群组作为指令；可用内部识别码或屏蔽字段，并将必要的对照信息留在受控位置。若数据可由自动化规则批量处理，先限定测试范围并核对筛选结果，再运行正式批量。
完成后记录实际操作时间、系统、条件、操作方法、成功笔数、失败或跳过笔数、例外原因、运行人、覆核人及可供查核的结果。例如，假设目标30笔而实际只移除28笔，纪录要写清楚另外2笔未处理的原因与后续负责人，不把预定数字当成已完成数字。对每种保存位置分别核实：主系统、导出档、共享文件夹、信箱、第三方平台或纸本；必要时保存作业回执、权限调整纪录或抽查结果，但避免将敏感内容再拷贝到新的纪录中。
要明白不同系统对删除、封存和备份的处理可能不同。若无法确认备份副本是否已同步清除，就把状态写成「主系统已处理，备份待依既有进程确认」，说明查核方式与下一次覆核点；不要宣称全数永久删除。可用抽样或查找结果核对清理是否符合条件，并将例外另列，而不是用「已完成」掩盖部分失败。最后把决策纪录与操作纪录相连，让未参与运行的人能还原为何处理、处理了哪一批、还有哪些待办，并保留核对人。
例外项目何时重看？
例外不是无限期保存的通行证，而是目前尚不能安全作出一般处置的具体状态。常见原因可能包括未完成交易或争议、责任人尚未确认文档分类、客户要求正在处理、系统副本仍被流程引用，或外部专业意见未回复。每个例外都要写明涉及的数据集和字段、暂停哪一项清理或使用、提出原因的人、核实负责人、下一个触发事件与重新查看日期；只有「重要」「怕以后用到」不足以成立。
例外期间采取最小必要措施：限缩可读取的人员，不把数据导入推广或新用途，不因待确认而添加字段，并注明仍在保留的是哪个副本。若是帐务或正式文档分类问题，转交帐务窗口；若是外部顾问需核实适用要求，记录询问项目及预期回复节点。收到答案后，将结论、依据、决策人和处置结果补回原例外项目，避免另开一张清单失去脉络。
例如，某笔数据因未完成付款核对而暂缓清理，例外记录可写「付款状态未确认、帐务窗口负责核对；联系字段不得用于推广；收到核对结果后再判断副本去留」。这并不表示所有联系数据都要留到付款记录结束，更不替代帐务文档自身的分类。当事件解除，立即按分流规则更新状态；如必须延长例外，补上新的理由、核准者和下一次检查点。每次覆核都重问理由、字段、责任人与所需证据，逐项点名未结例外，直到例外解除或形成有根据的正式保存安排。逾期未覆，交主管重派。
下一步，先选一份近期仍在使用的客户联系清单，填上数据集窗口、用途、未结事项与下次覆核点，再依结果分流帐务文档。了解 Chan & Chung，请由官网首页开始。