定制项目最容易失控的地方，往往不是你不会做，而是客户的需求在沟通中不断变化、关键决定散落在聊天记录里，最后每一步都要靠你临场补救。对一人公司来说，流程标准化不等于增加一堆管理工具，而是把高频决策和交付接口固定下来：什么客户值得接、什么算交付完成、需求变化怎么处理，以及每个阶段要留下什么记录。

先记住一个原则：每个阶段只设置一个明确的“过关条件”。条件满足，再进入下一步；条件不满足，就补齐信息、调整范围或暂缓承诺。你不需要为每个项目写一本手册，只要用一份项目主记录串起客户目标、范围、决定、交付物和待办。

先搭一套最小流程

单人执行时，可以先固定这七个阶段：

1. 线索筛选：判断项目是否值得继续沟通。
2. 需求确认：把客户想要的结果说清楚。
3. 报价与范围锁定：明确做什么、不做什么、如何验收。
4. 阶段交付：按约定节点提交可检查的成果。
5. 变更管理：区分范围内修改与新增工作。
6. 验收与回款：记录交付、反馈、确认和付款节点。
7. 项目复盘：把重复出现的问题变成下一次可复用的做法。

先用文档或表格跑通这条流程即可。工具可以后续再选；关键是所有项目都用同一套记录规则，而不是把信息分散在聊天、邮件和个人备忘录中。

1. 线索筛选：先判断是否适合接

不是每个有预算的询问都值得马上报价。你可以先确认四件事：

• 目标是否明确：客户希望解决什么问题？怎样算有改善？
• 决策链是否清楚：谁提出需求、谁确认方案、谁最终拍板？
• 时间是否可行：交付时间、反馈时间和你的工作安排能否对上？
• 合作方式是否匹配：客户是否愿意提供必要资料、集中反馈并确认阶段成果？

首次沟通不必做完整咨询。你可以先问：

这次项目最希望解决的问题是什么？如果项目完成，你会用什么结果判断它达到预期？谁负责确认需求和最终验收？

如果目标、负责人或时间安排仍不清楚，下一步应是补充沟通或缩小试做范围，而不是直接承诺完整项目。若关键条件长期无法确认，就把它记为暂缓或不接的原因。

过关条件：你能用几句话写出客户的目标、主要联系人、预期时间和目前缺少的信息。

2. 需求确认：把“想要什么”变成可执行描述

客户提出的通常是方案或愿望，例如“做得更专业”“增加转化”“帮我整理内容”。这些说法还不能直接作为交付标准。你需要继续确认目标用户、使用场景、现有材料、优先级和限制条件。

把需求整理成一页项目说明，至少包括：

• 项目目标与使用场景
• 目标用户或主要受众
• 已有资料、账号、系统或内容
• 主要交付物及其格式
• 优先级和必须满足的条件
• 客户需要提供的资料与配合事项
• 尚未确认的问题及其影响

重点是把事实、假设和待确认事项分开写。例如，“客户会在某日期前提供素材”是待确认的配合条件，不应默默当成已经落实的事实。若某项信息会影响报价、工期或方案，先标出来，并说明未确认时会带来什么变化。

过关条件：客户能确认项目说明中的目标、交付物和关键限制。若双方对“做好”的理解不同，先改写验收条件，而不是继续推进。

3. 报价与范围锁定：让承诺可以核对

报价不只是一个金额，也是一组合作约定。你可以在报价或项目说明中写清：

• 包含内容：具体交付物、数量、格式或服务环节。
• 不包含内容：容易被误认为默认包含的事项。
• 客户配合：需要提供的资料、反馈和确认。
• 时间安排：阶段节点，以及哪些节点依赖客户反馈。
• 反馈与修改方式：反馈由谁汇总、如何提交、哪些修改属于约定范围。
• 费用与付款安排：按双方确认的条件列明。
• 验收方式：交付什么内容、由谁检查、如何确认完成。

避免只写“网站制作一套”“内容优化一批”这类难以核对的描述。可以把它改成双方都能检查的交付物，例如“提交一份包含指定章节的方案文档”，并写明不包含的工作，例如后续持续运营或额外页面制作。

每个项目都应有一个确认版本。客户通过约定方式确认后，你再按该版本开始；后续讨论产生的新要求，进入变更流程，而不是悄悄写进原范围。具体合同条款、权利义务和税务处理，应按你的业务情况另行确认；这套流程不能替代合同、法律或财税专业意见。

过关条件：客户确认了范围、主要交付物、反馈方式和费用安排；你也知道哪些条件一旦变化就需要重新评估。

4. 阶段交付：让客户尽早发现偏差

如果项目周期较长，不要把所有成果都留到最后一次性交付。把工作拆成客户能检查、你能推进的阶段。例如，内容服务可以先确认选题框架，再交付初稿；开发项目可以先确认关键流程或原型，再进入完整实现。

每次阶段交付，尽量只附上三类信息：

1. 本阶段提交了什么；
2. 希望客户重点检查什么；
3. 需要客户在何时、以什么方式反馈。

让反馈集中在一个渠道或一份文档中，并指定一位汇总人。这样比同时追踪多人在不同聊天窗口里的零散意见更容易执行。收到意见后，把它整理成待办，并标明“已确认”“待确认”或“暂不处理”。

过关条件：当前阶段的成果得到明确确认，或未决意见已经列出负责人和处理方式，再进入依赖该阶段的后续工作。

5. 变更管理：先判断，再决定是否接

范围蔓延常常不是客户突然提出大改，而是一次次“顺便加一点”。所以你需要区分两类反馈：

• 范围内修改：针对已约定交付物的调整，且符合约定的反馈和修改规则。
• 范围变更：新增目标、交付物、使用场景、协作对象，或改变已经确认的方向。

收到新要求时，不要当场直接答应。先用四步处理：

1. 复述需求：确认你理解的新增内容是什么。
2. 判断影响：说明它对范围、时间或费用可能带来的影响。
3. 给出选项：例如替换原有事项、另排阶段，或暂不纳入当前项目。
4. 取得确认：双方确认调整方案后，再安排执行。

可以这样回复：

这项内容超出了当前确认的交付范围。我先评估它对时间和费用的影响，再给你一个调整方案；确认后我再安排进度。

如果客户只是在原范围内补充反馈，就按原规则处理，不必把每条意见都变成额外报价。关键是依据一开始确认的范围和修改约定判断，而不是凭当下情绪做承诺。

过关条件：每项新增要求都有明确结论：纳入原范围、替换已有内容、另行安排，或不处理。决定和确认记录在项目主记录中。

6. 验收与回款：不要让“发出去”成为结束标准

完成交付后，按事先约定的方式提交成果，并附上验收所需的信息：交付清单、文件或访问方式、需要检查的事项，以及尚未完成的依赖项。把客户的确认、反馈和后续修改需求分别记录，避免把“收到文件”误当成“验收完成”。

回款安排应沿用双方确认的报价或合同约定。你可以在项目记录中标注待开票、待付款或已完成等状态，并按约定跟进；不要等到项目结束才回头整理付款事项。若验收条件或付款安排需要调整，应先按适用的协议与专业意见处理。

过关条件：交付物清单、验收状态、遗留事项和款项状态都已记录；未完成事项有明确责任人和下一步。

7. 项目复盘：只改一个最值得修的环节

复盘不需要写长报告。项目结束后，留出一小段时间回答：

• 哪个环节最容易卡住或返工？
• 哪项信息本可以更早确认？
• 哪种反馈反复出现？
• 哪个范围边界最容易产生误解？
• 下次只改一个什么动作，就能减少重复沟通？

例如，如果客户经常在交付后才补充目标受众，下次就在需求确认阶段增加一项必答问题；如果修改意见分散，就在项目启动时说明反馈提交方式。把结论更新到模板中，而不是只记在个人印象里。

过关条件：复盘至少产出一个具体调整，例如修改问题清单、补充范围说明，或改变阶段交付方式。

单人可维护的文档清单

不必一开始为每个环节建独立系统。先准备以下四份内容，项目少时也可以合并到同一份文档中：

日常只需守住三个检查节点：

• 开始前：范围、负责人和关键条件是否已确认？
• 每次阶段交付后：客户反馈是否集中、决定是否留痕？
• 结束后：验收、回款、遗留事项和复盘是否完成？

从最容易出错的一处开始标准化

你不必一次把整套流程做得很完整。先回看最近几个项目，找出最常导致返工、等待或争议的环节，再为它加一个固定问题、确认节点或记录模板。流程是否有效，不看文档数量，而看它是否让客户需求更容易确认、范围变化更容易处理、交付结果更容易核对。

当你发现同一种问题在多个项目里反复出现，就把对应的解决办法写进模板。这样逐步形成的项目流程，通常比一开始搭建复杂的管理系统更容易坚持，也更适合一人公司的经营节奏。