接手一家咖啡店前，必须核对的软硬件资产清单

先写清楚这次交易到底交什么

一家咖啡店看起来是桌椅、咖啡机和收银台，实际运营还依赖许多不可见对象。POS商户主体、支付终端、库存库位、会员规则、外卖门店、地图商家、企业邮箱、域名、网络配置、监控权限、云端文件和供应商联系人都可能影响营业。若合同只写“店内设备及系统”，双方很容易对同一句话产生完全不同的理解。

CoffeeCloud在项目开始时先建立范围冻结表。每个对象必须标明是否随项目移交、只提供历史导出、需要向平台重新申请，还是明确排除。范围冻结不是为了让清单变长，而是避免切换日才发现某项关键能力从未被任何人承诺交付。

例如，咖啡机可以作为实物资产移交，但保修、租赁、维保合同与远程监控账号可能属于不同主体；收银平板可以在店内，但其中登录的支付账户可能仍连接原经营者的税务和银行资料。物理位置只能回答“东西在哪里”，不能回答“谁能合法、稳定地继续使用”。

项目负责人应把交易合同、设备台账和平台规则分开保存。三者互相引用，却不能互相替代：合同决定商业范围，台账记录实际对象，平台规则决定某项账号能采用什么方式变更。

沿着门店平面盘点，避免只看财务表

现场盘点从门口开始比从一张旧Excel开始更可靠。入口区域可能有门禁、电子招牌、背景音乐设备和地图二维码；收银区包括POS主机、钱箱、打印机、扫码器、支付终端与备用网络；吧台还会出现咖啡机、磨豆机、电子秤、净水和温控设备。

后场容易遗漏的是标签打印机、库存平板、NAS、路由器、交换机、监控录像机、UPS、备份硬盘和供应商专用设备。每件设备至少拍摄整体、铭牌、接口和当前运行状态，并将照片编号对应到台账。照片不是验收本身，但能解决型号、序列号和外观缺陷争议。

同一套设备若跨多个区域工作，也要记录依赖关系。前台打印机可能依赖后场路由器，电子菜单可能依赖云端账号，咖啡机的联网模块可能依赖供应商平台。把设备逐件列出却不写依赖，切换时仍会出现“每件都在，但整套不能工作”的情况。

盘点结束后让未参加现场巡查的人按台账找到设备。若他无法根据区域、标签和照片定位对象，说明台账仍停留在熟人记忆，而不是可以交给新团队使用的资产资料。

硬件台账至少要回答六个问题

第一是对象身份：品牌、型号、序列号和店内标签。第二是权属：自有、租赁、借用、供应商押金设备或随合同使用。第三是现场状态：正常、限制使用、待维修、缺件或无法测试。第四是依赖：电源、供水、排水、网络、账号或特定耗材。

第五是证据：发票、保修、维修记录、安装手册、最近保养和现场照片。第六是责任：谁负责修复、补件、联系供应商和最终签收。只有“设备名称＋数量”的表格不能承担交接，因为它没有说明设备为何能用、为什么不能用，以及异常由谁处理。

对咖啡机、制冰机、冷藏和净水设备，测试环境必须一起记录。水压、水质、过滤器状态、排水、电力和环境温度都会影响结果。机器在错误条件下短暂启动，既不能证明长期可用，也可能放大已有缺陷。

支付终端还要加上防拆检查、设备标识、连接方式和服务商。终端外观正常并不表示商户绑定、结算账户或软件配置已经属于新经营者；设备验收与支付主体切换应当分成两张签收记录。

软件和账号不能用共享密码当成交付

账号交接先区分所有者、管理员、操作员和只读角色。能登录并查看报表的人，不一定能增加用户、改变结算账户、移除旧管理员或完成主体认证。每个平台都要写明当前最高权限、目标最高权限、邀请状态和最终确认人。

密码共享会隐藏真正的所有权问题。新经营者若继续使用原负责人的个人邮箱登录，日后密码重置、设备验证或争议处理仍会回到旧主体。正确做法通常是由现持有人在平台内邀请新主体，再按平台允许的步骤转移主要角色，最后撤销旧访问。

有些平台允许转移账户，有些只允许变更角色，有些在企业出售场景下要求新建账户并重新验证。CoffeeCloud不会把这些差异压成一条“修改邮箱即可”的教程；项目台账必须保留平台给出的正式路径、受理编号和无法转移的理由。

企业邮箱与域名尤其需要关注恢复渠道。仅把日常邮箱密码交给新团队，却没有迁移域名注册、DNS、账单联系人、恢复邮箱和双重验证，可能让旧人员仍能在后台恢复控制权。

会员、订单和员工资料单独审查

会员姓名、手机号、生日、消费偏好、储值、优惠券和订单明细可能构成个人信息或敏感经营资料。它们不是因为存放在门店电脑里，就自然成为可以随硬件复制的资产。双方需要先查明处理目的、适用地区、告知或同意要求、保留期限及新旧主体责任。

数据台账按字段而不是按文件名审查。一份名为member_export.xlsx的表可能同时包含会员标识、营销授权、储值余额和内部备注；四类字段的必要性、准确性和处理风险并不相同。只写“会员数据已导出”无法证明转移范围合理。

备份也要能恢复。项目组应抽取一个不含真实敏感信息的样本，在隔离环境核对字段、编码、附件和时间范围。若导出的文件无法被新系统读取，或者缺少字段定义，它只能算完成了复制，不能算完成了可用交付。

涉及个人信息、储值、税务、工资或健康信息时，CoffeeCloud只负责技术台账与流程协调；法律结论、主体责任和具体处理方式应由相应平台及合格专业人员确认。

把切换日设计成可回退的窗口

切换日不应同时更换POS主体、网络、菜单、会员规则、打印机和全部员工账号。变量越多，出现故障时越难判断原因。较稳妥的安排是先完成备份和新账号验证，再选择低峰窗口逐组切换，并为关键收款与出单任务保留替代方案。

每个切换动作写清开始条件、执行人、验证任务、最长等待和回退点。例如，支付终端只有在新商户验证完成、测试交易和退款路径都核对后，才从旧终端退出；若平台未按时完成审核，则继续使用事先批准的替代收款方案，而不是临时借用个人账户。

现场沟通要围绕任务而不是群聊消息。任务记录包括当前状态、第一条错误、已经尝试的动作、负责人和下次检查时间。仅发送截图会让下一班人员重新猜测设备、账号和发生顺序。

切换窗口结束前，项目负责人核对当日订单、库存扣减、打印、会员识别、外卖接单、网络和后台报表。真实营业任务比界面上的绿色状态更能说明系统是否完成连接。

验收签字之前先处理例外项

例外项不是失败清单，而是尚未满足签收条件的对象。每条例外要写明影响、临时措施、责任人、证据和截止条件。把“等待平台处理”写成状态没有意义，必须保留受理渠道、当前角色和到期后的替代安排。

设备缺陷应区分外观、性能、环境和资料四类。划痕可能不影响运行，漏水会影响安全，错误水质可能缩短寿命，缺少保养记录会影响后续责任。不同类型的缺陷不能用一个笼统折价结论解决。

账号例外则关注控制权：旧主体能否恢复、新主体能否增加管理员、账单归属是否改变、API密钥和第三方集成是否更换。若其中任何一项仍依赖旧人员，项目只能标为受限交付。

签字文件要引用具体台账版本和例外清单版本。没有版本号的“全部完成”会在后续更新中失去对象，双方也无法确认签署时看到的是哪一份资料。

新账号可用后，还要证明旧权限已撤销

许多交接在新负责人成功登录时就宣布完成，却遗漏旧手机会话、恢复邮箱、浏览器密钥、API令牌、共享云盘、路由器管理员和实体钥匙。新增访问与撤销旧访问是两个独立控制目标，必须分别取得证据。

撤权顺序要避免先锁死关键系统。先查明至少两名新主体管理员、恢复方式和紧急联系人，再逐项移除旧角色、退出设备会话、轮换密钥并回收实体资产。每个动作都要由新团队重新执行一个必要任务，确认没有误删依赖。

供应商访问也要进入范围。维修公司、外卖代运营、会计、广告代理和网络服务商可能拥有后台权限或现场钥匙。项目结束时重新确认合作关系，保留仍需访问者的范围和期限，撤销无持续业务需要的账号。

撤权复核宜在切换后另一个时间点进行，因为部分平台会延迟更新会话或角色。第二次清点可以发现被浏览器保存、被自动化任务使用或被旧设备继续持有的访问。

会员仪表盘如何支持双方协作

CoffeeCloud会员仪表盘把项目拆成范围确认、资产盘点、资料备份、账号迁移、现场切换和最终验收六个阶段。每个阶段显示未完成任务、例外项和当前责任，不用一个百分比掩盖关键对象仍未交付。

仪表盘只展示项目需要的摘要，不要求客户在网页中粘贴密码、验证码、完整会员导出或支付资料。敏感文件采用项目约定的受控渠道处理；网页任务只记录文件是否存在、由谁核对以及结果是否通过。

会员登录使用项目编号和单独发放的访问密钥。没有公开注册，也不会因为知道门店名称就取得项目权限。若成员离开项目，应撤销其记录并重新发放访问密钥，而不是继续共享同一份群聊密码。

仪表盘是协作证据，不替代合同、平台审核或专业意见。它的价值在于让双方看到同一版任务、同一条例外和同一组签收条件。

最后用开门营业而不是文件数量验收

交付包可以包含许多文件，但最终仍要回答门店能否在目标经营主体下完成营业。开门测试应覆盖员工签到、收银、支付、出单、库存扣减、会员识别、外卖接单、网络、打印和日结；每个任务保留成功或失败证据。

测试交易需要按平台规则处理，不应用真实顾客资料制造假订单，也不能让未授权人员接触支付或会员信息。项目组可以使用平台允许的测试方式、小额真实交易或预先批准的内部流程，并在完成后核对撤销与对账。

如果关键任务依赖临时账号或旧主体协助，验收记录必须标记为临时运行，而不是完整移交。临时措施写明终止条件，避免半年后仍无人知道某个邮箱为何属于前老板。

CoffeeCloud把最终结果分成已交付、受限交付、待平台处理和明确排除四类。清楚的边界比一个漂亮的完成率更能保护接手后的日常运营。

先用依赖图找出真正的停业风险

资产台账完成后，再把关键营业任务画成依赖图。顾客完成一笔订单，可能依次经过网络解析、POS账号、商品库、支付终端、打印机、库存和后台日结。若只按设备类别分组，这些横跨多个系统的依赖会被拆散，直到切换日才同时暴露。依赖图不需要复杂软件，一张表列出任务、前置对象、失败表现、替代方式和负责人员即可。

优先级不能只按采购价格排序。价格不高的路由器、打印服务或域名账号，可能控制整间门店是否能接单；昂贵的备用磨豆机反而不影响当天开门。项目组应同时记录中断影响、恢复时间、是否有替代方案和对顾客的可见程度，由此决定哪些对象必须在低峰窗口先验证。

依赖关系还可以揭示隐藏的单点负责人。例如，所有供应商账号都由一位离场店长的个人邮箱恢复，或所有门店平板都依赖同一个没人知道用途的账号。把这个人或账号列为关键依赖后，才能在切换前建立企业身份、第二管理员和紧急联系路径。

如果一项任务跨越旧主体和新主体，必须写清过渡期边界。旧账户负责哪一笔交易之前的退款，新账户从哪个时间开始接单，谁处理跨日订单，都应落到可以对账的时间点。模糊的“当天切换”不足以解决跨午夜、延迟结算和预约订单。

三种门店情境会改变清单重点

第一种是原址继续营业、只更换经营主体。它最重视支付、税务、平台所有权、会员权益和旧权限退出，因为设备与网络环境大多不变。现场能继续出杯并不表示后台主体已经切换，反而更容易让团队误以为所有系统都可沿用。

第二种是品牌保留、门店迁址。除了账号主体，还要重新检查水电、排水、网络、设备安装与地图位置。旧址测试通过的咖啡机和打印链，在新址可能因为水压、VLAN、IP地址或服务商不同而失效。此时设备状态和现场环境必须拆成两个签收对象。

第三种是连锁体系内的店长或加盟方变更。总部平台可能仍归同一主体，但单店角色、门禁、供应商和现场设备责任发生变化。清单要避免误触全局商品库、跨店会员规则或其他门店管理员，同时确保离场团队不能继续查看该店报表与监控。

三种情境也可能叠加。项目负责人应在范围冻结时选择主要情境，再逐条标记例外；不能因为模板里有一百个字段，就假设每个项目都用同一种顺序。真正有效的清单会随着交易结构改变重点，但不会省略归属、验证、责任和撤权四个核心问题。

把证据分成存在、控制、运行与退出四类

存在证据说明对象真实可见，例如铭牌照片、账号列表、合同或导出文件。控制证据说明新主体能够管理，例如增加管理员、修改恢复方式或联系平台。运行证据来自真实任务，例如完成支付、退款、打印、库存扣减和报表。退出证据则证明旧角色、会话、令牌和实体入口已经关闭。

四类证据不能互相替代。一张登录成功截图属于有限的运行或访问证据，却不能证明账号所有权；设备发票可以说明购买历史，却不能证明当前运行；旧人员口头表示已经退出，也不能替代后台角色和活动会话复核。签收表应为每类证据保留独立位置。

证据还要能够追溯到对象和时间。照片需要资产编号，平台截图需要显示平台、门店和角色，测试交易需要能对回报表，撤权记录需要说明由谁执行和由谁复查。仅把大量图片塞进同一文件夹，会让后续人员无法知道它们支持哪一项结论。

涉及敏感资料时，证据应采用最小披露。可以记录字段数量、哈希、样本读取结果和授权人员，而不是把完整会员名单附在签收报告。CoffeeCloud仪表盘也只显示摘要和状态，敏感原件留在项目批准的受控渠道。

完成后一周再做一次营业复盘

开门当天通过并不代表所有延迟任务都会正常。供应商账单、周期性备份、自动报表、会员生日权益、订阅续费和平台结算，可能隔几天才运行。项目应在一个完整营业周期后复核后台作业，而不是签收后立即解散所有联系人。

复盘先看例外清单是否真的缩短，再看新出现的问题能否追溯到台账。若团队仍靠询问旧店长才能解释打印路由、折扣规则或供应商账号，说明知识尚未完成交付。此时应补充字段说明、操作责任和恢复步骤，而非简单延长共享账号。

复盘也检查访问日志和供应商权限。旧设备是否仍登录，自动任务是否还使用旧令牌，临时管理员是否已撤销，恢复邮箱是否完全属于新主体，都需要二次确认。延迟撤权不是默认安排；它必须有明确理由、范围、截止时间和复核人。

最终报告不追求所有项目都显示绿色。已交付、受限交付、等待平台和明确排除各有清楚定义，反而比把问题隐藏在完成率中更可靠。接手团队知道哪些能力可以独立使用、哪些仍有条件，才真正取得可持续运营基础。

出现争议时，从签收条件倒推事实

交接后的争议常被简化成“原来就是坏的”或“接手后才改坏”，但设备和系统状态往往受环境、账号与操作共同影响。项目记录应从双方预先同意的验证任务出发，比较签收时证据、当前条件和中间变更，而不是只比较两张外观照片。

设备争议先复现供水、电力、网络、耗材、预热和负载；平台争议先核对主体、角色、恢复、集成和操作日志；数据争议则对照基准日、字段定义、迁移批次和目标结果。不同对象使用不同证据，不能用一份总完成表判断全部责任。

若签收时已经列为受限交付，后续处理应回到当时写明的责任人、临时措施和截止条件。若当时标为通过，却发现证据不足，就承认验证缺口并重新测试，不应补写一张没有现场依据的旧记录。

紧急风险优先控制。漏电、漏水、支付异常、顾客资料暴露或旧人员继续访问时，应先停用相关能力、保存必要证据并联系服务商或合格专业人员。责任讨论不能成为继续运行高风险系统的理由。

一份能支持争议处理的台账，不是为了预判谁对谁错，而是把对象、条件、动作和时间留在同一条证据链。它让双方知道哪些事实已经验证、哪些只是陈述、哪些需要第三方判断。

争议关闭后还要把原因写回清单。若问题来自字段遗漏、测试条件不完整或角色理解错误，下一次盘点就应提前加入对应证据。若只是单店特殊条件，则保留为项目例外，不把偶发情况机械扩大成所有门店都必须执行的步骤。

复盘结论要由能承担后续动作的人接收。设备问题进入维保，平台问题进入正式工单，合同和责任问题交由合格专业人员；项目台账负责连接证据和状态，不替这些角色作超出能力的裁决。