我的案例

接访窗口最怕这种场面：来访人坐下，说的还是三个月前那件事，只换了说法和部门。重新登记、转办、一查——已经办过两轮。

重复访、多地访，是信访工作里最耗人力的一类。同一件事在不同层级、不同部门各立一份卷，彼此不知道对方的存在，办理意见还可能互相矛盾。

本案例的系统用勤哲 Excel 服务器搭建，把判重放在填报之前，把同一上访人的多次来访串成一条线，再用预警和分析把办理过程管起来。系统在全市已稳定运行一年，数据准确性经过实际检验。

第一难在认人。同一位来访人，不同次登记时姓名写法可能有别，联系方式换了，住址也变了。系统里存着几万条记录，靠姓名检索，很难判断眼前这位是不是来过。

第二难在认事。同一件诉求，这次说的是宅基地，上次说的是补偿，归类不同，卷宗就落在不同目录下。办案人员看到的只是自己手上这一份，看不到前因后果。

第三难在跟办。案件转给涉事单位后，办到什么程度、有没有回复、群众是否认可，缺少统一的记录口径，督办只能靠电话催。

三难叠在一起，结果就是重复劳动：同一件事被反复调查，同一批材料被反复调取，接访人员的时间大量消耗在"确认这是不是新案子"上。

系统的做法很直接：新案件录入时，先判重。输入来访人信息与诉求要点，系统在既有记录中检索，提示是否为多次访、是否属于多次上访人员。

判重前置，改变的是工作顺序。过去是"先立案、后并案"，重复的卷宗已经建好，再回头合并；现在是"先确认、再立案"，不该新建的就不新建。

对于确实的新情况，系统提供两个入口：一是预警案件，事情尚未发生或尚在苗头，提前登记、提前交办；二是首次案件记录，作为后续判重的比对基准。

这两个入口的设计思路不同。预警重在"防"，把可能引发集中反映的问题提前摆到台面上；首次记录重在"存"，为下一次判重留下可比的底稿。

案件记录采用的是"一对多"结构：一位上访人的固定信息记在一张"上访信息表"里，姓名、住址、联系方式这些不常变的内容只维护一份；每一次来访另记一张"上访情况表"，写清时间、接待人、诉求和办理进展。

这样的结构解决了一个老问题：同一个人来十次，不必把姓名住址抄十遍，也不会因为某次登记写错而导致同一个人变成两个人。

对办案人员来说，打开信息表就能看到这个人的全部来访轨迹；打开情况表，又能看到某一次来访的具体情形。纵向看人、横向看事，脉络清楚。

表与表之间由勤哲 Excel 服务器的表间公式关联，新增一张情况表，信息表上的来访次数、最近来访时间随之更新，不需要人工统计。

接访部门填完信息表与情况表，案件就进入处置环节。系统按归属自动把信访信息推送到涉事单位，对方在自己的界面上看到待办，不必等纸质交办单送到。

涉事单位填报接访情况与处置结果，内容回流到信访部门。这个回流不只是"交差"，它同时是后期分析的素材和部门评分的依据。

流程上的每个节点都带时限。超期未办的在列表里标出来，督办人员一眼能看到卡在哪一环、卡了多久。过去靠会议催办的事，变成了系统里的待办清单。

汇总分析是这套系统的另一半。案件数据先按时间、地点、上访主体分类，再按结案状态、是否属于非正常访区分；日、月、全年三档分析表和一份通报表，都由系统自动生成。

报表不是把数字堆在一起，而是回答具体问题：这个月哪些地区案件集中、哪类诉求增长最快、哪些单位办结率偏低。口径固定之后，不同月份之间可以直接比较。

评分则把办理质量量化。依据办结率与接访情况，系统对各部门的涉访情况打分，分数进入通报。这一步让督办从"提醒"变成了"评价"，压力传导更直接。

对管理层来说，日表看动态、月表看趋势、年表看结构，三层视角各有各的用处，不必每次重新组织数据。

第一件是重复立案少了。判重前置之后，同一件事被反复建档的情况明显减少，接访人员的时间从"确认是不是新案"转回到"处理这件事本身"。

第二件是脉络清楚了。一个人的多次来访、一个问题的多个侧面，都归在同一条记录下，办案时不必再靠回忆和翻卷宗拼接前情。

第三件是督办有据。办结率、接访情况进入评分，通报按月出，部门之间的比较有了统一标尺，督办不再只靠开会强调。

系统在全市运行满一年，数据的准确性是在实际使用中被验证过的。这个"一年"很关键——信访数据要经得起跨年度比对，短期跑通不算数，能长期稳定才算落地。

这套系统的价值不在于替人做判断，而在于把判断需要的信息摆齐：这个人来过几次、这件事办到哪一步、哪个单位拖得久。信息齐了，处理方式仍然由办理人员依据政策与实际情况决定。

勤哲 Excel 服务器在其中扮演的角色也很朴素：用表格描述业务，用表间公式连接数据，用工作流推动流转。系统由业务人员参与搭建，改起来不必依赖外部开发，这是它能在一年里持续贴合实际流程的原因。

对同类单位而言，可借鉴的经验有两条：一是把判重这类"事后补救"的动作前移到录入环节，二是让统计口径在系统里定死，而不是每次临时加工。前者省人力，后者省争论。