卖出的和正在交付的,本是同一件事

卖出工作和完成工作,是同一段关系的两个阶段,而几乎每套工具组合都恰恰在最需要连续性的时刻——交接——把它们拆进两款产品。Cyril 把商机和交付放在同一张数据图谱上,所以项目从双方实际的约定开始,而不是从它的摘要开始。

两个模块,同一份档案

商机变成项目

在我们的演示工作区里,隼程物流签下了管理咨询项目。项目直接由商机创建,带着约定好的范围、团队和截止日期,交付进展从客户档案上随时可见。

  1. 1销售

    卖出的内容,只写一次

    商机中记录了范围、拟派人员,以及向隼程承诺的日期。

  2. 2项目

    项目由此开始

    阶段变更是同一张数据图谱上的一个触发器,所以项目一创建,就关联到它所来自的商机。

  3. 3客户

    在资金所在之处看到交付

    第二阶段标记为完成,财务随即起草发票。销售、交付和客户支持读起来是同一个客户。

2026年10月20日从商机带入项目

放在一个普通的周二,这意味着什么

  • 成交的商机可以直接创建项目

    自动化运行在数据图谱层面而不是产品之间,所以阶段变更就是一个触发器,生成的项目会关联到它所来自的商机。

  • 任务经由项目归到客户

    项目隶属于它所服务的客户,所以从客户点一下就能看到交付,从项目点一下就能看到客户。

  • 在资金所在之处,就能看到交付状态

    项目和发票隶属于同一个客户,所以“交付了什么”和“计费了什么”可以一并查到,而不是每月对一次账。

  • 一个问题,贯穿销售、交付和客户支持

    “本季度哪些客户有流失风险,原因是什么”需要销售管道、交付、工单和发票。Ask Cyril 依据您在这四方面的记录作答,并注明所读取的内容;横跨四款产品,这就成了某人在问题发生之后才去做的一张电子表格。

一个问题,跨越四个应用销售管道、交付、工单和发票,通过同一套权限模型读取。

两套独立工具的做法

两套工具的组合,正是在交接时漏水。承诺的内容存在 CRM 里,往往只是一条备注;要做的东西存在项目工具里,由一个当时不在场的人录入。这道缝隙通常靠一场启动会来弥合,而启动会的全部目的就是把商机大声再读一遍。之后两份记录逐渐跑偏,到续约时,不做一番考古,谁也说不清最初的承诺是什么。

这是否适合您

适合您,如果

您交付的正是您卖出的东西——服务、实施、常年顾问工作——而两者之间的交接靠的是一场会议,而不是一个关联。交付与承诺挨得越近,同一张数据图谱对您的价值就越大。

不适合您,如果

您的项目工作与销售管道无关——比如围绕产品路线图的内部研发——而您的项目工具在专业领域里做得很好。当工作本身没有对应的客户时,共享客户图谱带来的收益很小。

目前还做不到的事

Cyril 尚未正式上线,所以值得公布的是现有功能的边界,而不是路线图。如果其中某项是您的硬性要求,请尽早告诉我们,我们会坦诚告诉您是否值得等待。

  • 跨项目组合的资源平衡和产能规划,目前不应纳入规划。
  • 支持甘特图依赖关系,但关键路径排期和基线管理比专门的 PPM 工具单薄。
  • 完全自主的智能体项目管理即将推出,尚未发布——目前已有的功能会展示计划,并在执行前等待您的批准。

涉及的模块

两者都是平台的一部分,按席位统一计价——没有需要拼装的套件,也没有需要购买的连接器。下方每个页面介绍对应模块自身能做什么。

常见问题

这是完整的项目工具,还是轻量的附加功能?

基于同一批记录的列表、看板和时间线,具备任务、依赖关系和自动化。它刻意不做的,是一款自带客户副本的独立项目产品——这正是本页所反对的东西。

我们在用一款团队很喜欢的项目工具,这有问题吗?

没有问题,但请正视其中的取舍。保留它,就意味着保留交接的接缝以及维护这道接缝的一切。这很可能是值得的;只是这笔成本应当被明确说出来,而不是被想当然地忽略。

AI 能同时看到项目工作和销售管道吗?

能。Ask Cyril 依据项目、商机、工单和发票作答,注明所读取的记录,且只读取您的角色有权打开的记录,而不是查四个工具再由人工拼合结果。

另外两次交接

各模块如何协同

销售与财务

商机和发票,对应的是同一个客户

商机明细直接变成报价单和发票的 CRM。无需导出、无需重复录入,也没有第二份客户版本需要对账。平台内置,按席位计费。

销售与客户支持

工单早已知道是谁写来的

早已了解客户账户、进行中项目和未付发票的服务台——一次查询,而不是六次。同一个平台,同样按席位计价。

用您自己的数据看看

Cyril 尚未正式上线,正通过等候名单开放抢先体验。目前还没有自助注册,也没有公开的客户——如果您想知道它真实的进展,欢迎来问。

一个团队围坐桌旁一起做规划,一位同事在白板上画出计划