Access
跨产品的账号与权限。
采用以通行密钥为主的登录方式，管理工作区成员和产品级权限，不必为每个应用单独做一套账号体验。
01
下一个产品，不该意味着又一套后台。
新应用需要的不只是核心功能。总得有人管理账号、核对产品权限，并在出问题时回应用户。
把产品独有的体验做好，把重复的运营基础复用起来。
彼此独立的产品。
- Product A账号 · 许可 · 收件箱
- Product B账号 · 许可 · 收件箱
- Product C账号 · 许可 · 收件箱
每个产品都要重做账号、权限、许可和一套反馈收件箱。
彼此连接的运营。
- Product A产品功能
- Product B产品功能
- Product C产品功能
Access · Commerce · Care
产品独有的功能和数据留在产品里，共享的运营层被复用。
02
从“我导不出来”，到一个有上下文的答复。
-
确认是哪个产品
看清请求来自哪里，涉及哪个版本。
-
核对相应权限
对已核实身份的用户，在你被授权的范围内查看相关产品权限和许可。
-
理解问题本身
把用户的描述和可获取的技术证据放进同一个工单。
-
回复或转交
结合上下文直接回复，或整理好开发同事排查所需的证据。
一个工单。更少在工具之间来回。
- 已核实的反馈者
- •••
- Editor Web
- ISS-0001
- 当前版本
- 3.1.7
- 反馈已收到
- 11:42
示例数据，不是真实工作区，也不是客户活动。
03
三个相连的领域。一个工作上下文。
Commerce
把购买记录和产品访问权限连接起来。
围绕客户实际使用的产品，组织套餐、许可、席位和用量权益。把支付处理与产品内部的访问判断分开。
Care
始终与对话相连的反馈。
把用户反馈、相关诊断信息和回复放进同一个支持流程。让团队有排查的上下文，也让用户有跟进的途径。
从适合你现状的模块开始。
04
为同时运营多个产品的团队而做。
一个网页应用和它的桌面版。几个 SaaS 产品。一个不断推出新工具的小工作室。
让产品定位和运营上下文保持在一起，同时每个应用都保留让它好用的那份体验。
- 适合小型产品团队。
- 适合软件工作室。
- 适合网页与桌面产品组合。
05
先从一个产品开始，按需要再连接更多。
-
先选定要解决的运营问题。
可以从账号、产品访问权限或用户反馈开始。
-
连接相应的产品。
使用适配你的应用和环境的受支持集成方式。
-
把工作流程放在一起。
让团队在一个一致的地方管理这些相连的工作。
已经在用身份或支付服务商？我们会围绕你现有的系统一起规划集成范围。
06
运营共享，边界清晰。
把工作区和产品权限区分开。只给成员他们负责的那部分工作的访问权限，并把面向客户的回复与内部备注分开。
只收集与问题相关的上下文，而不是要求用户把所有东西都发过来。应用专属的数据和逻辑留在应用里。
07
几个实际的问题。
我们必须替换现有的身份验证或支付吗？
不一定。可以先从符合需求的模块开始，并确认你当前技术栈受支持的集成方式。
这只适用于网站吗？
这个平台面向同时拥有网页和应用产品的团队。请确认你所用运行环境的反馈与集成支持范围。
IO Patina 会替我们回复用户的支持请求吗？
用户的反馈和对话由你的团队来管理。IO Patina 提供平台本身以及对平台的支持。
Platform 会取代我们应用的后端吗？
不会。应用的核心功能、产品数据和业务规则仍留在你的产品里。Platform 连接的是共享的运营工作。
可以只从一个产品或一个模块开始吗？
在受支持的配置范围内可以。我们会先一起梳理涉及的产品、模块和集成工作。
价格和适配情况怎么沟通？
把你的产品构成和想连接的工作流程告诉我们，我们会与你一起讨论范围和商务条件。