TASK 28 · 业务沟通
技术问题澄清与转交
把客户的技术与规格问题记录、转交专家、用可追溯来源回复，并更新知识库，避免销售凭印象回答。
问题 · PROBLEM
客户问规格、兼容或认证，销售凭印象回答或转发聊天记录；答案没有来源，前后不一致。
目标 · GOAL
建立技术问题闭环：记录问题、分类、转交专家、给出有来源的答案、确认客户理解、更新 FAQ 与资料库。
边界 · SCOPE
不提供未经确认的技术承诺；认证与合规声明需官方来源；复杂问题转技术团队。
常见输入
- 客户问题
- 产品资料
- 技术专家
- 历史问答
- 客户上下文
预期输出
- 问题记录
- 专家答复
- 来源链接
- 客户确认
- 知识库更新
风险边界 · RISK
高
本任务可能涉及个人信息、批量联系或对外发送。必须确认合法依据、平台规则、退订与投诉处理，并保留人工审核点；不要把自动化当作免责。
TASK BREAKDOWN
把任务拆成可执行的步骤。
步骤顺序不是唯一答案；它用于说明一项任务通常如何从证据走到输出，实际项目应按团队与市场调整。
- 01 记录
- 02 分类
- 03 转交
- 04 核对来源
- 05 回复
- 06 确认
- 07 更新
这个任务解决什么
技术问题回答错误，比不回答更危险。客户会据此做选型、设计或合规判断；销售如果凭印象承诺兼容性、认证或性能，后续交付和合同都会出问题。技术问题需要闭环：记录、找对人、给有来源的答案、确认理解。
最佳实践
- 记录客户原问题、应用场景、型号/版本和期望时间，不要只转一句“能不能用”。
- 按产品、兼容、认证、交付和售后分类，转给对应专家。
- 答案必须附来源：规格书、测试报告、官方文档或专家确认。
- 对不确定的问题明确说“需要确认”，不要用推测填空。
- 回复后确认客户理解，并把问答更新到 FAQ 或销售资料库。
- 高频问题应推动产品/文档改进，而不是每次重复问专家。
常见失败
- 销售凭印象回答，后续被技术团队纠正。
- 转发聊天记录，没有上下文和来源。
- 对认证或合规问题做未经确认的承诺。
- 问答不沉淀，同一问题反复出现。
衡量与边界
看技术问题响应时间、答案来源完整率、重复问题和客户确认率。技术沟通不提供未经确认的承诺；认证、合规和安全问题必须由官方来源或专业人员确认。
技术问题的答复应保留版本和日期，产品和认证变化后及时更新；无法确认时明确说需要验证，不要用推测填空。
SOLUTION COMPARISON
可选方案，按条件比较。
同一任务可能有现成 SaaS、自动化工作流或人机协作等不同路径。表格按技术门槛排序，不构成绝对排名；每个方案页都有更完整的限制、风险与核验说明。
| 方案 | 路径 | 技术门槛 | 部署 | 费用 | 核验 |
|---|---|---|---|---|---|
| 人机协作流程 / 自动化工作流 | 低代码 | 在线服务 / 混合 | 按量计费 / 订阅 | L1 · 已核对官方资料 | |
| API / 模型 / 工具组合 / 自动化工作流 | 需要开发 | 在线服务 / 自托管 | 按量计费 | L1 · 已核对官方资料 |
WHERE TO START
根据你的能力选择入口。
入门建议不是能力评级，而是降低第一次尝试的成本。先用小样本验证流程，再决定是否扩大自动化范围。
无需编程
适合一线从业者，先用现成产品验证流程。
当前没有发布在这一门槛下的方案；可先查看其他路径或方案索引。