LinkedIn加好友的对象、边界与节奏
加好友前先判断：这是不是正确的业务路径
连接请求不是“多一个联系人”的任务，而是一次低承诺的职业沟通。发送前你应能回答：目标公司实体是否正确？此人是否当前在职？公开职责和产品场景有什么交集？为什么现在是合理时机？如果对方接受，下一句具体要确认什么？任何一个答案不清楚，先研究而不是发送。
LinkedIn 连接不能代替同意、采购需求或授权。接受邀请只是建立一个平台关系，不应自动进入报价、样品或高频跟进流程。
用账户优先，不要用个人名单优先
先研究公司，再选择一个主路径。一个 Account 同时有 Buyer、Product、Sourcing、Quality 和 Owner 时，不代表应该全部添加；应按已核验场景选择最接近任务的一位，其他人只作为条件明确的备用路径。
| 当前目标 | 主路径候选 | 备用路径何时启动 |
|---|---|---|
| 确认新供应商入口 | Sourcing/Procurement | 主角色明确不负责或建议转介 |
| 确认品类/产品适配 | Product/Category | 产品节点说明采购路径 |
| 确认规格/认证 | Engineering/Quality | 已核验存在技术场景 |
| 确认订单条件 | Buyer/Purchasing | 已知或回复表明可进入执行端 |
| 小公司找负责人 | Owner/Founder | 无公开专业角色且场景明确 |
大型企业不能因为采购人没有接受就直接越级找 CEO；小企业也不能因为 Owner 是高层就假设他采购所有产品。
发送前的六项硬检查
□ 公司实体、官网业务和目标产品场景已核验
□ 个人资料公开显示当前在目标实体任职
□ 角色与本轮任务有至少一项公开相关证据
□ CRM 无同事正在联系的主路径，也无拒绝/离职/Stop 状态
□ 邀请备注只问一个职责或流程问题
□ 接受、无回应、转介、拒绝后的动作已预先定义“职位看起来像采购”“公司在某个国家”“对方认识很多人”都不能替代上述检查。不要通过私人资料、虚假共同关系或猜测供应问题制造邀请理由。
连接路径按相关性排序，而不是按方便程度
| 路径 | 适合何时使用 | 边界 |
|---|---|---|
| 公开的共同联系人引荐 | 引荐人同意且关系真实 | 不借共同关系施压 |
| 行业活动/公开讨论 | 真正参加同一活动或讨论同一议题 | 不把点赞当成合作意愿 |
| 公司与职责匹配 | 主体、角色、场景均已核验 | 备注只确认流程 |
| 官网公开业务入口 | 对方公布且用途合适 | 遵守该入口和当地规则 |
| 无上下文冷邀请 | 其他路径都不存在但研究充分 | 小批量，不做群发 |
先互动不是“养号技巧”。如果没有真实的行业观点或可提供的价值，不需要为了互动而评论；安静研究往往比泛泛点赞更专业。
节奏由质量信号控制，不由固定数量控制
没有适用于所有账户的“每日安全加好友数”。平台能力、邀请限制和用户反馈会变化；团队应根据账户提示、待处理邀请、重复触达、样本相关性和明确回复质量调整。出现异常时暂停，审查流程，而不是加大频率或更换账号。
| 观察到的情况 | 应做什么 | 不应做什么 |
|---|---|---|
| 新建账户研究队列 | 先完成六项检查，少量测试 | 一天导入/邀请大量陌生人 |
| 待处理邀请上升 | 暂停新增，按来源复盘 | 撤回后立即重发 |
| 接受后多数称不相关 | 修正角色和场景标准 | 换一段更强推的文案 |
| 出现平台提示 | 遵循官方指引并暂停 | 使用工具、换号规避 |
| 同公司被多人覆盖 | 合并负责人 | 同时让多名业务员测试 |
业务员的指标应奖励账户研究和明确路径，而不是单纯邀请数量。
接受后只延续原来的一个问题
对方接受连接后，先感谢，再回到邀请时的公开依据和唯一问题。若获得明确职责，再决定是否发送一页资料或联系被指向的团队；若没有回复，按团队节奏一次跟进后进入观察。
谢谢连接。此前我想确认的是：贵司 [明确品类] 的新供应商资料
通常由哪个团队先评估？如不属于你的职责，我会停止在这一方向打扰。不要因为对方接受就发送长目录、多个附件、价格表或会议链接。接受关系不是对营销内容的无限许可。
模拟案例：一家公司为何只先添加一人
以下为虚构案例。一家德国工业分销商官网展示过程设备。业务员在 LinkedIn 找到 Product Manager、Purchasing Manager 和 Managing Director。公开资料显示 Product Manager 的职责与产品组合最接近，Purchasing 只提到订单，Managing Director 无相关描述。
正确操作是先向 Product Manager 发送一条职责确认邀请，Purchasing 标为“若产品节点确认后再用”的备用路径，Managing Director 不联系。若 Product Manager 回复“由采购团队接收资料”，团队再由同一负责人转向 Purchasing。这样避免三人同时收到同一供应商信息，也让每一步有明确依据。
拒绝、无回应与状态更新
| 结果 | 记录什么 | 动作 |
|---|---|---|
| 接受并说明职责 | 明确原意、日期、下一节点 | 按许可继续一个问题 |
| 接受但无回复 | 当前没有新增事实 | 一次跟进后观察/关闭 |
| 指向同事 | 转介范围与目标角色 | 更新角色图，停止原路径 |
| 拒绝/不希望联系 | 明确边界与日期 | Stop，不换账号或渠道重试 |
| 资料显示离职/实体错 | 公开核验结果 | Stop，回到公司研究 |
任何状态更新都需要团队可见，避免后续成员把同一人当作新线索重新添加。
加好友操作检查清单
□ 从已核验 Account 选择唯一主路径，而非从个人名单批量添加
□ 当前任职、角色和产品场景均有公开证据
□ 邀请备注短、真实，只验证一个流程问题
□ 节奏受待处理、相关性和账户提示约束，不设盲目数量目标
□ 接受后不自动推销；只延续原问题并尊重回复
□ 无回应、转介、拒绝、离职都有可见的状态和 Stop 动作
□ 未使用自动化、虚假身份、私人数据或规避平台限制的方法加好友做得好，最终留下的不是连接数量，而是一张干净的账户关系图：谁已经核验、谁可联系、谁应停止，以及下一步为什么合理。
每月抽查一批已接受和未接受连接，核对是否都能回溯到同一套主体、角色和场景证据。不能回溯的记录应从活动队列移除，并用于改进下一次研究，而不是被重新包装后再次发送。
如果你想把「LinkedIn加好友的对象、边界与节奏」这一步继续落成流程，可以看看 客户开发 Agent，先判断它是否适合接住这段重复工作。查看适配方案
引用本文
引用时可保留文章名称、规范地址和页面记录的更新时间。