社区记得每个人。CRM 至少别把人弄混

创业者社区很容易计数：多少成员、多少聚会。但保留有用的记忆难得多。谁认识谁？这人现在做什么？加入时写了什么？谁答应活动后继续聊？

我围绕这些区别建设 Founders Dubai 的 CRM。成员卡片不只是联系人列表的一项，而是连接原始回答、最新信息、活动和团队行动的档案。

下面是虚构 Founders CRM 成员的卡片：个人资料、公司信息和参与历史。它演示工作记录的组织方式，不提供社区数据库访问。

成员卡片

归档界面 · 演示数据

问卷不能事后改写

最初的回答与可编辑的当前信息分开保存。人可能换公司或工作方向，组织者需要更新档案，但这不意味着成员当初提交的就是新版本。

修改有历史和作者。支持的操作可以撤销，同时保留发生了什么的记录。这比笼统的“最后更新”字段更有用；后者只说明时间，却让所有人都能无辜地耸肩。

一个任务，三种视图

计划包含列表、看板和甘特图。很容易做出三个漂亮应用，然后逐渐各说各话。所以这些视图使用同一套任务和子任务。

同一个演示的任务在看板上打开。可以查看各阶段分布和可用的本地操作；真实团队任务不会被修改。

团队看板

归档界面 · 演示数据

通过私有 MCP 接口，可以从 ChatGPT 调用获准操作。日常语言的便利，到具体动作开始时就必须落实：任务要有正确项目、状态和权限。助手说“完成”本身不会向工作流程写入任何内容。

主应用使用 React 和 Vite，后端为搭配 D1 的 Cloudflare Worker。Telegram Mini App 为成员提供个人档案和有限功能。不能因为两个人打开同一个链接，组织者信息就变成共享信息。

同名不等于同一个人

生态中有独立服务和旧数据。名字或 Telegram 用户名相同，不足以自动合并两个身份。等到别人的历史出现在成员卡片上再发现问题，尤其令人不快。

因此，在系统间迁移功能和迁移人员是不同任务。可以复用经过验证的组件，而不连同他人的权限和信息一起导入。

组织者的流程从成员卡片开始，延伸到团队共享任务。问卷、最新信息和修改历史分别保存，避免新状态改写过去。本文展示的是演示记录，不是社区成员数据库。

相关故事：Founders Dubai 社区网站 · 工作室与共同工作。