在運營中,和其他部門的溝通技巧
從事運營工作的人往往自嘲是打雜的,的確這份工作通常做些很瑣碎的事情。在運營實際工作中,需要和其他各個部門配合,以提升運營效率,達到運營目的。在和各個部門的配合中,溝通是非常重要的,良好的溝通往往可以使配合更加有效,項目推進也會比較順利。在和不同的部門溝通中,自然也會有些不同的技巧,今天就來聊聊運營中,和其他部門溝通的技巧。
和產品的溝通
產品和運營其實是一條船上的人,兩者是處于同一戰線的兄弟,甚至在一些小團隊里,產品和運營之間的界限也是模糊的。某些產品指標也是二者共同負責的,比如日活、次日留存等等。因此和產品的溝通會比和其他部門溝通更簡單一些。
運營會提出功能上的需求,產品來評估優先級,這個時候會有分歧,因為運營提出功能需求,往往是為了提升運營的效率和數據,而產品評估優先級的維度會更多,首先是用戶層面,然后是公司戰略,也許最后才會是運營上的方便。這個時候運營去和產品溝通的策略就是從用戶層面、公司戰略上拔高某項功能需求的重要性,最好是有數據支撐。
舉個例子,一個線教育產品,其核心功能是看課,社區討論功能就屬于次要功能,但對社區運營人員來說,社區的功能完善對于其運營工作極其重要,這塊功能的完善可以大大提升社區的活躍度,在產品和開發資源有限的情況下, 如何去和產品溝通,才能使其重視社區上的功能呢?
那就從學生學習的角度分析,社區討論有老師答疑, 看課滿足的是學生的一般需求,而答疑是滿足學生的個性化需求,答疑功能的完善對于學生的使用體驗來說非常重要,并且我們通過數據分析看到越來越多的學生來社區向老師提問,老師的回答也很及時,這塊功能不盡快上線,對用戶體驗會有極大的影響。并且從公司戰略的角度分析,公司正在摸索課程之外的其他用戶服務方式,這就是非常重要的一種,因此這部分功能優先級能否提升呢?相信通過這樣一番溝通,運營提出的功能需求,自然會得到產品的重視。
和技術的溝通
運營和技術直接溝通的情況不太多,因為技術只接產品PRD中的需求。只有在兩種情況下,運營會直接和技術溝通,那就是發現bug和項目性的功能支持。
發現bug的溝通會稍微簡單一些,只需將發現的bug傳達給相關技術負責人,并要求對方給予一個解決日期,后續跟進就可以了。在這里,對bug的描述越清晰越好,可以通過截圖的方式記錄,并盡可能描述出現該bug的操作步驟,使用環境等,這是為了技術排查bug出現的原因,然后說明該bug影響的范圍和用戶行為,并陳述其重要性,這是為了給技術解決該bug的優先級評估。作為運營,不需要技術給出bug出現的原因以及如何解決,只需要對方給我們一個解決的時間節點,以便我們能及時跟進。
關于項目性的功能支持,則需要反復溝通,要講明白需求,提前寫好驗收標準。比如找前端寫個專題頁面,運營策劃好專題內容,風格特色,交由設計做出設計稿,就可以和前端去溝通了。有時候對功能的需求和標準描述不夠專業,會讓對方聽不明白,這個時候拿著案例去說就會好很多,我就想要做成某某頁面的樣子,這樣對于前端理解運營的需求會很有幫助。不要去和技術探討專業的東西,只談邏輯就好。另外,讓人幫忙做事,態度一定要好喲。
和市場的溝通
市場有很多工作種類,有一線的推廣人員,也有品牌公關人員。和他們的配合往往是對雙方都有利的。
一線推廣人員是最了解用戶的,他們會給運營反饋一線的情況,甚至競品做的一些事情,這對運營提升效率非常有用,因此和一線推廣人員的溝通,以聽為主,并根據他們提供的信息,做一些判斷和分析,并適時做一些能夠輔助一線推廣人員的運營活動。
和品牌公關人員的配合會稍微少一些,與他們配合也多是內容上的配合,他們有時會需要一些運營上的數據,產品上內容詳情,這些按流程配合就好,溝通不存在障礙。倒是可以多去和他們聊聊他們做的事情,或許能在運營上帶給你一些靈感。
和客服的溝通
我想客服是對產品最熟悉的人,也是最能發現產品、運營上漏洞和問題的人。客服的工作內容一般是接受用戶的咨詢,解決用戶使用過程中的問題,處理用戶的抱怨和投訴。和客服溝通,可以知道自己哪里做的不夠好,用戶面臨哪些問題。
在運營活動中,一份客服文檔是保持信息互通的很好方式,也是避免很多不必要溝通的方法。客服文檔,通常包括活動的基本內容(活動形式、活動時間、活動獎品等等)和常見問題的解答。這樣客服收到用戶關于活動方面的咨詢和反饋時,可以根據客服文檔及時作出回應,而不是再來找運營人員溝通詢問。
總結
和不同部門溝通技巧雖有差別,但根本上是有相同的,就是清楚自己的目的,站在對方的角度,以對方能聽懂的方式溝通。當你掌握了這些溝通的技巧,對于推進自己的項目進度,提升運營效率一定會大有幫助的。
本文由 @奔雷?原創發布于人人都是產品經理。未經許可,禁止轉載。
- 目前還沒評論,等你發揮!