为自由职业者打造的提案流水线应用：从草案到中标/失单

为什么提案会被忽视

大多数自由职业者并不是因为工作不够好而丢失提案。真正的原因是提案“消失”了。

常见的混乱看起来很熟悉：文档里有一个草稿，文件夹里有最终的 PDF，最后一次客户消息埋在邮件或聊天里，而唯一的“状态”就是你的记忆。在你忙于交付客户工作时，很容易忘记谁在等报价，谁需要再催一次。

提案常常散落在：

• 一个名为“Proposal v7 FINAL (2)” 的 Google 文档里
• 有三个不同主题行的邮件线程中
• 手机里的一个带跟进日期的笔记里
• 没有上下文的日历提醒里
• 你的脑子里（直到为时已晚）

提案被忽视的原因很简单：没有一个地方能显示下一步该做什么。如果你不能在 10 秒内回答“下一步我该做什么，针对哪个客户？”，跟进就会被拖延。拖延的跟进会变成失单，即便客户本来有兴趣。

这就是流水线的意义：一组清晰的状态，展示每个提案处于何处以及接下来应做什么。提案流水线应用并不是复杂的销售机器。它是记分板和待办事项的结合体。

把期望放低。你不是在构建带有预测、区域划分和你永远不会看的报表的复杂 CRM。你只需要一个轻量的工具，符合你实际的工作方式，让“下一步”变得明显。

这能防止的情况例如：你在周二发了一个网站改版报价并告诉自己周五跟进。周五忙碌了一天。到周一你记不得自己是否已经询问过。一个小小的流水线，只要有一个可见的“等待客户”阶段和明确的下一次跟进日期，就能阻止这种安静的损失。

轻量级提案流水线应具备的功能

提案流水线应用只有一个任务：以最少的额外工作，把每个提案从草案推到中标或失单。如果它增加了额外的行政工作，你会在最需要它的时候停止使用它。

在你设计任何东西之前，先决定即便几个月后你也必须知道关于某个提案的哪些信息。把字段控制在少数几个，能帮你跟进、预测收入并了解哪些服务更好卖。

对每个提案的实用最小信息集：

• 客户（个人或公司）和联系方式
• 服务类型（例如：网站改版、移动应用、月度 SEO）
• 估算金额（或区间）和预计开始日期
• 下一次跟进日期
• 当前状态（草拟中、已发送、谈判中、中标、失单）

然后定义什么算“完成”，以保证应用可信。提案不应该永远停留在“已发送”。“完成”意味着滞后的事项会触发提醒，收到回复后会记录结果，并且你能在不导出表格的情况下看到简单报表。

一开始把范围保持小。单用户、单工作区和简单字段胜过你永远不维护的大系统。如果你这周发了三个提案（两个是“落地页 + 文案”，一个是“常规维护顾问”），一个强制要求下一次跟进日期并记录结果的流水线，会很快显示哪类服务的成交率更高以及在哪些环节耗时。

选择符合真实工作流的状态

状态只有在反映你真实日常时才有用，而不是那种你不会遵守的理想流程。保持状态集足够小，让把卡片向前移动成为轻松的操作。

一个实用的状态集：

• 草拟中
• 准备发送
• 已发送
• 需跟进
• 谈判中
• 中标
• 失单

名称要简短且基于行动。如果读到某个状态你不知道接下来该做什么，就改名。

接着，设定一些简单规则，防止提案变成僵尸项。

例如：

• 在没有客户、服务类型、总价和交付时间窗的情况下，不能把提案移到“已发送”。
• “谈判中”应当意味着客户已回复并且范围、价格或条款正在变化。
• 标记为“中标”应当需要明确信号：签署的协议、已付定金或书面“同意”。

跟进日期是另一个防线。并非每个状态都需要提醒，但有些状态确实需要。一个稳妥的默认规则是：已发送和需跟进必须有下次跟进日期。谈判中也可以要求，但仅在下一步由你来执行时才需要。

一个快速情景：你在周一发出网站改版报价。如果周四还没收到回复，它会显示为“需跟进”。如果客户回复说“能不能去掉博客并降价？”，你把它移到“谈判中”，并将下一次跟进设在第二天。这样的结构足够保持推进，同时不会把工作流程变成文书活儿。

设计数据：客户、提案、服务、活动

提案流水线应用的成败取决于数据。如果结构太松，你会跳过字段；如果太严格，你会停止使用。目标是建立一套可信的小记录集，只有在真正需要时才加细节。

从四个核心对象开始：客户（Clients）、提案（Proposals）、服务（Services）和活动（Activities）。

核心表格（及其存储内容）

首个版本保持简单：

• Clients（客户）：名称、联系人、电子邮件、备注（可选：公司规模）
• Proposals（提案）：标题、client_id、service_type（或 services）、金额、状态、发送日期、下一次跟进日期、结果原因
• Services（服务）：名称（例如：“网站改版”、“SEO 审核”），可选的默认价格区间
• Activities（活动）：proposal_id、类型（笔记、提醒、电话、邮件）、时间戳、详情

对提案来说，next_follow_up_date 是你未来的保护网。outcome_reason 在你标为中标或失单时很重要，因为“失单：价格太高”与“失单：时间不合适”会导向不同的改进措施。

单一服务与多服务的取舍

每个提案只有一个服务类型是最快的设置，适合你销售清晰套餐的情况。若经常打包（设计 + 开发 + 维护），多服务更合适，但会增加复杂度，需要中间表（如 ProposalServices），并且让报表更难处理。

一个折衷是先用单一服务类型，只有当你确实遇到混合提案且报告复杂性会改变决策时再扩展为多服务。

活动记录让你无需翻邮件就能看到轻量历史。发出提案后，快速记录一句“已发 v2，客户询问时间线”。稍后你一眼就能看懂进展。

规划界面：看板、列表、详情、报表

如果每个界面都能回答一个明确的问题，提案流水线应用只需要几个界面。目标是速度：打开它，看到需要关注的事项，做一次更新，继续工作。

流水线看板（每日视图）

这是你每天常驻的界面。每列代表一个状态。每张卡片应展示足够的信息以决定下一步：

• 客户名称
• 提案金额（或预计月度维护费）
• 下一次跟进日期
• 服务类型标签

快速操作比完美布局更重要。从卡片上（或小弹出详情）你应该能更改状态、设置跟进日期、添加笔记，并在不填写长表单的情况下标记中标或失单。

提案列表（搜索与回顾视图）

看板适合流程，列表更适合查找。用表格风格的列表并提供筛选项，如状态、客户、服务类型和是否逾期跟进。当一周很忙时，这里是你的“回顾”视图。

详情页（快速编辑，而不是繁琐文书）

你只需要两个详情页：提案页和客户页。

提案页用于时间线（笔记、状态变更、下一次跟进）以及关键字段如金额和服务类型。客户页保存上下文：联系信息、当前提案和近期活动。

如果更改跟进日期需要 30 秒，你就不会频繁更新。优化这些页面以便一键编辑。

简单报表（单屏）

一份轻量报表起步就够：按服务类型的成交率和平均成交时间。它应回答两个问题：“我该多卖什么？”和“交易在哪儿停滞？”。

从零构建到可用

一个可用的提案流水线应用并不是“完整 CRM”。它应该告诉你哪些是活跃的、哪些被卡住，以及今天你该跟进谁。

当天可用的第一个版本

从数据模型和几条测试记录开始，以便你能测试流程。创建一个客户、两个提案和至少两种服务类型（例如“网站改版”和“持续 SEO”）。

然后构建两个核心界面：一个按状态列出的看板（Pipeline）和一个提案详情表单。看板用于日常扫描，表单用于准确更新。

一个让你持续前进的构建顺序示例：

• 模型：Client、Proposal、ServiceType、Activity
• 界面：看板视图 + 提案详情表单（状态、金额、发送日期、下一次跟进）
• 规则：在关键字段缺失时阻止状态迁移（例如已发送需要发送日期）
• 提醒：在到期跟进时通知（可选在提案首次变为已发送时通知）
• 仪表盘：按状态计数和按服务类型的成交率图表

添加“无法前进，直到……”的检查

这是让应用可信的关键。

示例：你把提案从草拟拖到已发送，但如果没有客户邮箱或提案金额，应用会阻止你。那点小摩擦可以防止日后数据混乱。

一个默认规则能阻止大多数漂移：每个未结提案必须有下一次跟进日期。如果缺失，在看板上显示警告。

一个可用性的简单定义：

• 在 60 秒内可以添加一个提案
• 一眼就能看到今天该跟进谁
• 状态变更保持一致（没有半发送的提案）
• 可以按服务类型看到成交率
• 当你已在跟进时，提醒保持安静

基于状态的提醒而非打扰你的通知

当提醒与流水线中的明确节点关联时效果最佳，而不是随机的日历提醒。如果应用知道当前状态，它就能只在提案可能变得陈旧时提示你。

你不需要很多触发器。一个简单设置如下：

• 当提案变为已发送时，要求设置跟进日期。
• 在跟进日期当天发送一次提醒。
• 如果在已发送状态 X 天后仍无回复，自动创建跟进任务。

把提醒文本保持简短并面向行动，仅包含对象、主题和下一步：

• "跟进 {Client}：{Proposal} — 快速确认"
• "{Client} / {Proposal} — 询问是否需要在批准前做改动"
• "{Client} / {Proposal} — 确认时间线与开始日期"

添加保护机制，避免它变成噪音：对每个提案每天最多一条提醒，并提供稍后提醒选项（1 天、3 天、下周）。

也要记录每条提醒的处理结果：完成、延后（到什么时候）、跳过或已发送。

示例：你在周一把“Website refresh - Acme Co”标为已发送，并把跟进定在周四。周四早上一条提醒弹出，你把它延后到周五。周五你跟进并把提醒标为完成，于是“X 天无回复”计时器重置。

按服务类型跟踪成交率并据此行动

提案流水线应用只有在能帮你决定下一步时才有价值。最简单的方法是按服务类型跟踪成交率，而不是只看总体。“网站改版”和“月度维护”往往像两门不同的生意。

首先，使结果一致：

• 中标 意味明确的肯定（签署协议、已付定金或确认开始日期）。
• 失单 意味你不再追踪它（他们明确拒绝、选择了别人，或长期无回应到可以断定该案已死）。

选择一个规则并坚持，否则数据会变得噪声。

保持失单原因简短且一致：

• 价格
• 时间安排
• 范围不匹配
• 无回复
• 选择竞争对手

然后在你实际使用的时间窗口（最近 30 或 90 天）计算每种服务的成交率。例如在 30 天内发了 12 个“品牌策略”提案，赢了 3 个，那就是 25% 的成交率。你不需要完美，只要稳定。

再加上“成交时间”指标，保持自检。记录从已发送到中标或失单所需的天数。你可能会发现“SEO 审核”通常在 5-10 天内成交，而“全站重建”需要 30-45 天。这会改变你跟进频率和收入预测的方法。

让数据可执行：如果某服务的成交率低且成交时间长，缩小首阶段范围（scope）、提供更多证明材料或提高筛选门槛。如果某服务的成交率高，就保护它：复用有效做法并谨慎提价。

构建提案 CRM 的常见陷阱

把工具做得令人困惑是让它变得无用的最快方式。自由职业者通常怀着好意开始，最后得到一个他们不信任的工具。

一个陷阱是状态太多、但含义相同。如果你无法用一句话解释“已发送”、“已提交”、“已交付”和“审核中”的区别，那么你很可能只需要其中一个。

另一个陷阱是让“已发送”变成坟场。如果你不要求跟进日期，打开看板时会看到一堆没有下一步的提案。一个简单规则即可修复：每个已发送的提案必须有下一次行动计划。

其他会悄悄破坏专注力的错误包括：

• 把潜在客户与提案混在一起，使流水线变成杂乱收件箱
• 不记录失单原因，导致你重复犯定价与范围的错误
• 过早过度自动化，花更多时间调试提醒而不是发提案

让提醒保持无聊且具体。通常一条与跟进日期绑定的提醒就够了。更多规则可以等你有一个月的真实使用数据再添加。

如果你连续丢了三个提案，注释都写着“时间太长”，那说明你该提供一个更小的首阶段项目，而不是增加五个新状态。

在依赖它之前的快速检查表

在把提案流水线应用当成唯一可信来源之前，确保没有东西处于停滞状态且下一步显而易见。

打开流水线视图并计时。你应在 30 秒内看懂今天的优先事项。如果你必须点开多个提案才能找到下一步，说明你的设计把最重要的字段藏起来了。

检查表：

• 每个打开的提案都显示明确状态和下一次跟进日期。如果没有下一步，就把它关闭。
• 你的“今天”视图展示可以立刻执行的动作（跟进、发送、修订），而不是一堆压力清单。
• 标为中标或失单时，记录最终金额和简短原因。
• 在你常用的时间窗（30-90 天）内可见按服务类型的成交率。
• 提醒可以延后，且同一提案不会在同一天收到重复提醒。

做一个小压力测试：创建三个不同服务的示例提案，把它们在状态间移动并触发提醒。如果你能在五分钟内把它搞崩，繁忙时你也会崩。

示例：一周内的简单提案流程（以及你会学到什么）

周一你发出五个提案。三个是网站改版套餐，两个是月度支持顾问。所有提案从草拟开始，邮件发送后进入已发送。

到周三，状态会讲故事：

• 两个改版提案变为已查看（你看到客户打开了文档）
• 一个改版提案仍然是已发送（未查看）
• 一个顾问提案变为谈判中（他们要求调整工时）
• 一个顾问提案中标（已签）

提醒防止你掉链子。“已查看但 2 天内无回复”规则会提醒你在周五上午跟进那两个改版线索。“已发送但 3 天未查看”规则会捕捉到那个静默的提案，于是你重新发送并写一段更短的消息并给出明确下一步。

现实是混乱的。某位客户在周日迟来回复说“抱歉，忙了一周”，并要求下个月再开始，于是你把它移到“暂缓”而不是让它在已发送中腐烂。谈判仍然激活，但提醒仅检查一次，而不是每天都催。

到周末，按服务类型的成交率会让你惊讶：支持顾问 1/2 中标，网站改版 0/3。下周你会改变一件事：把改版范围收紧为两个层级，并增加一个简短的反馈截止日期。

下一步：先发布小版本，再逐步改进

最快获得价值的方式是发布那个你每天都会打开的最小版本。提案流水线应用第一天不需要模板、复杂自动化和各种图表。它需要告诉你：我发了什么、哪项在等、我接下来该做什么。

把状态设置为每个状态都能回答一个简单问题：现在期望做什么？如果你不能用一句话解释某个状态，它只会拖慢你。

本周可执行的三件事：

• 设定 5 到 7 个状态（通常草拟中、已发送、需跟进、谈判中、中标、失单就足够）
• 建立一个看板视图，让你能在几秒内把提案在状态间移动
• 仅为重要场景打开提醒（需跟进，以及当下一步由你执行时的谈判中）

当基本循环变得自然后，再逐步改进。一个好的优先顺序是先完善提醒（避免遗漏），然后是报表（帮助你学习），最后是模板（节省时间）。如果一开始把所有功能都加上，你就不知道哪些改变真正有用，哪些只是噪音。

把第一个版本当作个人工具而不是产品。如果记录新提案或推进一条提案花费超过 30 秒，先简化字段和界面再添加新功能。当它变得毫不费力，你才会真正使用它，数据才会保持可靠。

如果你想在不大量编码的情况下构建它，AppMaster (appmaster.io) 是一个实用选项：你可以在一个地方建模数据库（客户、提案、服务），并构建界面和状态规则，然后随着流程变化迭代。

把升级小而可测量。一周后问自己：我跟进得更快了吗？错过的回复更少了吗？一个月后问：哪种服务成交最好？哪种需要更好的报价或更高的价格？

把第一个版本当个人专属工具：只要记录新提案或推进提案不超过 30 秒，就继续添加；否则先简化。在它变得轻松时，你才会一直用，数据才会可靠。