在
全网营销中有一个很关键的存在,它就是运营,但是往往从事运营工作的人自嘲是打杂的,的确这份工作通常做些很琐碎的事情。在运营实际工作中,需要和其他各个部门配合,以提升运营效率,达到运营目的。
在和各个部门的配合中,沟通是非常重要的,良好的沟通往往可以使配合更加有效,项目推进也会比较顺利。在和不同的部门沟通中,自然也会有些不同的技巧,运营中如何和其他部门沟通的技巧。
和产品的沟通
产品和运营其实是一条船上的人,两者是处于同一战线的兄弟,甚至在一些小团队里,产品和运营之间的界限也是模糊的。某些产品指标也是二者共同负责的,比如日活、次日留存等等。因此和产品的沟通会比和其他部门沟通更简单一些。
运营会提出功能上的需求,产品来评估优先级,这个时候会有分歧,因为运营提出功能需求,往往是为了提升运营的效率和数据,而产品评估优先级的维度会更多,首先是用户层面,然后是公司战略,也许最后才会是运营上的方便。这个时候运营去和产品沟通的策略就是从用户层面、公司战略上拔高某项功能需求的重要性,最好是有数据支撑。
举个例子,一个线上教育产品,其核心功能是看课,社区讨论功能就属于次要功能,但对社区运营人员来说,社区的功能完善对于其运营工作极其重要,这块功能的完善可以大大提升社区的活跃度,在产品和开发资源有限的情况下,如何去和产品沟通,才能使其重视社区上的功能呢?
那就从学生
学习的角度分析,社区讨论有老师答疑,看课满足的是学生的一般需求,而答疑是满足学生的个性化需求,答疑功能的完善对于学生的使用体验来说非常重要,并且我们通过数据分析看到越来越多的学生来社区向老师提问,老师的回答也很及时,这块功能不尽快上线,对用户体验会有极大的影响。并且从公司战略的角度分析,公司正在摸索
课程之外的其他用户服务方式,这就是非常重要的一种,因此这部分功能优先级能否提升呢?相信通过这样一番沟通,运营提出的功能需求,自然会得到产品的重视。
和技术的沟通
运营和技术直接沟通的情况不太多,因为技术只接产品PRD中的需求。只有在两种情况下,运营会直接和技术沟通,那就是发现bug和项目性的功能支持。
发现bug的沟通会稍微简单一些,只需将发现的bug传达给相关技术负责人,并要求对方给予一个解决日期,后续跟进就可以了。在这里,对bug的描述越清晰越好,可以通过截图的方式记录,并尽可能描述出现该bug的操作步骤,使用环境等,这是为了技术排查bug出现的原因,然后说明该bug影响的范围和用户行为,并陈述其重要性,这是为了给技术解决该bug的优先级评估。作为运营,不需要技术给出bug出现的原因以及如何解决,只需要对方给我们一个解决的时间节点,以便我们能及时跟进。
关于项目性的功能支持,则需要反复沟通,要讲明白需求,提前写好验收标准。比如找前端写个专题页面,运营策划好专题内容,风格特色,交由设计做出设计稿,就可以和前端去沟通了。有时候对功能的需求和标准描述不够专业,会让对方听不明白,这个时候拿着案例去说就会好很多,我就想要做成某某页面的样子,这样对于前端理解运营的需求会很有帮助。不要去和技术探讨专业的东西,只谈逻辑就好。另外,让人帮忙做事,态度一定要好哟。
和市场的沟通
市场有很多工作种类,有一线的
推广人员,也有品牌公关人员。和他们的配合往往是对双方都有利的。
一线推广人员是最了解用户的,他们会给运营反馈一线的情况,甚至竞品做的一些事情,这对运营提升效率非常有用,因此和一线推广人员的沟通,以听为主,并根据他们提供的信息,做一些判断和分析,并适时做一些能够辅助一线推广人员的运营活动。
和品牌公关人员的配合会稍微少一些,与他们配合也多是内容上的配合,他们有时会需要一些运营上的数据,产品上内容详情,这些按流程配合就好,沟通不存在障碍。倒是可以多去和他们聊聊他们做的事情,或许能在运营上带给你一些灵感。
和客服的沟通
我想客服是对产品最熟悉的人,也是最能发现产品、运营上漏洞和问题的人。客服的工作内容一般是接受用户的咨询,解决用户使用过程中的问题,处理用户的抱怨和投诉。和客服沟通,可以知道自己哪里做的不够好,用户面临哪些问题。
在运营活动中,一份客服文档是保持信息互通的很好方式,也是避免很多不必要沟通的方法。客服文档,通常包括活动的基本内容(活动形式、活动时间、活动奖品等等)和常见问题的解答。这样客服收到用户关于活动方面的咨询和反馈时,可以根据客服文档及时作出回应,而不是再来找运营人员沟通询问。
总结
和不同部门沟通技巧虽有差别,但根本上是有相同的,就是清楚自己的目的,站在对方的角度,以对方能听懂的方式沟通。当你掌握了这些沟通的技巧,对于推进自己的项目进度,提升运营效率一定会大有帮助的。
云裂变,就是一家专业的
品牌全网推广服务商,专业的人做专业的事,让客户省心省力,不烧钱做宣传。