诉前案件管理系统的用法，首先要放在2025年以来立案与调解制度调整的背景下看。民事案件立案前调解已经调整为登记立案后的先行调解，诉前调解不再是一个可以无限期“蓄水”的独立阶段，而是被纳入审判全流程管理的审前准备环节。这意味着系统“怎么用”的答案变了：它不再是一个把案件拦在立案门外做调解的漏斗，而是一个在案件进入诉讼程序之后，把先行调解作为审前节点来组织、跟踪和衔接的流转引擎。理解这条制度前提，立案前调解和案件流转的每一个操作要点才能落到正确的位置上。

入口：登记立案时就完成“调解意愿”和“案件画像”的采集

系统用起来的第一个动作发生在立案窗口。当事人提交起诉材料、法院登记立案的同时，系统需要完成两件事：征询当事人是否同意先行调解，并对案件做初步“画像”。画像的依据是案由、标的额、当事人人数、是否已有同类纠纷、是否涉及群体性因素等字段。调解意愿的征询结果不是一个可选项，而是后续分流的触发条件：同意调解的案件进入先行调解队列，不同意或依法不适宜调解的案件直接进入审理排期，两条路在系统里从一开始就是分开的。

这一步的实操要点是必填规则和材料校验前置。登记环节最容易出的问题是“信息不全就提交”，案件流转到调解员手里才发现缺关键材料或当事人联系方式无效，调解排期只能退回重来。系统应当按案件类型设置分类型的必填字段和材料清单，支持暂存草稿但限制不完整案件的正式提交，并对同一当事人、同一标的的重复案件自动预警。

分流与指派：规则可配置，但“人工干预”通道必须保留

案件进入先行调解队列后，系统按预设规则完成分流和调解员指派。分案的首要维度是案由，系统内置标准案由体系，将案件归类到对应的案由代码，再结合标的额、地域、专业领域匹配调解组织或调解员。婚姻家庭、民间借贷、物业服务、劳动争议等高频类型通常设置专属分案规则，实现案件与调解员专长的精准匹配。

但自动分案不能替代人工判断。实操中经常出现的情况是：系统按规则分给某调解组织，该组织近期案件饱和或调解员与当事人存在地域回避事由，需要快速调整。因此分流模块必须保留人工调整和审批通道，并且分流规则本身应当可配置而非写死在代码里，因为各院的案件结构和调解资源分布不同，规则调整是常态。指派完成后，系统自动向调解员和当事人推送通知，同时启动调解期限倒计时。

调解过程：每一步操作都要留下“可回溯的痕迹”

调解过程管理是系统使用频率最高的模块，也是“会用”和“用好”差距最大的地方。调解排期需要与调解员的日历视图打通，支持现场、电话、视频和在线调解多种方式。视频调解场景下，系统应当支持在线签到、身份核验、录制告知和音视频留痕，笔录在线确认后由各方电子签名。

比排期和签字更重要的是多轮调解的过程记录。一起案件经历了几轮调解、每轮谁到场、双方提出了什么方案、方案如何变化、分歧缩小的节点在哪里，这些信息如果只留在调解员的笔记里，后续司法确认审查和质效考核都缺少依据。系统应当按轮次记录调解时间、参与人、争议焦点、调解方案和结果，并支持调解中止与恢复的状态切换。调解过程中形成的笔录、证据材料和调解员意见，自动归入该案件的电子材料包，为后续无论是转立案还是申请司法确认做好准备。

时限管控：预警要能“升级”，不能只发给承办人

先行调解最怕的是“调而不决、久调不转”。系统需要对各环节设置时限规则：登记后多久完成分流和指派，调解期限多长，超期后如何处置。时限倒计时和颜色预警是基本功能，但真正起作用的是预警的升级机制。如果超期提醒只发送给调解员或承办人，而这个人恰好请假或疏忽，案件就会在系统里“安静地超期”。合理的配置是：临近期限时提醒承办人，超期一定天数后自动上报部门负责人，再超期进入院级督办列表，同时触发“是否转立案”的强制确认提示，而不是让案件无限期停留在“调解中”状态。

出口一：调解失败转立案——流转的核心不是“推过去”，而是“材料跟着走”

调解失败后的转立案，是案件流转中最核心也最容易断链的出口。系统层面的标准动作是：调解员提交调解失败结果和失败原因，系统自动将案件基本信息、当事人信息、调解笔录、证据材料和调解员意见打包，推送到审判系统的立案程序。书记员在审判系统中点击“转立案”时，这些信息应当自动带出并预填，而不是重新录入一遍。

实操中最常见的返工点在于材料归卷的完整性。调解失败不等于调解过程中的材料作废：调解笔录中当事人对事实的承认或否认、争议焦点的归纳、调解员对案件走向的判断，对后续审理都有参考价值。这些材料应当随案件自动归入审判系统的电子卷宗，而不是留在诉前系统的文件夹里等人手动搬运。验收时应当用一起真实调解失败案件，从调解员提交结果开始计时，检查审判系统收到案件时材料是否齐全、字段是否可读、调解期限是否已正确终止，而不是只看“转立案按钮能不能点”。

出口二：调解成功后的司法确认与自动履行

调解成功后的出口有两条分支：需要司法确认的，系统将调解协议、调解笔录、当事人身份信息和司法确认申请打包推送至法院审查，裁定书生成后自动回传诉前系统并通知调解员和当事人；不需要司法确认但当事人愿意自动履行的，系统记录履行状态和履行期限，到期未履行的自动提醒并转入执前督促或转立案程序。这两条分支在系统里应当有明确的状态标记，避免调解成功的案件在“已成功”状态下沉默，后续履行情况无人跟踪。

底座：与人民法院调解平台的对接，决定系统是“帮手”还是“负担”

诉前案件管理系统的日常使用体验，很大程度上取决于它与人民法院调解平台之间的对接深度。如果两个系统各自独立运行，立案法官就要在诉前系统登记一遍、在调解平台再录一遍，两个编号、两套状态，调解结果还要手动抄回，系统不仅没有减负，反而增加了重复劳动。

合理的对接逻辑分三层。第一层是案件信息单向推送：诉前系统作为登记入口，将案件编号、案由、当事人、诉讼请求、标的额等信息推送到调解平台，调解平台生成调解编号并回写映射关系，法官不再二次录入。第二层是状态自动回传：调解平台将“已受理、已指派、调解中、调解成功、调解失败、已转立案”等节点回传诉前系统，立案法官在一个界面就能看到进展，不需要每天登录两个系统切换查看。第三层是结果与材料回传：调解协议、笔录、司法确认材料和签名页回传后自动关联案件，支撑归档和后续流转。验收对接时应当逐字段核对映射表，并模拟“推送—受理—调解—成功或失败—回传”全链路跑通，而不是只看接口文档里写着“支持对接”。

诉前案件管理系统的“用”，本质上是用一条可追踪的流水线替代过去靠台账和电话维持的线下流转：入口把意愿和画像采准，分流把人和案件匹配好，过程把每一轮调解留痕，时限把案件往前推而不是囤在原地，出口让转立案和司法确认都有材料兜底。这套系统用得对不对，检验标准不在功能菜单的多少，而在一个具体的问题上：一起案件从登记到离开先行调解环节，操作人员需要重复录入几次、手工搬运几次文件、打几个电话追问进度。这些动作越少，系统才越接近它该有的样子。