DingTalk「开发者说」- 酷应用业务篇之:如何设计一款酷应用

简介: 本篇主要从产品的视角讲解酷应用的设计逻辑和基于群场景的能力构成与场景拆解。

DingTalk「开发者说」

酷应用业务篇之:如何设计一款酷应用

 

 

摘要:本篇主要从产品的视角讲解酷应用的设计逻辑和基于群场景的能力构成与场景拆解。

 

分享人:溪时,群场域应用产品负责人

 

视频地址:

 

正文:

 

一、群酷应用的整体介绍

 

1.  什么是群场景的酷应用

 

群场景酷应用是指:可在群内直接启用,并与群内用户互动的一类应用,其与群所处的场景深度融合,能够帮助群的用户在群内完成业务闭环。

 

下图是两个典型的酷应用群场景:项目管理群应用场景和工单协同群应用场景,项目管理进度、任务详情、群工单信息、负责人等都会在群内呈现。

image.png

 

2.  群酷应用的产品设计架构

 

一个完整的群应用,必须包含多个可安装在会话应用栏的应用节点和一个群机器人,并主要使用互动卡片、半屏容器与PC侧边栏,与用户进行互动。

 

一个优秀的群应用,应聚焦于解决垂直场景的垂直问题,且其本身的业务服务能力可在群内基本闭环。

 

image.png

3.  群酷应用的核心能力构成

 

群酷应用的核心能力构成如下图所示:

image.png

a.   事件回调:感知酷应用和群的各类生命周期事件,功能包括酷应用启用、停用、群解散、添加/删除群成员等;

 

b.   互动卡片:在开放区块内嵌开发者页面呈现数据、提供用户交互,功能包括消息卡片、置顶卡片、用户交互、主动更新、千人千面等;

 

c.   群应用入口:应用功能的快捷入口,用户通过点击可快速访问功能页面,功能包括:多端定制、多模式打开、动态参数、红点引导、多级菜单等;

 

d.   机器人:消息收、发通道,具备对话式交互能力,功能包括发送/接收消息、撤回消息、查已读未读等;

 

e.   能力套件:可内嵌到开发者自己页面内部的一系列钉钉前端组件,功能包括启用酷应用、建群、用户发消息、加人等;

 

4.  群在客户端的能力开放

 

针对应用开发者的各类场景,群在客户端做了整体性的开放,基本开放能力包括:会话设置、置顶卡片、机器人、互动卡片、消息、会话应用等,以帮助开发者更好地服务客户。

image.png

 

a.   会话应用栏

 

会话应用栏是群应用在群内的核心入口,用户侧可通过应用栏上的会话入口,快速开发应用部署在群内的各项服务能力,如查看工单列表,或者创建新的任务等。

 

会话在这个场景下为应用提供了传参能力,应用开发者可获取具体是哪个用户在哪个群内点击了哪个插件,从而可以更好的提供针对性的服务,即使同一个入口,不同用户也会实现千人千面的服务,让用户得到更好的体验。

image.png


b.   互动卡片

 

互动卡片是酷应用在群内的主要载体,如何设计和使用互动卡片的交互和刷新能力,是决定酷应用好坏的关键。

 

互动卡片的三个核心能力:卡片动态更新、用户点击交互、千人千面。

 

能力一:卡片动态更新

 

开发者可以实时更新互动卡片数据,钉钉多端实时更新卡片内容。

可触发更新数据的方法有两种:

  • 点击更新:用户点击卡片按钮触发回调,开发者返回最新卡片数据,如群接龙;
  • 主动更新:开发者调用API主动更新卡片数据;

image.png

 

能力二:用户点击交互

 

“实时互动”能力:让用户直接在卡片内进行交互,促进沟通互动,并且无需进入二级页面,能够缩短用户操作路径,提升效率。

 

注:用户交互通过http回调给开发者的服务进行处理,服务调用rt长时间低于1200ms,可能会被限流。

image.png

 

能力三:千人千面

 

开发者提供的卡片数据会用于卡片布局渲染和数据内容填充,分为公用和私有数据,借助公有和私有数据,实现卡片布局和内容的千人千面:

  • 公有数据:默认卡片对每个用户渲染优先使用的数据;
  • 私有数据:对部分用户指定私有数据,优先用私有数据渲染卡片。

 

以下图为例,上一张卡片的“拒绝”和“接受”是公有数据,即群内每个人都可以看到的,当用户点击拒绝或接受以后,第二张卡片呈现的“已拒绝”就是私有数据,即仅点击的用户可以看到。

image.png

再比如一个卡片报表,推送当天的销售业绩,其中一些信息如客户数据、销售金额等不能呈现给群内所有成员,这种场景只需要在卡片的模块中设置私有数据,指定这些数据仅限哪些人可见,当卡片发送到群内,群内成员看到的会是不同的卡片内容

注:单张卡片最多支持500个用户的私有数据,单次调用创建卡片和更新卡片接口,最多支持传递20个用户的私有数据。因此,在超大群中不建议使用千人千面的方式。

 

c.   群机器人

 

群机器人会随应用安装到群后一起启用。群机器人为应用提供了与群内用户进行直接交换的能力,如推送进度公告与任务信息,响应用户的@信息。机器人是互动卡片发送的主要载体。

image.png

机器人的核心能力:

 

  • 接收用户消息

用户at机器人的消息以Http 回调的形式回调给开发者;

  • 发送消息

可用API发送互动卡片等各种内容到群内;

  • 查询已读/未读

通过消息id 查询已发送消息的已读未读数据,以帮助开发者提升业务运行效率以及全面了解业务运行情况;

  • 撤回消息

通过消息id 撤回已发送的消息;

  • 机器人管理

机器人是随酷应用一起安装到群内,同时,机器人也随酷应用一起从群内卸载。

 

机器人的整体链路

 

下图是钉钉机器人整体链路图,钉钉所有机器人消息链路,都符合这个关键链路的设计范式。

image.png

钉钉机器人整体链路图

 

在这一链路中,主要包含机器人消息发送系统和机器人消息回调系统。

  • 开发者发送机器人消息,请求到开放平台网关,然后自动发送消息到客户端;
  • 消息发送中会经过机器人消息限流、内容安全检查、消息体格式检测等;
  • 客户端收到消息后会将客户端消息监听、消息体解析/处理、数据结构体构建等,通过机器人消息回调系统推送给开发者

 

d.   容器能力

 

在群内设计酷应用,需要充分利用IM在端内的容器能力,让用户侧可以在一个界面,即可完成全部交互和全部业务,无需跳出场景,解决用户在多个应用入口来回跳转的问题,实现所有交互在群内闭环完成。

image.png

PC端侧边栏打开链接

image.png

移动端半屏容器打开链接

 

半屏容器实例

 

以叮当OKR酷应用为例,将“我的OKR”、“创建OKR”作为入口,放在群快捷栏上,让内部群的用户可以直接在群内查看OKR和创建OKR, 同时借助蓝条和红点提示能力,也可以在插件上做到信息的提示。

image.png

 

二、基于群场景的案例分析

 

1.  酷应用设计工具:场景泳道图

image.png

场景泳道图

 

场景泳道图将酷应用设计分为三个步骤:

 

  • 第一步:明确场景主线

以场景主线的方式描述对应的场景,并在场景主线上标注任务节点;

  • 第二步:明确功能活跃度

标注任务节点的功能活跃度;

  • 第三步:高频功能卡片化

针对高频功能运用卡片的更新、回调、私有数据等功能更新群内进度。

 

以招聘场景“一起招聘”为例,将业务场景拆解如下:

 

  • 角色设置:作为一次性工作,钉钉建议将角色设置放在主应用的流程中;
  • 简历上传:这是相对中频的工作,主要由HR负责,在群内只需启用快捷入口即可;
  • 简历筛选:可以运用群卡片完成,将初步筛选出的简历以卡片的形式发送到群内的面试人员;
  • 面试安排:属于高频工作,面试官安排好面试时间后将信息告知相关人员,需推送卡片到群内并将日程同步到钉钉日程中;
  • 面试反馈、录用:都属于高频工作,面试后的反馈和录用与否需要在群内告知,同样以卡片的形式推送到群内并以群吊顶形式实时更新进度;
  • 面试复盘:面试结束后做面试复盘并在群内呈现。

 

2.  具体案例

 

【案例一】客服系统的酷应用改造

 

image.png

原有高度依靠人工协同的流程

 

a.   改造前:

  • 客户问题提报、处理在一个群内,信息混杂,小二在钉钉和工单系统频繁切换;
  • 客户缺少自助解决问题渠道,小二需要时刻关注群内信息和工单状态;

 

b.   改造步骤:

  • 将所有信息汇总到一个群,客户人员和客服人员都在这个群内,机器人会即时响应客户问题;
  • 重新部署群快捷栏入口,将工作台、工单等任务放在快捷栏入口,客户可以自助查询信息、处理任务,而无需人工对接;
  • 重新设计业务流程,将与主群无直接关系的信息和任务处理放到子群,比如:客户提出问题后,线上客服会创建一个子群自动将客户和相关人员拉入,在子群中处理问题;

image.png

 

c.   改造后:

  • 一单一群,小群处理故障,大群实时同步进度,信息再多也不乱;
  • 通过流程拆解和分群,实现信息效率十倍提升;

 

d.   核心价值:

  • 建单模式:改变在线服务的业务模式,释放生产力;
  • 任务单群:有效解决信息过载、任务跟丢情况,消息管理、任务跟进更聚焦。

 

【案例二】应急响应系统的设计

 

a.   业务痛点:

  • 多群响应,信息分散,第一时间故障链路相关人找群难;
  • 应急协同不清晰,不清楚SOP是什么,群里谁负责什么;
  • 应急时无法及时获取当前进展,依赖爬楼;
  • 应急过程中响应、动作、决策无记录,不可追溯,依赖爬楼;

 

b.   解决方案

  • 故障处理群统一管理,通过公告、消息引导至同一群内处理;
  • 通过机器人进行人员、流程协同,群内标示人员身份;
  • 通过吊顶、卡片跨群同步处理进展;
  • 结合聊天记录、群内互动信息,自动生成处理过程;

 

image.png

 

c.   预期价值

  • 基于钉钉IM开放能力,打通监控、运维、调度等业务系统,建设线上协同解决方案,保证应急响应的高效、有序和透明。

 

三、总结

 

1.     群酷应用适用场景

 

群酷应用适用于多人(参与人数量)、多节点(任务复杂度)、多任务(并行任务量)的场景。

 

2.     酷应用分类

 

酷应用的分类是基于参与人数量、任务复杂度、并行任务量三个维度,分为四类:

 

  • 数据收集型

多个人、单任务、单节点,例如:打卡,订餐,问卷,投票,兴趣派,日报,技术分享等;

 

  • 客户服务型

多个人、多任务、单节点,例如营销服务(纷享销客、销帮帮);

 

  • 单任务流转型

一个人、单任务、多节点,例如:工单、GOC报警、AONE、招聘等;

 

  • 自定义型

多个人、多任务、多节点,例如:一起出差(阿里商旅)、OKR(叮当OKR)、资产管理(公贝资产)等;

 

前三类属于通用型,钉钉提供酷应用通用模板进行快速适配,针对第四类自定义型,钉钉提供了设计工具和设计指引,以加速应用改造的操作。

 

image.png

 

四、Q&A

 

Q:酷应用有模板吗?

A:酷应用本身还没有模板,钉钉提供了酷应用中互动卡片的开发者模板。如果全代码开发有困难,可以尝试使用宜搭的低代码酷应用开发。

 

Q:半屏打开页面可以嵌入H5吗?

A:其实半屏打开的就是一个H5+浏览器,可以将原来的业务系统嵌入。

 

Q:酷应用案例在哪里可以看?

A:钉钉开放平台文档中有很多酷应用案例供大家参考。

 

相关文章
|
开发者
【官方帖】各位宜搭开发者,晒一晒你的酷应用开发案例,评论留言吖~~~
快来晒一晒你的酷应用开发案例,有机会在宜搭服务窗/微信公众号等渠道进行宣传推广~ 如果有您有更好的酷应用开发场景,需要宜搭产研共创支持,欢迎评论留言
【官方帖】各位宜搭开发者,晒一晒你的酷应用开发案例,评论留言吖~~~
【大陈子学低代码】— Vol.1 用宜搭酷应用制作的第一张酷卡片诞生
用集成自动化与酷卡片实现了部门特定人员的专属定时提醒,点对点推送,具备强动态性与交互性。
【大陈子学低代码】— Vol.1 用宜搭酷应用制作的第一张酷卡片诞生
|
人工智能 供应链 安全
DingTalk「开发者说」- 酷应用业务篇之:类目酷应用化的机会点及方法路径剖析
本篇主要讲解酷应用的红利期与机会点,以及做酷应用的方法路径。
DingTalk「开发者说」- 酷应用业务篇之:类目酷应用化的机会点及方法路径剖析
|
JSON 搜索推荐 前端开发
DingTalk「开发者说」- 酷应用开发之卡片开发和能力套件开放
本篇主要讲解钉钉酷应用中卡片的构造、接口和最佳实践,以及卡片未来的规划和能力套件开放。适用对象:产品经理和有技术背景的开发工程师。
DingTalk「开发者说」- 酷应用开发之卡片开发和能力套件开放
|
移动开发 算法 机器人
DingTalk「开发者说」- 开发钉钉酷应用集成入门
本篇主要分享钉钉酷应用的群应用开发流程和实践。
DingTalk「开发者说」- 开发钉钉酷应用集成入门
|
运维 监控 搜索推荐
DingTalk「开发者说」- 酷应用业务篇之:酷应用总体介绍
本篇主要讲解钉钉酷应用的总体概念、使用范围、具体案例等信息,带大家走进钉钉酷应用。
DingTalk「开发者说」- 酷应用业务篇之:酷应用总体介绍
|
机器人 API 开发者
DingTalk「开发者说」- 使用宜搭酷应用工厂开发酷应用
本篇主要讲解宜搭酷应用工厂的概念和开发指南,以及使用宜搭酷应用工厂开发钉钉酷应用的实践。
DingTalk「开发者说」- 使用宜搭酷应用工厂开发酷应用
|
前端开发 安全 搜索推荐
DingTalk「开发者说」- 酷应用开发之群扩展基础开发
本篇主要讲解钉钉酷应用在群内的功能,群内酷应用的接入、开发演示和最佳实践。
DingTalk「开发者说」- 酷应用开发之群扩展基础开发
|
移动开发 JavaScript 小程序
干货分享|APICloud多端架构与开发实践解析
随着内容/媒体/智能设备的极速丰富,app需求出现井喷。移动设备屏幕碎片化、系统版本分散、厂商定制竞争加剧等各种开发适配痛点导致app开发成本和周期问题凸显,这与企业的低成本、高人效诉求相矛盾。
235 0
|
IDE 开发工具 开发者
APICloud超实用经验分享——平台功能
从2016年开始使用APICloud进行app项目开发,到现在也有五六年了。在此过程中伴随着APICloud一起成长,踩过一些坑,自己的技术也提升不少。在APICloud 推出avm框架一年之后,IDE和框架逐渐成熟。我打算把这些年使用APICloud的经验做个总结,希望帮助到更多的开发者。总结分为开发工具、平台功能、模块SDK这三个方面,今天先讲一下平台功能方面的。
195 0