批发企业安排业务员跑餐饮门店，常见的尴尬不是没有人注册，而是业务员谈成意向后，门店用另一条链接自行注册，后台出现两份相似客户档案；运营给其中一份开通商城，财务给另一份设置账期，首单最后又由客服代下。主管看到“新增客户一户、订单一笔”，却无法回答是谁开发的、当前谁负责、客户为何能下这笔单，更无法合理核算拉新业绩。客户归属要从可核实的门店身份出发，在注册、审核、负责人确认和首单履约之间建立同一条记录；不能把转发链接、填写负责人和获得提成当成同一件事。
开发线索、注册账号和有效客户不能混为一谈
销售主管先规定三个状态：业务员拜访后得到联系人和采购需求，是待核实线索；门店身份、收货地址和账号建立并通过企业审核，是可服务客户；订单由客户确认、进入实际履约并符合企业的有效交易口径，才是首单转化。加了微信但不知道门店名称不算建档；扫码注册但从未确认价格和收货地，也不算首单可达。若把注册数直接作为拉新业绩，业务员可能反复邀请同一门店不同员工开账号，名单很快变长，真正可采购的门店却没增加。
例如业务员去青禾餐饮南山店拜访周店长，先确认该店是否独立采购、谁有订单审批权、由谁接收货物、发票和账期是否由总部统一负责。一个连锁品牌有十家门店，不一定是十个独立结算客户；一家门店有店长和厨师两个联系人，也不应成为两份客户档案。销售记录门店地址、经营品类、预计采购的鲜品与干货、首次试单时间和下一次联系约定。主管看这些事实，才知道这条线索是否值得进入建档流程。手机号可能换人，门店名称可能简称；去重应交叉核营业主体、收货地、联系人、旧客户编号和历史订单，不能只凭一个号码。
建一份可承接价格、履约和收款的客户档案
线索确认后，由授权人员在管理端建立或审核同一客户身份，录入客户类型、所在区域、收货地址、联系人及结算安排。图1展示管理端客户列表中可按编号检索的客户记录，便于主管先查有没有旧档案再新增。页面展示的是已存在资料的样例，不意味着系统会自动替企业判断两家公司是否同一经营主体。若门店已经在旧档案下有应收或售后，不能为了给新业务员计拉新而新建一份“干净客户”；应先核真实归属与原业务责任，再按企业规则调整负责关系。
图1：先用客户编号及门店资料核重，再决定是继续旧档案还是建立新客户。
图2中的客户详情能核名称、编号、类型、区域等基础信息，销售和运营应围绕同一编号复核资料。示例编号只用于说明方法，不应把“编号相同”作为无需确认经营主体的唯一证据。客户自助注册时，也要核注册人是否真的代表采购门店、手机号是否可联系、收货地址是否准确，以及是否已存在由销售预建的客户；必要时把线索交给主管人工合并或转交，而不是让业务员从自己的个人表格里记一份、后台再建一份。
图2：客户身份核定后，报价、订单、欠款与售后应沿该档案延续；更名或换联系人不应切断历史责任。
资料不是越多越好，关键是下一岗位能据此判断可否交易。若合同要求总部付款，门店客户可以负责收货与选品，但财务应清楚实际付款方；若按单现金交易，不能误套别家门店的月结政策。开户资料、授信条件和特殊报价都要经相应负责人批准，业务员不得为了促成首单自行填写虚构账期。后续发现客户类型、区域或收货主体录错，应在同一客户档案上按权限更正并保留变更依据，避免新旧档案形成相互矛盾的交易历史。
先核当前服务归属，再讨论开发贡献和提成
“是谁邀请来的”“现在哪个员工负责”“首单由谁陪同完成”“提成算给谁”是四个不同的问题。业务员在手机端分享邀请入口，只能说明他进行了邀请动作；普通商城链接更未必携带邀请归属。客户注册或管理员审核后，销售主管应在客户详情核所属员工、所属部门与区域，必要时指定当前服务负责人。若客户从广告入口自行注册，但此前已经由某业务员有效拜访，主管可对照拜访时间、客户反馈和企业内部规则确认开发贡献，不能仅凭谁最后转发链接决定历史归属。
图3展示业务员手机端入口，它说明员工能从移动端进入客户服务与邀请场景，却不等于每个扫码注册账号都自动完成正确绑定。主管还应在PC端复核最终客户资料与员工归属；若员工调区或离职，先处理未完报价、在途订单、欠款和售后，再变更服务负责人。变更后新负责人承担后续服务，不应抹掉原开发人的历史记录；提成计算可按企业约定区分开发奖、首单奖和持续维护奖，系统中的当前负责人字段不能单独代替薪酬制度。
图3：移动端入口支持业务员开展邀约与服务；客户实际归属仍要到客户档案核定。
为避免两名员工争同一客户，主管要在首次建档时明确：谁提供第一条可验证的线索，谁完成有效拜访，客户原本是否有服务人员，谁负责之后的交付与回款。争议期不应让两人同时以不同价格向客户报价；先锁定统一的客户政策和联系人，再在内部处理贡献分配。对已经由平台运营获客但需要属地业务员服务的客户，也应分开记录获客渠道与服务归属，避免“归到业务员”就把内容或渠道获客功劳全部抹去。
审核开通前，替客户走一遍可购买路径
客户资料齐全不代表手机商城已经能买。运营或客服应以该客户允许使用的入口核登录方式、店铺、商品可见范围、客户价、规格与单位、起订量、配送区域、收货地址和付款条件。客户买鲜整鸡按公斤计价，报价时要说清是否按称重结算、预计与实际重量如何对账；店长看到“每箱”和采购实际要的“每公斤”不是一回事。若销售口头答应周五配送，系统配送范围却只覆盖下周一，首单很可能在确认页被放弃。对医药器械或其他有资质要求的商品，还要先完成企业既定的资格核验，不能为了测试订单绕开准入。
销售主管可拿一张首单准备清单让业务员与运营交接：客户账号已可登录，意向SKU能看到，价格和报价一致，收货人与地址得到客户确认，供货库存和配送时间可执行，付款与授信通过审批。每项有对应负责人和完成时间；缺货找采购或仓库，价格找定价负责人，配送找履约，信用找财务。不要把所有障碍笼统写成“客户不会下单”，否则培训客户十次也无法修复一个错误的商品范围或账期限制。
首单按客户真实需求成交，并把履约结果交回业务员
首单最好选客户确定会用、企业能稳定供的常购商品，而不是为了完成开发指标凑一张虚高订单。业务员可以在手机商城现场指导客户搜索商品、确认规格和单位、检查单价、数量、收货地址及最终金额。图4是手机端订单确认页面示例，重点在让客户逐项核对，而非只看页面最底部“确认订单”按钮。鲜整鸡这类按重量采购的商品尤其要说明单位、称重和最终结算规则；页面样例价格不是给任何客户的统一报价。
图4：首单确认应由客户核数量、计价单位、地址、付款和配送条件；手机端记录是指导客户自助下单的优先场景。
如果客户不愿现场操作，授权员工可以依据客户确认的品项与数量协助代下，但需说明是代客订单，不将其算作客户已经养成线上自助采购。购物车里的商品尚未成交，提交订单也不等于已履约；订单后还要看审核、实际出库、签收、退货与回款。首单若因缺货被取消，不应为了拉新业绩保留“已转化”标签。业务员把订单号与交付状态写回客户跟进记录，待客户收到货后询问规格、配送和售后体验，给下一次采购留下具体改进点。
用同一条客户链路核拉新成效，而不是只看注册数
主管可按同一批新开发门店建立四段漏斗：有可验证拜访记录、有唯一且获审核的客户身份、有明确当前负责人和可购买条件、有付费并完成实际交付的首单。每一段都留客户编号、发生日期、主责岗位和异常原因。若二十家拜访门店里十二家注册、十家通过审核、五家完成首单，不能直接断言业务员跟进不力；先看未注册的八家是否本就不适用，未审核的两家缺什么资料，已开通未成交的五家是否受价格、货盘、配送或资金条件阻断。复盘必须能回到具体客户，而不是只给员工看一张总转化率表。
首单考核还要同时检查订单是否有效、毛利是否合理、退款与欠款是否可控，以及客户第二次采购由谁维护。若门店首单靠大幅补贴、签收后又退货，名义成交对企业无价值；若客户由原业务员开发，首单时由客服帮忙操作，开发、成交服务和售后贡献也要区分。企业在政策里预先规定提成触发点、退货后的调整方式、员工调岗后的交接责任，再让系统记录提供核对依据。未经确认的奖金规则不能因为后台有“所属员工”字段就自动成立。
试点时选择一个区域、几名业务员与少量真实门店，分别测试管理端预建档、客户自助注册、旧客户归属调整和代客首单。正常案例要走到客户签收与下一次采购，异常案例至少覆盖重复建档、邀请链接与归属不一致、价格不可见、收货区域不支持、提交后取消或退货。每例检查是否能从客户编号回查来源、当前负责人、首单订单号和实际处理人；找不到某项证据，就补记录和规则，而不是靠主管事后口头认定。只有业务员离开、客户换联系人后，下一位同事仍能顺利接手服务和收款，归属与首单流程才算真正跑通。