律所 CRM 客户管理系统
一个潜在客户很少只打给一家律所。他们会打给三家，向接电话的人描述自己的麻烦，然后聘请第一个回电的律师。而与此同时，两件足以拖垮一家小所的事，恰恰就藏在这同一次接案里：因为对方当事人正是本所现有客户而被漏掉的利益冲突，以及无人记入期程的诉讼时效。大多数单人所和小型律所靠一本便笺、一个共享邮箱和脑子在硬撑。一套贴合律所真实接案与办案方式的 CRM——一个接案队列、一次真正的冲突检索、一块案件看板、一份期限清单——正是把好客户留下、把执业过失索赔挡在门外的关键。
痛点
- 接案环节漏水：一通转介绍来电、一份网站表单、一位上门访客，全都落在不同的地方，跟进又慢，潜在客户转身聘请了第一个回电的律所，而你的线索还躺在语音信箱里。
- 冲突检索只存在某个人脑子里：新案件的对方当事人是不是本所现在或过去的客户，靠记忆或一张过时的表格来判断，而你漏掉的那一个，往往就是能让律所被取消代理资格的那一个。
- 一个人不等于一个角色：同一个人在这个案件里是你的客户，在另一个案件里却是对方当事人，所以一份只给联系人贴一个标签的通讯录，根本回答不了一个真正的冲突问题。
- 期限被记在所有地方、又哪里都没记：诉讼时效日期和开庭期限散落在一本纸质日历和三位律师的脑子里，而一个被漏掉的日期，正是所有执业过失索赔中最常见的那一种。
你能搭什么
每一位潜在客户都汇入同一个地方，无论来自网站表单、一条转发的通话记录，还是一位上门访客，都带着业务领域、案情描述、以及点名列出的每一位当事人。在一个案件被接受之前，接案必须先通过一次跨越所有联系人与当事人的冲突检索——覆盖进行中的、已结案的、乃至已谢绝的案件，检索结果会记录在这条接案上，于是你手里握有查过的凭证。
一块可拖拽移动的看板，用你真实的阶段——新接案、咨询、已委托、进行中、证据开示、已结案——每张卡片都是一个案件，关联着一位客户联系人以及每一位其他当事人，各自带着一个角色。一个案件可以同时列出客户、对方当事人、协办律师和证人，让记录真正反映出谁站在哪一边。
一份期限清单，把诉讼时效日期、开庭期限和递交期限连同提前量提醒一并浮现出来，再加上一个绑定到案件与联系人的每日任务队列。最近的那个硬性期限，永远是屏幕上最响亮的东西，于是在一个案件被接下到走进法院之间，没有任何要紧事会从缝隙里滑掉。
数据模型
系统里的一天
- 上午 8:40：一条隔夜进来的网站接案和两通转介绍来电正等在队列里。每一条都变成一份接案记录，标记好来源、设定好业务领域，并在案情还新鲜时就把它记录下来，于是没有任何潜在客户被晾在语音信箱的困境里。
- 在安排咨询之前，你对这位潜在客户以及他点名的每一位当事人跑一次冲突检索。系统按全名和别名进行匹配，横跨所有联系人与当事人，包括已结案的案件和先前谢绝的接案，而不只是现有客户。
- 一个命中回来了：这起新纠纷里的对方当事人，正是本所在另一起不相关案件中代理的一位联系人。这条接案翻转为 conflict_pending，路由给负责律师去谢绝、或去争取一份书面豁免，检索结果则盖章记在这条记录上。
- 一条干净的接案通过了。你安排好咨询、把它记为一次活动，等客户正式委托你时，这条接案转化为一个案件，客户联系人被关联进来，对方当事人也作为一位当事人、带着它的角色被加进去。
- 你在这个新案件上录入诉讼时效日期。期限清单立刻创建一条 SOL 期限，带上提前量提醒，于是那个足以终结整起案件的唯一日期，现在成了一项硬性的、看得见的义务，而不再只是一条便签。
- 中午：案件看板显示出哪些动了。你把一个案件从「已委托」拖到「进行中」，又把另一个从「进行中」拖到「证据开示」，每张卡片都带着它的客户、当事人和未结期限一起走。
- 期限清单浮现出一份九天后到期的法院递交任务，以及一个下个月落地的诉讼时效。你把这份递交任务指派给一位助理律师，并确认提醒窗口留得够宽，来得及真正动手处理。
- 一天结束：仪表盘显示还有哪些接案在等待冲突检索、哪些期限本周到期、哪些潜在客户还没回电，于是你下班时清楚地知道有哪些事悬而未决，而不是心存侥幸地盼着一切没事。
AI 容易出错的地方
- 冲突检索不是一次精确姓名查询：它必须检索每一位当事人，横跨进行中、已结案和已谢绝的案件，并在别名、经营字号（DBA）、婚前姓氏和关联实体上进行匹配，而不只是客户的姓名。一个只拿新客户的精确姓名去比对现有客户的粗糙做法，会漏掉真正让律所被取消代理资格的对方当事人冲突和前客户冲突。
- 按案件为每位当事人建模，绝不要给一个联系人贴一个标签：同一个人在一个案件里是客户，在另一个案件里却是对方当事人。如果一个联系人只存一个角色，你就回答不了一个真正的冲突问题，还会把某人到底站在哪一边这件事搞错。
- 潜在客户和已谢绝的客户照样会让你产生冲突：在一次咨询中得知的信息，即便你从未接下这起案件，也可能让律所无法代理对方。把咨询和已谢绝的接案永久保存，并把它们留在冲突检索的范围之内，不要为了整理干净就把它们删掉。
- 诉讼时效日期不是一项可选任务：它是那个一旦错过就终结整起案件的期限，而错过期限正是排名第一的执业过失索赔。给诉讼时效和开庭日期设定带真实提前量的硬性提醒，并把日期毫不含糊地存储，让一个递交期限上差一天的错误永远不会发生。
- 客户保密是一项义务，而不是一个开关：案件细节受保密特权保护，不能存放在一个共享邮箱或一张公开的表格里。把整个系统置于按用户的身份认证与访问控制之后，并把信托账户核算彻底排除在外——因为规则 1.15 要求单独的、经过对账的记录，而一套通用 CRM 根本没有资格去假装做到这一点。
- 一个接案队列，把每一位潜在客户连同来源、业务领域、案情描述和所有当事人一并记录下来，并且在一次冲突检索跑完并被记录之前，禁止接受一个案件。
- 一次横跨所有联系人与当事人的冲突检索——进行中、已结案、已谢绝——按姓名和别名进行匹配，并把结果盖章记在每一条接案上，作为你查过的凭证。
- 一块关联着客户及其当事人的案件看板，外加一份期限清单，把诉讼时效和开庭日期连同提前量提醒一起标记出来。
- 信托账户核算与 IOLTA 对账，以及客户账单或开票：钱是一套单独的、受到严格监管的系统，所以先把它排除在 v1 之外，而不是把它做一半。
- 文书自动生成、电子签名的委托书，以及法院电子递交集成：现阶段先上传或链接文档，把这些文书工作留到以后再自动化。
- 完整的工时记录与计费小时分析：v1 阶段先在案件上记录活动，等接案与期限清单这个核心被验证之后，再加上计费报表。
常见问题
它是真的会跑一次冲突检索，还是只是把姓名存起来？
它会跑一次真正的检索。当你处理一条接案时，它会把这位潜在客户和每一位被点名的当事人，拿去跟横跨进行中、已结案和已谢绝案件的所有联系人与当事人做匹配，比对全名和别名，然后记录下结果。它会把潜在冲突标记出来，交由律师去排除或豁免，而不是替你做那个伦理上的判断，但它给了你一次检索、以及规则 1.7 默认你已经做过的那份书面凭证。
它能处理同一个人站在对立面的案件吗？
能，而这正是把当事人单独建模的意义所在。一个联系人只存在一次，每个案件通过一条带角色的当事人记录与它关联，于是同一个人可以在一个案件里是你的客户，在另一个案件里是对方当事人，而这两者不会坍缩成一条混乱的记录。
它能阻止我错过一个诉讼时效吗？
它是一套记录系统，而不是期限管理纪律的替代品，但它会让那个日期无从丢失。诉讼时效和开庭期限都坐落在一份带提前量提醒的期限清单上，最近的那个硬性日期被最先浮现出来，于是这项义务每天都看得见，而不是被埋在一本没人记得去查的日历里。
客户数据是保密且安全的吗？
你的 CRM 托管运行在 ybuild 上、通过你自己的域名对外提供服务，背后由一套受管数据库支撑、并由受管认证把守、按用户授予访问权限，于是受保密特权保护的案件细节都留在一套受控的系统里，而不是一个共享邮箱或一张公开的表格中。
我能把现有的客户和案件清单迁进来吗？
可以。描述一下你当前表格或导出文件里的列——姓名、案件、当事人、业务领域、关键日期——应用会把它们映射进 contacts、matters 和 parties 表，于是你的冲突检索从第一天起就覆盖你真实的历史，而不是一个空白的数据库。
参考来源
- ABA 示范规则 1.7：利益冲突——现有客户 — 美国律师协会（ABA）关于并存利益冲突在何时阻却代理的规则界定，正是你的接案冲突检索要抓住的那条确切标准。
- ABA：法律客户接案与冲突检索流程是如何运作的 — ABA 的实务指引，讲的是如何收集完整法定姓名、别名和对方当事人，并在接受一位客户之前检索每一个进行中、已结案和潜在的案件。
- ABA 关于客户信托账户记录的示范规则 — 规则 1.15 背后的记录留存基线，以及为什么信托账户核算是一套单独的、经过对账的系统，你要有意识地把它排除在 v1 CRM 之外。
- Clio 法律趋势报告：律所基准数据 — 被广泛引用的基准数据显示律师的平均可利用率接近 38%，凸显出有多少可计费时间流失在了没有条理的接案与行政事务里。
描述它，一次性上线到你自己的域名——托管、全栈、无需服务器。免费开始。