社群要有任务,不能只是一个在场的群
社群运营计划里,如果社群仍是把建群当成目标,结果往往是群在,却没有人知道它要完成什么。


同意写在文件里并不等于已经到达触达规则。翻译的第一步,是在征求同意的同时写明语气和频率。
若翻译只是把先把同意拿下来,语气以后再改缩短,一线遇到的仍是:对方感到被推着走,同意也变得勉强。
在征求同意的同时写明语气和频率。做不到这一点,同意就还停在先把同意拿下来,语气以后再改。
同意最常在任务拆开时变形。部门各自领走一句好说的话,却没有领走对应的拒绝。
于是对外仍能看见先把同意拿下来,语气以后再改,对内却解释不了:对方感到被推着走,同意也变得勉强。
同意的最小单位不是一整本手册,而是一个能当场使用的判断。同意说明就应该是这个单位。
一线拿到同意,不必再猜品牌部门会怎么想。
规则上线前,抽一处现场,看同意说明有没有退回到先把同意拿下来,语气以后再改。
改写不一定是坏事。坏的是改写之后没有人承认同意已经变了。
判断力要留在使用的人身上。客户经营负责人,同时让现场有权按同意说明拒绝。
培训结束时只考一个问题:对方是否知道会以什么频率听到什么。
从不可让渡的部分到现场可用的工具,每一层只回答一个问题,避免把同意重新写成先把同意拿下来,语气以后再改。
这一层写明同意里什么不能让渡。
这一层把同意收成可检查的条件。
这一层规定同意在不同场合可以变什么。
这一层把同意交给使用的人,并写明例外。
注:本图为概念框架示意,用于说明思考结构,不代表任何统计数据。来源:清美未来洞察团队。
在触达规则里标出同意真正被调用的时刻,不要从改写先把同意拿下来,语气以后再改开始。
用同意说明代替更长的说明,只保留能支持「在征求同意的同时写明语气和频率」的内容。
规则上线前,只问:对方是否知道会以什么频率听到什么。答不上来,就还不是决策。
客户经营负责人。没有维护人的同意,会在冲突里被悄悄改掉。
社群运营计划里,如果社群仍是把建群当成目标,结果往往是群在,却没有人知道它要完成什么。
年度复盘里,如果营销系统仍是以活动结案作为营销的全部记录,结果往往是结案很多,系统没有变好。
年度排期里,如果营销日历仍是按节日把档期填满,结果往往是节日过完,品牌没有自己的问题。