在运营中，和其他部门的沟通技巧

2017-04-23 09:25:00

从事运营工作的人往往自嘲是打杂的，的确这份工作通常做些很琐碎的事情。在运营实际工作中，需要和其他各个部门配合，以提升运营效率，达到运营目的。在和各个部门的配合中，沟通是非常重要的，良好的沟通往往可以使配合更加有效，项目推进也会比较顺利。在和不同的部门沟通中，自然也会有些不同的技巧，今天就来聊聊运营中，和其他部门沟通的技巧。

和产品的沟通

产品和运营其实是一条船上的人，两者是处于同一战线的兄弟，甚至在一些小团队里，产品和运营之间的界限也是模糊的。某些产品指标也是二者共同负责的，比如日活、次日留存等等。因此和产品的沟通会比和其他部门沟通更简单一些。
运营会提出功能上的需求，产品来评估优先级，这个时候会有分歧，因为运营提出功能需求，往往是为了提升运营的效率和数据，而产品评估优先级的维度会更多，首先是用户层面，然后是公司战略，也许最后才会是运营上的方便。这个时候运营去和产品沟通的策略就是从用户层面、公司战略上拔高某项功能需求的重要性，最好是有数据支撑。
举个例子，一个线教育产品，其核心功能是看课，社区讨论功能就属于次要功能，但对社区运营人员来说，社区的功能完善对于其运营工作极其重要，这块功能的完善可以大大提升社区的活跃度，在产品和开发资源有限的情况下，如何去和产品沟通，才能使其重视社区上的功能呢？
那就从学生学习的角度分析，社区讨论有老师答疑，看课满足的是学生的一般需求，而答疑是满足学生的个性化需求，答疑功能的完善对于学生的使用体验来说非常重要，并且我们通过数据分析看到越来越多的学生来社区向老师提问，老师的回答也很及时，这块功能不尽快上线，对用户体验会有极大的影响。并且从公司战略的角度分析，公司正在摸索课程之外的其他用户服务方式，这就是非常重要的一种，因此这部分功能优先级能否提升呢？相信通过这样一番沟通，运营提出的功能需求，自然会得到产品的重视。

和技术的沟通

运营和技术直接沟通的情况不太多，因为技术只接产品PRD中的需求。只有在两种情况下，运营会直接和技术沟通，那就是发现bug和项目性的功能支持。
发现bug的沟通会稍微简单一些，只需将发现的bug传达给相关技术负责人，并要求对方给予一个解决日期，后续跟进就可以了。在这里，对bug的描述越清晰越好，可以通过截图的方式记录，并尽可能描述出现该bug的操作步骤，使用环境等，这是为了技术排查bug出现的原因，然后说明该bug影响的范围和用户行为，并陈述其重要性，这是为了给技术解决该bug的优先级评估。作为运营，不需要技术给出bug出现的原因以及如何解决，只需要对方给我们一个解决的时间节点，以便我们能及时跟进。
关于项目性的功能支持，则需要反复沟通，要讲明白需求，提前写好验收标准。比如找前端写个专题页面，运营策划好专题内容，风格特色，交由设计做出设计稿，就可以和前端去沟通了。有时候对功能的需求和标准描述不够专业，会让对方听不明白，这个时候拿着案例去说就会好很多，我就想要做成某某页面的样子，这样对于前端理解运营的需求会很有帮助。不要去和技术探讨专业的东西，只谈逻辑就好。另外，让人帮忙做事，态度一定要好哟。

和市场的沟通

市场有很多工作种类，有一线的推广人员，也有品牌公关人员。和他们的配合往往是对双方都有利的。
一线推广人员是最了解用户的，他们会给运营反馈一线的情况，甚至竞品做的一些事情，这对运营提升效率非常有用，因此和一线推广人员的沟通，以听为主，并根据他们提供的信息，做一些判断和分析，并适时做一些能够辅助一线推广人员的运营活动。
和品牌公关人员的配合会稍微少一些，与他们配合也多是内容上的配合，他们有时会需要一些运营上的数据，产品上内容详情，这些按流程配合就好，沟通不存在障碍。倒是可以多去和他们聊聊他们做的事情，或许能在运营上带给你一些灵感。

和客服的沟通

我想客服是对产品最熟悉的人，也是最能发现产品、运营上漏洞和问题的人。客服的工作内容一般是接受用户的咨询，解决用户使用过程中的问题，处理用户的抱怨和投诉。和客服沟通，可以知道自己哪里做的不够好，用户面临哪些问题。
在运营活动中，一份客服文档是保持信息互通的很好方式，也是避免很多不必要沟通的方法。客服文档，通常包括活动的基本内容（活动形式、活动时间、活动奖品等等）和常见问题的解答。这样客服收到用户关于活动方面的咨询和反馈时，可以根据客服文档及时作出回应，而不是再来找运营人员沟通询问。