惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

A
About on SuperTechFans
D
DataBreaches.Net
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
V
Visual Studio Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
B
Blog RSS Feed
Recent Announcements
Recent Announcements
The Register - Security
The Register - Security
S
Secure Thoughts
Y
Y Combinator Blog
The Last Watchdog
The Last Watchdog
L
LINUX DO - 最新话题
V2EX - 技术
V2EX - 技术
腾讯CDC
GbyAI
GbyAI
G
Google Developers Blog
博客园 - 司徒正美
博客园 - 三生石上(FineUI控件)
T
The Exploit Database - CXSecurity.com
T
Threat Research - Cisco Blogs
P
Proofpoint News Feed
Schneier on Security
Schneier on Security
Microsoft Security Blog
Microsoft Security Blog
Jina AI
Jina AI
WordPress大学
WordPress大学
aimingoo的专栏
aimingoo的专栏
MyScale Blog
MyScale Blog
Help Net Security
Help Net Security
K
Kaspersky official blog
P
Privacy & Cybersecurity Law Blog
www.infosecurity-magazine.com
www.infosecurity-magazine.com
AI
AI
MongoDB | Blog
MongoDB | Blog
Scott Helme
Scott Helme
J
Java Code Geeks
Engineering at Meta
Engineering at Meta
H
Heimdal Security Blog
H
Help Net Security
D
Darknet – Hacking Tools, Hacker News & Cyber Security
云风的 BLOG
云风的 BLOG
Microsoft Azure Blog
Microsoft Azure Blog
S
Security Affairs
TaoSecurity Blog
TaoSecurity Blog
The GitHub Blog
The GitHub Blog
Hacker News: Ask HN
Hacker News: Ask HN
Martin Fowler
Martin Fowler
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Project Zero
Project Zero
T
The Blog of Author Tim Ferriss
Last Week in AI
Last Week in AI

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
7000 字长文浅拆 aPaaS
Artisan · 2023-07-10 · via 人人都是产品经理

本篇文章将从基础能力、产品特色两个关键层面对 aPaaS平台进行分析。作者以 Salesforce、纷享销客、明道云三个平台为主要例子,对比三个平台的特色能力,能给产品设计的伙伴们提供一些设计参考,希望能对你有所启发。

当前 SaaS 产品面临一个矛盾,即“小客户续费率低、大客户定制化程度高”。

另外,小客户与大客户在 SaaS 产品的需求点上又是不同的。就拿我比较熟悉的 CRM 中的 L2C 部分为例,小客户更多聚焦于 L(线索),希望通过一套CRM 系统为其带来更多的销售线索。

而大客户聚焦于 L2C 流程的信息化管理提效,希望通过一套系统将已经很成熟的线下流程固化到系统中,做到更流畅更大范围的协同从而促进公司整体效率的提升。

因此在我看来,SaaS 产品未来发展的两个大方向:

  • 以细分方向切入打造标准产品做 PLG。
  • 上探大客户市场做信息化赋能。

而对于想要上探大客户市场的 SaaS 公司而言,在标准产品能力的打磨外不可避免的需要应对大客户的定制化需求,更不用提在我国经济中起到重要支柱作用的国企客户了。

这个问题目前看来的唯一解法就是 aPaaS。

一、aPaaS 概述

对于 aPaaS 产品而言,核心的三大板块即对象、流程、权限层层递进:

  • 通过「对象」抽象业务实体,是一切 B 端产品通过数据流与信息流赋能业务的基础。
  • 通过「流程」连接「对象」、创建「对象」间的对应关系实现数据流与信息流的自动化。
  • 在设计 B 端产品时通常以“上帝视角”将全部「对象」和「流程」大而全设计,最后通过「权限」控制 B 端产品中各个用户角色的可见及可操作范围。

通过这三大板块的低代码甚至无代码快速配置具备定制化能力,以在产品层面吸引更多大客户。同时尽可能的降低定制成本,从而给 SaaS 公司带来更大的营收。

二、本文目的

下面通过对比目前行业内具备优秀 aPaaS 能力公司的相关产品,以 aPaaS 三大核心板块的维度,浅层面做一个拆解。

本文结构:先介绍基础能力、再介绍各家的特色能力、在文末附上拆解产品的在三大板块能力的对比表格。

通过满足基础能力,则完成了一款 aPaaS 产品的基本设计思路。而各家特色能力则是基于对用户需求的深刻洞察、为了更好的满足用户需求的差异化设计。

三、产品清单

本次拆解选取了三款优秀的 aPaaS 产品,分别是「Salesforce」、「纷享销客」、「明道云」。另外还有不少优秀的 aPaaS 产品,由于没有体验账号只能欠奉。

四、基础能力

1. 对象

对象的底层架构分为两大层级,底层对象数据与上层对象展示:

  • 底层对象数据由对象参数和字段参数两个模块组成。对象参数指的是这个业务对象(比如商机)自身的参数、对象参数指的是对象内字段的参数(单选、默认值等等)。
  • 上层对象展示由布局和三大页面展示构成,其中三大页面展示关联布局。布局包括布局数据、业务类型数据以及布局规则,布局数据为布局本身的数据(该布局适用于哪种场景),业务类型数据(同样是商机,市场和销售看到的布局则不一样),布局规则为该对象的详细布局规则(字段位置、展示与否等)。同时,由于 B 端信息系统绕不开三大页面(新建页、列表页、详情页),因此做单独抽象,而后与布局做关联。
  • 而对象的两层架构受权限赋予的用户角色所控制,用户角色 + 对象数据 + 对象展示 = 每个用户在每个场景下看到的页面。

对象的基础能力分为两大板块:列表和详情页(编辑页和新建页属于详情页的特殊场景设计)。

① 列表基础能力包括场景视图、检索能力、查重能力:

  • 场景视图:通过对对象内未来将要包含数据按照预设场景分类,为不同用户划定不同的数据展示边界。
  • 检索能力:列表页自定义检索功能。
  • 查重能力:系统要具备在用户录入数据时根据预设逻辑检索当前系统内是否存在重复数据的能力。

② 详情页基础能力包括字段编辑器、布局编辑、字段关系:

  • 字段编辑器:包括字段组件库(基本字段组件、高级字段组件)、默认值(包括公式计算)、数据验证(是否必填、长度等)、属性(只读/编辑)等。不同的字段组件由于其性质不同,需要包含不同的编辑项。
  • 布局编辑:分为内置布局编辑和外置布局编辑两种。内置编辑即编辑功能内置在对象的表单编辑环节,外置编辑则单独抽象出布局编辑功能独立于字段编辑。两种编辑方式各有优劣,内置编辑在布局设计或后期变更时体验更加友好,而外置编辑则通过将布局编辑功能独立抽象进而提供了较强的扩展性(支持不同角色、场景使用不同的布局方案)。
  • 字段关系:包括字段的显隐/关联关系(例如:当字段 A 不为空时显示字段 B)以满足级联递进场景。

2. 流程

流程的基础能力分为数据处理流程和审批流程两种,在数据处理流程中存在审批场景,而在审批流程又可作为数据处理流程的触发器,因此两种流程存在相互调用关系:

1)数据处理流程包括四类基础能力,触发、数据、逻辑、通知,通过数据处理流程编辑器完成设计

① 触发基础能力包括表单触发、逻辑触发、时间触发、API 触发:

  • 表单触发:通过用户在预先设计的表单中填写相关数据触发流程。
  • 逻辑触发:当对象中数据满足预先设计的逻辑时触发流程。
  • 时间触发:当达到预先设置的时间或时间周期时触发流程。
  • API 触发: 通过 API 触发流程。

② 数据基础能力包括数据的增、删、改、查:

  • 增:在对象或对象的字段中增加数据。
  • 删:在对象或对象的字段中删除数据(在实际产品设计中一般为假删)。
  • 改:在对象或对象的字段中修改数据(在实际产品设计中需记录修改日志)。
  • 查:在对象的字段中查询数据,是「删」和「改」的必要基础、「增」的非必要基础。

③ 逻辑基础能力包括赋值、判断、循环、暂停。

④ 通知基础能力包括站内信通知、三方应用集成通知、API 通知:

  • 站内信通知:在 aPaaS 平台内部完成通知,除非 aPaaS 平台具备协同能力,不然使用场景极大受限。
  • 三方应用集成通知:集成到目前常用的协同工具中,诸如企微、钉钉、飞书、微信(需配合移动端和小程序/公众号)等。
  • API 通知:用于提供与客户自研系统的集成能力。

2)审批流程按照审批时间线分为三个阶段,审批前、审批中、审批后,通过审批流程编辑器完成设计

  • 审批前:在审批流程开始以前的操作,如审批人是谁。
  • 审批中:在审批流程进行中的操作,如发起人操作(是否可撤回/催办)、自动通过机制、审批人操作(通过/拒绝/转审/待定)、审批人权限(当审批人与发起人所拥有数据权限不一致时,审批人在审批时的数据可见范围)。
  • 审批后:在审批流程结束之后的动作,如消息通知机制、审批后动作(又要调用数据处理流程的基本能力)。

3. 权限

权限功能的核心思想在于“分级管理”,横向两级 + 纵向三级架构,以此切割所有管理职责,做到可插拔可复用:

  • 横向:功能权限、数据权限。功能权限控制用户是否可以对数据做增删改查操作、数据权限控制用户是否对该数据可见。在数据权限内部继续分化全部数据权限、组织内数据权限、数据共享,以体现数据之间不同的继承关系。
  • 纵向:前台、后台、超级后台。前台权限控制了用户的权限边界,后台权限控制了各个系统管理员团队的权限边界,超级后台权限控制了整个系统的权限。

通过抽象角色(功能权限)、岗位(数据权限)、管理角色、分管小组四个模块,在以上模块的基础上关联员工实现高度灵活以支持人员的快速迁移。

在功能设计时,在上文基础上考虑到需要控制的功能模块、业务对象、对象字段、流程等数据众多且还需分别控制可见和可编辑。以单个权限(字段的只读/编辑为颗粒度)、单个自然人,二者组成了权限控制的基础。

在实际权限功能设计中,考虑到用户体验,通常还会在基础之上做进一步的包装,诸如权限组、用户角色等。

看起来十分简单,但是权限系统设计在 aPaaS 产品中却是最复杂的。由于本人对权限系统的了解并不深入,因此对于下面的分析可能会非常浅,望各位读者见谅。

五、产品特色

1. Salesforce

1)对象

① 强大的对象编辑器

对于「Salesforce」的对象部分,其实特色确实不多。一方面是由于对象作为 aPaaS 三大板块的基础,本身可做的新鲜功能就不多;其次以「Salesforce」的行业地位和发展时间来看,其成为了众多 aPaaS 平台的参考对象,导致整个对象相关功能趋于同质化。

初步体验,「Salesforce」的对象功能是非常“难用”的,体现为设置项众多且十分复杂,再加之其在我国缓慢的运行速度(这样大体量的系统估计在海外使用也谈不上轻快),但是客观来讲「Salesforce」的编辑器是十分强大的。通过对象编辑器,你几乎可以 100% 的完成你对于对象的设计构想而无需根据系统的功能边界“削足适履”。

聚焦于产品层面,「Salesforce」的对象编辑器除了拥有基础能力外,还支持筛选器配置、搜索布局、自定义按钮、列表和详情页的布局等。

尤其是布局编辑器,除了支持完全定制对象详情页的功能及布局外,还支持创建不同的页面布局以适配不同场景(比如根据营销团队、销售团队、客服团队的业务需求和数据隔离需求创建不同的商机布局)。

但是应当指出的是,「Salesforce」的对象编辑过程及其不友好,无论是字段的配置还是布局的配置均没有采用图形可视化的交互,这对于系统搭建人员来讲是一个不够友好的点(或许对于「Salesforce」来说,系统的搭建者都是实施团队或认证系统管理员,不存在业务人员自行搭建的场景)。

2)流程

① 极其强大的流程引擎

「Salesforce」在流程部分则非常具有特色,通过对流程元素接近“代码级”的抽象,使其几乎可以完成日常工作中的绝大多数流程设计。但问题就是其易用性较低,从网络上大量的教程和培训课程就能可见一斑。

「Salesforce」除了审批流,目前还有 6 大流程,分别是屏幕流、记录触发流、计划触发流、平台事件触发流、自动启动流(无触发器)、记录触发的业务流程。

下面分别介绍:

  • 记录触发流:先介绍「记录触发流」,它是其他流程的基础。当对象中的数据增删改时被触发,运行预设的流程。
  • 屏幕流:在「记录触发流」的基础上增加「屏幕」和「回滚记录」组件。「屏幕」组件可被理解为一个表单,支持用户通过填写一些信息而触发预设流程。
  • 计划触发流:在「记录触发流」的基础上增加根据预设时间或预设频率触发的能力。
  • 平台事件触发流:在「记录触发流」的基础上增加根据平台事件触发的能力。「记录触发流」也可以理解为被某些事件触发,只不过和「事件触发流」本质的区别在于,触发「记录触发流」的事件局限于该流程关联的对象的内部;而触发「平台事件触发流」的事件为该流程关联对象的外部、平台的内部。
  • 自动启动流(无触发器):一个无触发器的「记录触发流」,当接到 Apex 或 API 的指令后触发。
  • 记录触发的业务流程:与上述「记录触发流」及其衍生流程不同,「记录触发的业务流程」类似阶段推进流程,当被预设动作触发后跳转到下一个阶段,以将用户线下的阶段性流程线上化。

② 变量资源带来更多可能

变量资源是「Salesforce」流程中非常重要的板块。

在这里的“变量”与「Salesforce」定义的“变量”不同。在「Salesforce」中,变量只是资源的一种,与其并列的还有常量、公式、选项等;这里所说的变量可以理解为「Salesforce」的全部资源,都可以理解为宏观的变量。变量的意义在于有两点,即“输入到变量暂存”和“从变量输出赋值”。

在「Salesforce」中,每新建一个元素就会被视为一个资源,方便系统搭建人员随时修改各个元素的默认值;同时支持手动创建资源,为流程的构建创造更多的场景(比如计数、复用选项、数据桥接等)。

③ 丰富的模板生态

如前所述,强大的流程引擎和变量资源概念的引入只是基础,加之「Salesforce」的生态能力,在「Salesforce」和「appexchange」中可以找到丰富的流程模板,其中不乏很多大厂出品。

这将带来三个好处:

  • 通过对现有模板的适配性修改,可以让系统管理员以更快的速度完成功能的搭建。
  • 现有模板中不乏很多高评分的“最佳实践”模板,为用户带来更大的价值。
  • 「appexchange」为流程开发者提供平台、为用户提供流程模板与“最佳实践”、为「Salesforce」造就了繁荣的生态实现了更大的规模效应,最终都会不断提高「Salesforce」的 NDR,在这个三边关系中取得了共赢。

3)权限

① 权限集&权限集组二次包装

「Salesforce」在单个权限的基础上做了两层封装,分别为权限集和权限集组,权限集包含多个单个权限、权限集组包含多个权限集。

在权限集组中,各个权限集的权限共享,属于“自下而上”的权限控制。

举一个应用场景的例子,比如某大型销售团队在业务上面向大中小客户划分三个团队,在对象和流程上就可以遵循“大而全”的思路取并集设计、在权限配置时为三个团队单独配置权限。

而此时,存在一个业务支持小组,为三个小组提供就技术和资源上的支持。那么则无需重新为该业务支持小组重新配置权限,而只需将三个小组的权限打包为权限集组赋给业务支持小组。

2. 纷享销客

1)对象

① 支持对已有对象或对象内字段名称做修改

客户的个性化需求不仅局限于业务对象和流程的再造,还有较大比例是让现有业务对象和流程与客户组织内的习惯做适配。在客户的组织内,已经习惯了管「线索」叫「潜在客户」、管「商机」叫「销售机会」,我们没有必要一定让客户为了我们的产品而修改组织内已有的工作习惯,尤其对于大客户而言。

而「纷享销客」的所有对象以及对象内的字段是以 ID 作为唯一值的(在功能搭建时也可以根据开发者的习惯自定义 ID),将现有对象或对象内字段与客户修改后的名称再做一次关联并不会影响系统功能,成本也并不高,但是却能极大地提升用户体验。

② 具备 CRM 特色和本土化的字段组件库

除了具备 aPaaS 平台较为常见诸如文本(单行/多行/富文本)、数字、选项(单选/复选)等基础字段组件外,作为 CRM 产品还支持了很多非常具有 CRM 特色和本土化的字段组件,比如签名字段、支付组件、签到组件、地区定位等。

通过这些组件能够很好的满足 CRM 的用户场景,比如使用签名字段可以实现业务人员提交客户合同审批时通过系统签名确认的场景、使用支付组件可以实现组织上下游订货支付场景(也契合了「纷享销客」“连接型 CRM”的产品定位)、使用地区定位可以实现监控销售人员做客户拜访的场景(实现 CRM 的“销售过程赋能、销售结果管理”理念,关于这个话题以后再说)。

③ 支持打印模板功能

在「纷享销客」中支持企业自定义各种单据的打印模板。对于组织发展时间较长、信息化程度较低的大客户或零售、物流、仓储等较为依赖纸质单据管理的行业来说来说,这一功能能够使其在不对当前管理方式做大调整的情况下平滑无感的过渡到信息化管理。

2)对象

① 具象本土化特色实践

「纷享销客」在前文的对象部分就非常具有 CRM 和本土化特色,而在流程方面同样如此,通过多层级具象实践,以便业务人员经过简单培训后快速搭建。

在流程基础能力上具象出 4 种流程(审批流程、业务流程、工作流程、阶段推进器),利用「Salesforce」的流程 + 对象同样可以实现上述 4 中流程,但是其难度超乎一般业务人员能力范围。

流程具象关系(即用「Salesforce」实现同等功能)如下:

  • 纷享销客,审批流 = Salesforce,批准过程。
  • 纷享销客,业务流程 = Salesforce,屏幕流。
  • 纷享销客,工作流 = Salesforce,记录触发流 ∪ 计划触发流。
  • 纷享销客,阶段推进器 = Salesforce,记录触发的业务流程 ∪ 屏幕流 ∪ 记录触发流 ∪ 计划触发流。

② 连接型 CRM

除了将实际业务中常用的诸如短信通知、发送邮件具象进流程动作中以外,结合「纷享销客」的协同和“连接型”能力,流程中的动作可以通过「企信」协同或发送到其他应用中(如「订货通」、「代理通」等)。

3. 权限

1)连接型“权限”

「纷享销客」的权限部分可配置部门内数据权限和数据共享,其具备两大场景:

  • 公司销售团队下分为三个小组,可将三个小组需要共享的数据,通过配置部门内数据权限和数据共享完成权限的拉齐。
  • 聚焦于「纷享销客」的“连接型 CRM”产品定位,如果客户将自己的上下游也加入到「纷享销客」中,即可通过配置内部数据权限和数据共享完成对于上下游多租户的权限管控。

3. 明道云

1)对象

① 完全视觉图形化的优秀体验

「明道云」和无论是「纷享销客」还是「Salesforce」相比都有较大的差别,前者定位为轻量化的 aaPaaS 平台,仅提供基础能力;而后两者都是老牌 CRM 大厂,aPaaS 能力只是在发展到一定阶段后的产物。不仅如此,后两者在产品理念上更加偏向于“传统派” aPaaS 产品(更加传统的产品国内还有「泛微」、国外还有「SAP」等),而「明道云」这种“创新派”产品则更加轻量化,聚焦“业务人员快速搭建信息系统”理念。

据此,在「明道云」的对象/场景试图创建和编辑的过程中,都采取了完全视觉图形化的方式。即便「纷享销客」和「Salesforce」在很多地方也采用了视觉图形化的方式,但是整体的使用体验上「明道云」还是非常优秀的。

② 积极拥抱 AI+aPaaS

之前和朋友讨论过在 AI 时代 SaaS 行业未来发展,主要的争议点在于“AI 颠覆 SaaS 论”和“AI 赋能 SaaS”论。我个人的意见还是“AI 赋能 SaaS 论”,具体到落地就是通过 AI 辅助业务人员完成 aPaaS 平台搭建。

坦率的讲,“扩展性”和“易用性”是天平的两端(这一点在后文的流程方面体现的尤为明显),国内诸如「明道云」之类的 aaPaaS 平台的产品厚度总体是不足的,可扩展性其实远不如「纷享销客」和「Salesforce」,但也带来了极佳的易用性,可以做到业务人员依靠帮助手册即可完成对于相对复杂信息系统的搭建。

未来通过 AI 辅助业务人员搭建,一方面能够提高业务人员搭建的信息系统的质量,同时也为 aPaaS 平台向高扩展性方向迭代提供了空间。

回到主题,「明道云」提供了「AI 字段建议」功能。根据体验,虽然目前所提供的字段数量并不全、且不包含字段的详细配置,但仍然可以说是朝着 AI+aPaaS 的方向迈出了坚实的一步。

2)流程

① 搭建过程十分简单

不同于「Salesforce」和「纷享销客」以 CRM 为基本盘、将 aPaaS 平台作为适应用户需求的业务定制平台,「明道云」定位纯 aaPaaS 产品,其流程聚焦于用户在平台内部创建的各个对象(也可以理解为数据表),使得其灵活度极高,各种流程可使用的元素完全一致。

同时得益于出色的交互,使整个搭建过程十分简单易上手。

3)权限

① 简单清晰,基础权限设计的参考模板

「明道云」的权限部分设计的是比较简单的,但是十分清晰,可以作为权限设计部分的基础参考模板。

在其内部,围绕着对象的增删改查下钻分化出对象内场景视图的增删改查、对象内字段的增删改查、对象内数据增删改查的范围、对象内可触发的操作四个方向。

虽然权限部分的功能非常基础,但是加上「明道云」出色的交互设计,整个权限部分十分简单清晰,可以作为 B 端产品基础权限设计的参考模板(仅限基础)。

过于基础粗放的权限功能势必会造成系统无法适应大型组织内部复杂的分工关系,但是这也契合明道云的产品定位,即适配中小组织、业务自发搭建、小范围内协同、通用型 aaPaaS 这四个关键词。

六、总结

1)总结

对于 aPaaS 平台的三大板块而言,目前对象和权限已经比较成熟且标准化了,且各家的功能在逐渐趋同;而流程部分各家差异是非常大的,「Salesforce」聚焦于抽象流程底层、「纷享销客」聚焦于业务场景实践、「明道云」则十分轻量易用。

这也和本次对比的三个产品的产品定位有关,「Salesforce」经过长时间的发展迭代,通过极其健壮的 aPaaS 能力,早已成为一个“开发平台”,打造自己的平台生态。

「纷享销客」作为国内极其优秀的 CRM 产品,在 CRM 的基本盘上通过 aPaaS 去满足大客户的定制化需求,同时也保留了国内平台在本土化上的优秀表现,打造出了“符合国情”的优秀产品。

而「明道云」和二者不同,其定位为通用型的轻量化 aPaaS 产品,本质上是去革 Excel 的命(有机会可以给大家拆解一下「伙伴云」,在我理解这才是真正的 Excel Pro),再加上优秀的体验,十分适合组织内部团队级的信息化协同。

不过在对「明道云」多说两句,「明道云」是我研究 aPaaS 时深入体验的第一款产品,个人对这款产品是十分喜爱的。但是还是有一点担忧的是,它没有自己的基本盘。

拿本次拆解的其他两款产品来说,「Salesforce」有自己的生态能力、「纷享销客」有极其优秀的 CRM 做基本盘,它们也在做 aPaaS。

换句话说,「明道云」能做到的,「Salesforce」和「纷享销客」也能做到。而二者的独特优势,却是「明道云」所确实的。而主打组织内团队级协同的话,随着组织的发展和产品在组织内的渗透,未来的 NDR 又会是一个挑战。虽然对其有所担忧,但是仍然希望「明道云」这款优秀的产品能够找到自己未来的发展方向茁壮成长。

2)展望

个人猜想,未来 aPaaS 平台在流程上的创新点是非常大的,尤其是对于国内 aPaaS 厂商。「Salesforce」流程的底层抽象已经比较完善了,但是国内 aPaaS 平台在流程的抽象上仍然有继续向底层深挖的迭代空间。对于权限的部分个人倾向于稳定发展,个人目前确实也想不到除了继续抽象组织的管理诉求外的其他创新点在哪里。

而对于对象,虽然和权限一样已经高度成熟且同质化,但是随着 AGI 时代的到来相信未来对象 + 流程 + AGI 可能会涌现出新的创新方向。

同时,包括本次对比的三款产品以及其他产品我们也能看到,国内的 aPaaS 平台与海外市场在发展方向上有本质的差别。

海外 aPaaS 平台由于先发优势,涌现了 SAP、Oracle 等强大但“工程化”的产品。而国内的新时代 aPaaS 平台诞生于中国互联网甚至移动互联网爆发之后,并且我们即将步入 AGI 时代。

再加上由于国内外企业商业环境和发展阶段的不同造就的对于 SaaS 和 aPaaS 平台定位和需求的不同,相信国内的 aPaaS 平台未来一定会朝着场景化、最佳实践化方向演进,为企业创造更大的价值。

附录:对比汇总

1)字段组件库对比汇总

2)Salesforce 6 大流程元素对比汇总

3)明道云 6 种流程元素对比汇总

4)Salesforce 流程变量汇总

5)纷享销客 4 大流程元素对比汇总

本文由 @Artisan 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。