多门店零售合同系统系列之六

作者：合同吴彦祖

前五篇，我们一直围绕多门店零售企业的合同管理展开。

从行业为什么难管，到一套基本合同系统应该具备什么；从拓展人员怎样在经营现场发起合同，到多人怎样协同定稿，再到不同版本怎样完成比对，前面解决的是合同如何进入系统、如何形成，以及如何确认最终签署文本。

但多门店零售企业的特殊性，不只体现在合同办理过程更加复杂。

合同最终服务哪家门店，费用落到哪里，门店迁址、关闭或者更换经营者以后，还有哪些责任没有结束，同样决定了合同能不能真正管住。

所以从这一篇开始，我们继续沿着多门店这条主线，把视线从合同办理过程，转向合同背后的门店经营关系。

一家连锁品牌的运营负责人，临时要查某家门店的全部合同。

门店要迁址了。

租赁、装修、设备、物业和品牌服务合同，哪些还没有履行完，哪些需要变更地址，哪些费用还没有付，都要在几天内理清楚。

工作人员先从组织架构里找。

找不到。

因为这家门店是加盟店，经营者是一名个体工商户，在法律上与总部没有隶属关系，自然不会出现在总部的部门树里。

他又去合同台账里搜索门店名称。

一份合同写着“长风街店”，一份写着“长风门店”，还有一份使用了加盟商的工商名称。明明说的是同一家店，系统却把它们当成三个毫无关系的对象。

最后，大家还是从Excel、聊天记录和区域经理的记忆里拼合同。

问题并不在于系统少建了一个部门。

恰恰相反，如果为了管理加盟门店，把几千家独立经营者全部塞进总部组织架构，组织、审批和权限反而会变得更加混乱。

加盟门店不是总部的下级部门。

但只要合同围绕这张经营网络发生，总部就必须知道合同与哪家门店有关。

这需要的是合同系统里的第二套管理维度。

而且这套维度不能只停留在概念上。

运营负责人要查“长风街店”的合同时，不能再找技术人员导数据，也不能先导出一张总表，再在Excel里慢慢筛。

他应当打开合同台账，点一下区域，再点一下城市和门店，这家店关联的租赁、装修、设备、物业和服务合同便立即出现在眼前。

能不能立刻找到，才是门店管理有没有真正落地的第一条标准。

一、组织、签约主体、合同类型和门店归属，必须各管一件事

普通合同表单经常只有“所属部门”“签约主体”和“合同类型”。

放到加盟零售模式中，这两个字段远远不够。

所属部门回答的是：总部内部由谁负责。

签约主体回答的是：谁在合同上签字，并依法承担责任。

合同类型回答的是：这是一份租赁合同、装修合同、采购合同，还是加盟合同。

门店归属回答的是：合同与哪个区域、哪座城市、哪个经营网点有关。

三者可能完全不同。

例如，一份设备采购合同由总部法人签署，拓展部门负责办理，设备最终配送到二十家加盟门店。总部是签约主体，拓展部门是内部责任组织，二十家门店则是合同的服务对象。

如果系统只记录签约主体，后来只能查到“总部签过一份设备合同”，却不知道哪些门店正在使用设备。

如果系统只记录所属部门，又会把经营网络误解成内部行政关系。

所以，一套面向连锁零售的合同系统，首先要把这三种关系拆开保存，再通过同一份合同把它们连接起来。

系统对象主要回答的问题
内部组织总部哪个部门、哪名员工负责办理和管理
法律主体谁签署合同，谁承担合同权利与义务
合同类型这是什么合同，应使用哪些字段、模板和审批规则
合同分类合同属于哪个区域、城市、项目或门店，怎样快速查找和统计
门店档案这家门店是谁，当前由谁经营，处于什么状态，发生过哪些变化

这不是多增加一个字段。

这是先把法律关系、内部责任、合同性质和经营归属分清楚。

尤其要分清合同类型和合同分类。

租赁、装修、采购，是合同类型。

华北区域、太原市、长风街店，是合同分类。

前者决定这份合同按照什么规则办理，后者决定以后从哪里把它找出来。

二、第一步不是新建一个部门，而是建立区域、城市和门店分类

要让运营负责人立刻找到某家门店的合同，最直接的实现方式，是先在合同系统中建立一套独立于组织架构的合同分类。

后台可以按照企业自己的经营方式建立多个分类维度。

一家区域层级比较稳定的连锁企业，可以建立“区域—城市—门店”的树形分类，从华北区域一路展开到山西、太原和长风街店。

另一家企业也可以把区域、项目和门店分别建立成几个独立维度，再根据自己的管理习惯组合使用。

分类可以是平铺列表，也可以是多级树。

某个维度是否必须填写，能不能选择多个值，要不要出现在合同草拟页面和台账查询条件中，也应当由企业自行配置。

这一步解决的是过去最基础、也最麻烦的问题：不再让经办人手写门店名称。

长风街店在系统中只有一个正式选项。

不管合同由哪个部门发起，不管正文中写的是门店简称、商场铺位还是加盟商工商名称，只要草拟时选择了同一个门店分类，合同最终都会归到同一处。

【截图位置1：合同分类配置页面】

建议展示：区域、城市、门店等分类维度，以及树形或列表、是否必填、是否多选、是否在草拟和查询中显示等设置。

三、合同草拟时完成归类，台账中才能一眼找到

分类建立以后，不能等合同审批结束再让档案人员补。

拓展人员在草拟合同时，就要直接选择这份合同所关联的区域、城市和门店。

一份门店租赁合同通常只关联一家店。

一份总部统一采购合同，却可能同时服务几十家甚至几百家门店，因此门店分类还要支持多选。

如果企业规定“涉及门店的合同必须选择门店”，系统就应在提交审批前完成必填校验。没有归属的合同不能悄悄混进台账，留给以后的人猜。

更重要的是，这种关联不能只保存成一段文字。

合同与分类之间要形成正式的数据关系。合同改名、换负责人或者进入归档以后，这条关系仍然存在；以后按区域、城市或者门店查询时，系统才能准确找到它。

【截图位置2：合同草拟页面中的分类选择】

建议展示：拓展人员选择区域、城市和一家或多家门店，必填项在提交审批前完成校验。

合同进入台账以后，分类要继续发挥作用。

运营负责人可以从左侧分类树逐级进入某个门店，也可以把门店与合同类型、合同状态、金额、相对方和到期时间组合筛选。

他想看长风街店的全部合同，就点长风街店。

他想看长风街店尚未履行完的租赁和物业合同，就在这个结果上继续增加条件。

他想看太原地区所有即将到期的门店合同，也不必把每家店分别查一遍。

分类后台还应显示每个分类已经关联多少份合同，以及还有多少合同尚未归类。存量合同可以批量补充或者调整分类，不能要求档案人员一份一份打开修改。

【截图位置3：按照门店查看合同台账】

建议展示：左侧区域、城市、门店分类树，右侧为该门店关联的合同；再组合合同类型、状态和到期时间进行筛选。

四、合同分类解决“放在哪里”，门店档案还要回答“它是谁”

做到这里，运营负责人已经可以按照门店快速找到合同。

但合同分类首先解决的是归集和查询。

区域、城市和门店分类的配置，合同草拟时的分类选择，合同台账中的分类筛选，以及存量合同的批量调整，这些能力已经可以先把散落的门店合同收拢起来。

企业不必等所有门店管理能力一次建完，才开始解决合同找不到的问题。

先让每份合同拥有准确的门店归属，已经能解决眼前最直接的管理困难。

随着门店越来越多，企业还会继续追问：这家店现在由谁经营？什么时候开业？是否迁过地址？原加盟商退出以后，新经营者从哪一天开始接手？

这时，就需要把分类中的“长风街店”进一步连接到独立的门店档案。

这里不是再维护一套同名数据。

门店档案应当成为门店基础信息的来源，保存唯一编码、标准名称、经营主体、地址、状态和历史变化；合同分类则在草拟、查询和统计时引用这家门店。

管理员修改门店标准名称，不需要再去分类中改一次。拓展人员选择的“长风街店”，运营负责人在台账中点击的“长风街店”，以及门店档案中记录经营变化的“长风街店”，指向的都应当是同一个业务对象。

分类负责让合同迅速归队。

档案负责解释这支队伍背后的门店是谁。

再往后的待开项目转换、门店角色、费用承担、履约延续、迁址关闭和自定义权限，则是在这套归属关系之上继续升级的能力。

要长期按门店管理合同，系统必须知道“这家门店是谁”。

门店需要自己的唯一编码。

名称、简称和地址可以变化，加盟商也可能更换，但门店编码不能跟着每次变化重新生成。否则，迁址前后的合同会被拆成两家门店，更换经营主体后，旧合同也会突然失去归属。

一份真正能用于合同管理的门店档案，至少要说明：

  • 门店编码和标准名称；
  • 直营、加盟或其他经营类型；
  • 当前经营主体或加盟商；
  • 所属经营区域及责任人；
  • 待开、营业、迁址、停业、关闭等状态；
  • 开业、停业和关系变化的生效时间。

门店名称可以改。

地址可以迁。

经营主体也可以换。

但这些变化都应形成历史记录，而不是用今天的资料覆盖昨天的事实。

运营负责人查看三年前签订的租赁合同时，系统仍然应该告诉他：合同签订当时，这家门店位于哪里，由谁经营，属于哪个区域。

【截图位置4：独立门店档案页面】

建议展示：门店编码、经营类型、经营主体、区域、负责人、当前状态和历史变更。截图中不要把加盟门店放进总部部门树。

五、拓展人员提交合同时，正式门店可能还不存在

零售企业还有一个特殊情况。

合同产生得比门店更早。

拓展人员开始谈场地时，项目可能只有一个商场名称和候选铺位。门店还没有开业，正式编码也没有生成，但租赁意向、装修勘察和设备准备已经开始，合同同样需要提交。

如果系统要求“必须选择正式门店”才能发起合同，拓展人员只有两种办法。

要么随便选一家已有门店。

要么把“某某商场待开店”写进备注。

前一种会制造错误关系，后一种则无法查询和追踪。

更合理的做法，是让合同先关联拓展项目、候选场地或待开门店。

项目落地以后，再把这个业务对象转为正式门店。早期形成的合同、审批记录、费用和附件继续挂在同一条关系链上，不需要重新录入，也不会因为门店后来才建立而断掉。

如果项目最终终止，系统同样保留它产生过的合同和费用，并提示相关人员完成解除、结算和材料归档。

系统管理的不是一个门店名称。

它管理的是一家门店从筹备、开业到退出的完整经营关系。

六、在合同页面里，要说清门店扮演什么角色

运营负责人找到那份设备采购合同以后，发现它关联了二十家门店。

仅仅显示二十个门店名称，仍然不够。

有的门店是设备使用方，有的门店承担费用，有的门店负责验收，还有一家门店只是统一收货后再向周边分发。

同一份合同与不同门店之间，关系可能并不相同。

因此，合同关联门店时，页面不能只有一个普通多选框。

用户选择门店以后，还应根据业务需要说明这家门店在合同中的角色、关系生效时间，以及是否承担费用或履约任务。

一份合同可以只关联一家店，也可以按区域或门店清单批量关联几百家店。

反过来，一家门店也可以同时关联租赁、装修、设备、物业、营销和服务等多类合同。

合同详情中要有门店关系。

门店详情中也要能反查全部相关合同。

这两个入口必须相互到达。

七、关联完成以后，门店要继续进入付款和履约

很多系统在合同发起时让用户选择一次门店，审批完成以后，这个字段便再也没有作用。

这仍然不是真正的门店管理。

设备送到哪家店，要按门店生成交付和验收记录。

哪家门店承担费用，要在付款和财务分摊中继续使用同一门店编码。

区域负责人查看辖区履约时，要能看到哪些门店已经安装，哪些仍未验收。

发生质量问题时，也要从具体门店回到供应商和合同，而不是重新在聊天记录中寻找采购依据。

门店与合同一旦建立关系，就要沿着合同继续向后走。

它不仅用于查询，还应成为付款、履约、快递、统计和责任分配的共同依据。

这样，总部签订的一份全国合同，才不会在系统里只剩一个总金额；管理人员可以继续看到它在不同门店如何执行，成本最终落到了哪里。

八、门店迁址或关闭时，先调整归属，再找到没有结束的责任

几天后，这家门店的迁址方案确定下来。

运营负责人再次打开门店档案，系统列出了与它相关的全部合同。

这里先要处理合同归属。

区域调整、门店合并或者管理口径变化以后，不能让管理员逐份修改合同。系统需要根据新的经营关系，对一批合同的分类进行批量追加或者覆盖调整。

旧门店或旧区域停止使用，也不等于删除历史分类。过去已经关联的合同仍然保留原来的经营归属，新合同不再选择这个分类即可。

分类调整完以后，系统还要继续处理尚未结束的责任。

已经履行完并归档的合同保留原关系。

仍在执行的物业合同需要解除。

设备维保合同要变更服务地址。

尚未完成的付款计划需要重新确认费用归属。

两份寄往旧地址、尚未返还的纸质合同，也要通知经办人处理。

门店状态不能一改成“关闭”，所有关系就一起消失。

系统应当先把未完成合同、付款、履约、快递和归档事项列出来，再由责任人逐项决定继续、转移、变更或终止。

已经发生的历史不被改写。

尚未结束的责任也不能被门店状态掩盖。

九、分类让合同找得到，自定义权限决定谁能看

最后还要分清一件事。

合同关联某家加盟门店，只能说明这份合同与该门店的经营有关。

它并不自动授予任何人访问权限。

总部采购合同可能服务这家门店，但全国采购价格、其他门店名单和内部审批意见，未必应该对外开放。

谁能看到合同、能够看到哪些字段、能否下载正文和处理履约，需要由另一套权限规则决定。

而这一部分，不能假装只靠合同分类就已经解决。

现有分类机制能够把合同准确归到区域、城市和门店，也能帮助用户快速筛选；但要适应复杂的加盟网络，系统还需要继续补齐自定义权限规则。

企业应当能够把组织、人员角色和合同分类组合成授权条件。

总部法务可以查看全部门店的合同正文和审批记录。

山西区域负责人只能查看分类属于山西区域的合同。

太原城市经理可以查看太原辖区的门店合同，却未必能够下载涉及全国采购价格的附件。

加盟商作为外部人员，只能访问与自己的门店直接相关、并由总部明确开放的合同内容，不能因为合同关联了这家店，就顺带看到其他门店、内部批注意见和企业底价。

权限还不能只控制“能不能打开”。

它至少要继续细分数据范围、字段范围、文件权限和操作权限：能看哪些合同，能看哪些字段，能否预览或下载正文，能否发起变更、处理履约或者导出台账。

人员换区、门店转让或者加盟关系结束以后，授权也要按照生效时间调整。过去的业务记录仍然保留，但不应让已经离任或退出的人员继续访问新的合同。

合同分类和门店关系解决“合同与谁有关、到哪里能找到”。

权限解决“谁能以什么方式使用这些信息”。

把两者混为一谈，要么业务无法推进，要么敏感信息失去边界。

所以，合同分类负责把合同归到正确的经营范围，自定义权限再决定不同人员能够怎样使用这些合同。

回到文章开头。

运营负责人不再去组织架构里寻找一家本就不属于总部的加盟店，也不再把总台账导出到Excel里逐行搜索。

他打开合同台账，从区域分类中选择“山西”，继续进入“太原”和“长风街店”。

与这家门店相关的租赁、装修、设备、物业和品牌服务合同，立即出现在同一个结果中。

再加上“履行中”和“即将到期”两个条件，需要随迁址处理的合同便被单独筛了出来。

过去需要几个人翻半天资料才能拼出的结果，现在不过是几次选择。

这才是门店分类首先要解决的问题。

不是让系统多记住一个门店名称。

而是管理人员想看哪家门店，就能立刻看到哪家门店的合同。

零售企业真正需要的门店管理，不是在合同表单里多放一个“门店名称”。

第一步，是用独立于组织架构的合同分类，把区域、城市和门店变成可以选择、可以统计、可以批量调整的经营归属，让管理人员想看哪家店，立刻就能找到哪家店的合同。

再往前一步，是让这些分类连接独立的门店档案，记录门店从筹备、开业、迁址到退出的变化，并让合同关系继续进入付款和履约。

最后，还要补上一套能够由企业自行组合的权限规则，让“找得到”和“看得见”成为两件既相关、又边界清楚的事情。

它要让独立于总部组织的经营网点拥有自己的档案，让合同能够准确连接签约主体、内部责任和实际经营地点，再让这种关系一直进入付款、履约、快递和历史变化。

组织架构管理一家企业内部的人。

门店档案管理企业面对的经营网络。

合同分类让总部快速看见经营网络里的合同。

门店档案让总部看懂每份合同背后的经营关系。

自定义权限则保证该看的人看得见，不该看的人越不过边界。

三件事接在一起，总部才能在门店不断增加、迁址和退出以后，既知道每一份合同最终落在了哪里，也能真正把它管起来。

我是合同吴彦祖。

下一篇继续进入合同签署后的经营过程：合同系统与财务系统对接，为什么绝不只是推送一张付款单？