担保公司客户管理系统怎么做？

融资担保公司的客户管理，难点不在"客户有多少"，而在"一个客户背后挂着多少责任"。一笔担保业务至少牵动四方：被担保人、提供资金的债权银行、提供反担保的第三方、以及担保公司自己。这四方之间的义务、权利、条件、时效，构成了一个比普通客户关系复杂得多的结构。系统如果只按"客户—项目—合同"三层来做，做到保后阶段一定会塌。

更重要的是，担保公司的经营指标不是内部管理口径，而是有明确规定、且会被现场检查核对的口径。《融资担保公司监督管理条例》（国务院令第 683 号，2017 年 8 月 2 日公布，2017 年 10 月 1 日起施行）明确监管部门的现场检查措施包括检查融资担保公司的计算机信息管理系统。也就是说，系统里的数据随时可能被拿来核对。

这篇文章按"责任链从哪里开始、指标怎么算、流程怎么串、权限怎么分、报表怎么用"的顺序展开，讲清担保公司客户管理系统在六个方面的关键设计。文中引用的条款均来自公开的行政法规与配套制度，会标注条号性质；涉及厂商公开表述的部分会另行说明。担保行业系统与通用 CRM 在判断标准上的差异，可参考金融行业CRM系统怎么选。

一、先把"责任链"画出来

担保业务的最小管理单元不是"一个客户"，而是"一笔担保责任"。这一笔责任上有四个角色，缺一个就不完整。

• 被担保人。需要被担保的人或企业。系统要记的不只是基本信息与财务数据，还有融资用途、担保类型、在保余额，以及他与其他主体之间的关联关系——因为集中度指标是按"同一被担保人及其关联方"合并计算的，关联关系建不准，集中度就算不准。
• 债权银行。提供资金的一方，也是担保责任的受益对象。公开条例规定，担保公司应当向被担保人的债权人提供与融资担保有关的业务活动和财务状况等信息。这意味着系统需要能按银行维度输出信息，而不是只按客户维度。
• 反担保提供方。可能是被担保人自己，也可能是第三方。公开资料显示，行业系统通常支持六种反担保方式：质押、抵押、保证、信用、留置、定金，并支持单选与多选。反担保物不是附属信息，它决定了代偿之后能不能追回，因此在系统里要作为独立对象管理，带权属、估值、登记状态与处置状态。
• 担保公司自己。承担代偿义务的一方。系统要能表达"这份责任目前占用了多少风险权重、还剩多少可用担保能力"。

四个角色合起来，就是公开资料里用的一句话：担保业务系统覆盖的是担保业务全生命周期——客户管理、项目受理、尽职调查、风险评审、合同签署、在保监管、代偿追偿、统计分析。这个跨度比一般 CRM 长得多，中间任何一个环节断掉，后面都要靠人工补。

二、担保责任余额不是一个"存进去的数字"

这是担保公司系统与通用 CRM 差异最大、也最容易被做错的一项。

公开条例第十四条要求：融资担保公司应当按照国家规定的风险权重计量担保责任余额。配套制度把这个权重写得很具体：

• 单户在保余额 500 万元人民币以下且被担保人为小微企业的借款类担保业务，权重为 75%；
• 单户在保余额 200 万元人民币以下且被担保人为农户的借款类担保业务，权重为 75%；
• 其他借款类担保业务权重为 100%；
• 被担保人主体信用评级 AA 级以上的发行债券担保业务权重为 80%；
• 其他发行债券担保业务权重为 100%；其他融资担保业务权重为 100%。

而且配套制度还规定了两条容易被漏掉的计算规则：对于按比例分担风险的融资担保业务，融资担保责任余额按担保公司实际承担的比例计算；计算放大倍数和集中度时，应当在净资产中扣除对其他融资担保公司和再担保公司的股权投资。

为什么这件事必须由系统算，而不是由人填？因为责任余额是连续的、会变的。客户还了一部分款，在保余额下降；发生展期，期限变化；反担保物估值变化，风险权重可能变；关联方新增，集中度合并口径变。如果责任余额靠人工登记，那么月底算放大倍数时，一定是在算一个过期数字。

系统层面的三个设计要求：

• 在保余额要能自动维护。放款、还款、提前结清、展期、代偿，每一个动作都要更新在保余额。这要求担保系统与账务或放款数据有联动，而不是靠台账手工登记。
• 权重规则要可配置且可追踪。权重取决于业务类型、被担保人类型、在保余额区间、信用评级四个条件。这些条件会随业务变化（比如企业从小微变成中型），因此系统需要能按规则重新计算，并保留"当时用的是哪条规则"的记录。
• 放大倍数要有运行时提醒。公开条例第十五条规定，担保责任余额不得超过其净资产的 10 倍；对主要为小微企业和农业、农村、农民服务的融资担保公司，倍数上限可以提高至 15 倍（配套制度进一步明确为：小微企业和农户融资担保业务在保余额占比 50% 以上且户数占比 80% 以上）。这个倍数在业务前端就应该能实时看到——新增一笔担保后，剩余可用空间是多少，应该是提交时就能看到的数字，而不是季度末才发现的偏差。

三、集中度与关联方：两个必须一起做的能力

公开条例第十六条明确：融资担保公司对同一被担保人的担保责任余额与净资产的比例不得超过 10%，对同一被担保人及其关联方的担保责任余额与净资产的比例不得超过 15%。配套制度还补充了一条特殊规则：对被担保人主体信用评级 AA 级以上的发行债券担保，计算集中度时责任余额按在保余额的 60% 计算。

第十七条则划了一条更硬的线：融资担保公司不得为其控股股东、实际控制人提供融资担保；为其他关联方提供融资担保的条件不得优于为非关联方提供同类担保的条件。同时，为关联方提供融资担保的，应当自提供担保之日起 30 日内向监督管理部门报告，并在会计报表附注中予以披露。

把这几条放在一起，会得到三个具体的系统需求：

• 关联方关系表是必备的，不是可选的。因为集中度按"被担保人及其关联方"合并计算，"同一被担保人"这一档已经不难做，"及其关联方"这一档才是真正的门槛。公开的行业系统方案也把"关联企业图谱"作为客户管理模块的组成部分。做法上：关系表要有方向（控股、参股、实际控制、担保关系）、有来源（客户申报、企业公示、人工核实）、有时间（关系什么时候建立、什么时候解除）。
• 控股股东与实际控制人要有硬拦截。这条禁止性规定不是提示性的，应该在准入环节直接拦住，而不是事后发现。系统需要在被担保人建档或项目受理时，与股东名册、实际控制人名单做校验。
• 关联交易要有报告倒计时。"自提供担保之日起 30 日内报告"是一条有时效的义务，因此系统需要能生成待报告清单并提醒到期。这一条的实践中很容易被忘，因为它是"报告"而不是"审批"，没有审批节点自然也不会有人提醒。

另外，公开条例第四十条列出的处罚情形里明确包含了"担保责任余额与其净资产的比例不符合规定""为控股股东、实际控制人提供融资担保或者为其他关联方提供融资担保的条件优于为非关联方提供同类担保的条件""未按照规定提取相应的准备金"。这提醒了一件事：系统里做不做校验，不是效率问题，而是合规风险问题。

四、保前、保后、代偿追偿是一条流程，不是三个模块

公开条例第十三条要求：融资担保公司应当按照审慎经营原则，建立健全融资担保项目评审、担保后管理、代偿责任追偿等方面的业务规范以及风险管理等内部控制制度。这三件事被写在同一条里，本身就说明它们是连续的。

公开资料对担保业务系统的全流程节点描述比较一致，可以归纳为：担保申请 → 初审 → 复审（含审保会）→ 费用收取 → 签约 → 放款确认 → 保后监管 → 结项 / 代偿追偿。每个节点都设有时效监控和待办提醒——这一点比节点本身更重要。担保业务的真实风险往往不是"某个环节没做"，而是"某个环节拖了太久"。一笔应在一周内完成的复审拖到一个月，客户可能已经找了别家，或者情况已经变化。

• 保前：项目受理、尽职调查、风险评审。公开系统方案提到尽调用模板化报告与数据自动采集，风险评审用规则引擎打分加专家会签。实务上的关键是把"条件"结构化——评审通过往往附条件（补交材料、追加反担保、限制用途），这些条件如果不落进系统，就等于没有。
• 保后：公开资料显示通用做法分首次监管与常规监管，并配置六类风险预警：首次监管预警、保后监管预警、还款到期预警、追偿催收预警、担保费到期预警、担保费逾期预警、担保到期预警。这六类预警覆盖了保后要盯的全部时间点。系统的价值不在预警本身，而在预警之后有没有形成处置结论——这一点在后面的过程指标里会讲。
• 代偿追偿：见下一节。

五、代偿不是终点，案件要能结得干净

公开资料里有一句判断非常精准：代偿完成不等于案件结束。后续还要跟踪催收、和解、诉讼、执行、资产处置、回收金额和结案依据。

这决定了一个关键的设计选择：代偿要建"案件"，而不是改一个状态。公开资料对案件要素的描述很完整，可以直接作为字段清单：关联原担保合同、债权银行、代偿条件、应付金额、审批、付款凭证、追偿权利、反担保物，以及诉讼或处置任务。

还有一条关于分工的提醒值得抄下来：追偿任务应当区分业务协调、法务程序、财务核销、资产处置四类，并避免一名客户经理拥有从"事实补录"到"风险结论"再到"核销"的全部权限。理由很直接——如果一个人既能记录事实、又能下结论、还能核销，那么这条链上的记录就失去了审计价值。关键材料、金额和状态变更都需要保留审计。

这条原则在系统里的落法是：代偿案件的每个环节设置独立的角色与权限，且核销这个动作必须由与业务条线不同的人员执行。权限设计的方法可参考助贷CRM权限怎么分级。

六、权限要按"职责 + 项目敏感度"双重控制

担保业务的敏感性差异极大：一笔小额农户担保和一笔大额债券担保，需要的可见范围完全不同。因此单纯的"按角色分权限"不够，需要叠加"按项目敏感度"这一层。

公开资料给出的一份权限矩阵（厂商公开方案）可以作为设计参考，它的结构值得借鉴：

这份矩阵的核心思想是每个角色都有"不可直接修改"的边界：客户经理不可修改评审结论与风险计量；项目评审不可修改财务实付与合同原件；风险管理不可无依据覆盖历史事实；法务不可修改经营报表口径；财务不可修改客户尽调结论；管理层不可绕过审计批量下载明细。这六条边界，正好对应了担保业务中最容易出问题的六个位置。

此外还有三条实践要求：字段、记录、附件和导出权限要分别配置（能看一个客户不等于能导出全部客户）；关联方、个人担保人、财务材料和诉讼文件按必要性开放；移动端只展示现场工作所需内容。最后这条在实务中经常被忽略——移动端为了"好用"往往展示得更多，结果就成了数据外泄的主要出口。

七、经营报表不能替代监管口径

这是担保公司数字化项目中最容易产生误解的一点。

公开资料说得很清楚：系统经营层可以看新增项目、受理转化、评审时长、条件未完成、在保项目协同、保后任务、预警、代偿案件、追偿进度；但权威的责任余额、净资产倍数、单户与关联方比例、准备金和监管报送，仍然来自专业计量与财务系统——系统只能引用经过确认的口径。

这句话对系统设计的含义是"分层记账"：

• 业务层记录事实。放了多少、还了多少、反担保是什么、条件完成没有。这些是业务系统的权威。
• 计量层产出指标。责任余额、放大倍数、集中度、准备金，涉及权重规则与净资产基数，通常由专业计量模块或财务系统产出。业务系统可以展示，但不能自己发明一套算法。原因很简单：一旦两套算法并存，现场检查时就要解释为什么报表和系统数字不一样。
• 报送层对内对外一致性。公开条例第三十一条要求按要求向监督管理部门报送经营报告、财务报告以及注册会计师出具的年度审计报告等文件和资料。这些材料之间必须自洽。

另外，公开资料给出的四个过程指标很实用，它们衡量的是"过程有没有真的走完"，而不是业务结果，因此特别适合作为系统上线后的验收指标：

• 条件按时完成率 = 按期限完成的放款或保后条件数 ÷ 到期条件数；
• 保后证据完整率 = 完成必要证据并通过复核的在保项目数 ÷ 应复核项目数；
• 预警闭环率 = 在目标时间内形成处置结论的预警数 ÷ 到期预警数；
• 追偿任务兑现率 = 按期完成且有结果证据的追偿任务数 ÷ 到期任务数。

这四个指标的共同点是有明确的分母和分子，都要求"有证据"。它们比"上线了多少功能"更能说明系统有没有真正被用起来。

八、怎么落地：从三十个项目开始

担保业务的复杂度决定了不可能一次性全量上线。公开资料给出的试点方法是：选一个合作银行和一种担保类型，然后抽取十个在评、十个在保、十个风险或已结项目，用这三十个项目把整套逻辑跑通。

具体步骤：

• 明确适用制度与业务类型，避免一上来就覆盖全部产品线；
• 绘制主键关系：客户、关联方、项目、合同、反担保、还款、风险，这七个对象的关联关系是整套系统的骨架；
• 确定系统边界：哪些数据来自业务系统、哪些来自财务系统、哪些来自风险计量，接口怎么对账；
• 配置任务：材料缺口、评审条件、保后任务、预警任务；
• 回放异常场景：展期、逾期、反担保变化、代偿、追偿——这五类异常是最容易在上线后让系统"漏账"的场景，必须在试点阶段就回放验证；
• 核对权限、审计日志、接口对账、双端排版与管理报表，确认无误后再扩围。

公开资料列出的上线验收清单里，有两条特别值得关注：同一企业多项目和关联方关系不会错误合并；评审结论可追溯到材料版本和条件。第一条说的是数据模型（一对多关系要建对），第二条说的是留痕（结论要能追溯到依据）。这两条不达标，后面所有报表都不可信。系统上线的推进节奏与阶段划分，可参考助贷机构数字化转型从哪一步开始。

九、常见问题

担保公司的系统和小贷公司的系统能通用吗？底层相通（客户、项目、合同、贷后都是同类对象），但监管指标完全不同：小贷看集中度与融资杠杆，担保看担保责任余额的权重计量与放大倍数。指标层不能通用，业务层可以复用。小贷系统选型的判断标准见小贷公司管理系统怎么选。

担保费怎么收、能不能自动算？公开条例第十九条规定担保费率由担保公司与被担保人协商确定，纳入政府推动建立的风险分担机制的担保公司还应按规定降低对小微企业和农业、农村、农民的费率。系统层面的需求是：费率按期限、金额、费率计算，支持一次性收取与分期收取，并有担保费到期与逾期预警。财务侧的记账与核算设计可参考助贷佣金结算系统怎么做，费用结构的完整拆解见助贷CRM收费标准。

关联方关系靠谁维护？三条来源并行：客户在申请材料中申报、通过企业公示信息核实、由业务人员在尽调中确认。三者都要能录入并标注来源，因为集中度计算的合规性依赖于关联方识别的完整性。这与信贷客户管理系统怎么设计里"关联关系层"的设计是同一件事。

监管报表要不要在业务系统里生成？可以生成，但要明确它是一个"取数并组装"的动作，口径来自计量层而不是业务层。公开的系统方案里，监管报送模块通常包含数据校验、历史版本比对、一键上报这些功能——"历史版本比对"这个细节很关键，因为报送数据会随业务变化，能追溯上期数字怎么来的，才说明数据是可解释的。

十、小结

• 管理单元是"一笔担保责任"，不是"一个客户"。一笔责任牵动被担保人、债权银行、反担保提供方、担保公司四方，其中反担保物必须作为独立对象管理，因为它决定代偿后能不能追回。
• 担保责任余额是算出来的，不是填进去的。四类权重（500 万以下小微 75%、200 万以下农户 75%、AA 级以上债券担保 80%、其他 100%）＋三项调整（按比例分担按实际承担比例、扣除对担保与再担保公司的股权投资、AA 级以上债券担保集中度按 60% 计），再输出放大倍数（10 倍，符合条件可至 15 倍）与集中度（同一被担保人 10%、含关联方 15%）两个指标。
• 关联方关系表是准入门槛而不是附属功能。不得为控股股东、实际控制人提供融资担保；为其他关联方担保条件不得优于非关联方；为关联方担保须在 30 日内报告并在会计报表附注披露——后者需要系统生成待报告清单。
• 保前、保后、代偿追偿是一条流程。每个节点要有时效监控与待办提醒；保后按首次监管与常规监管配置六类预警；代偿要建案件而不是改状态，案件要能关联原合同、付款凭证、追偿权利、反担保物与处置任务。
• 权限按"职责 + 项目敏感度"双重控制。每个角色都要有"不得直接修改"的边界；追偿任务要区分业务协调、法务程序、财务核销、资产处置，避免一人贯通事实、结论与核销。
• 经营报表不能替代监管口径。业务层记事实、计量层出指标、报送层保一致；四个过程指标（条件按时完成率、保后证据完整率、预警闭环率、追偿任务兑现率）可作为上线验收标准。

最后给一个自检标准：一套担保公司客户管理系统做得对不对，可以问六件事——责任余额是不是系统算出来的、放大倍数在业务提交时能不能看到、关联方能不能自动合并计算集中度、为关联方担保的 30 日报告有没有提醒、代偿案件能不能一直跟到结案、客户经理能不能自己核销一笔追偿。前五件有肯定答案、第六件是否定答案，这套系统才算真正做对了。

担保业务与信贷业务在客户视图、贷后管理、权限设计上是同一套底子，可以接着看信贷客户管理系统怎么设计、助贷贷后管理怎么做与金融居间CRM与普通CRM的差异。涉及与银行协作的部分，见银行中介系统需要哪些能力。