很多項目制的工作中，團隊在售前到交付的銜接非常“倉促”。本文作者以自己的工作經(jīng)驗，對如何更好地完成工作的階段性銜接，更快的開展交付工作展開了分析，希望對你有幫助。

去年，我寫過一篇關于工作交接的文章（工作交接中的“交”與“接”）。不過這篇文章比較概括性，真正的工作交接需要考慮很多場景和“工種”。

最近幾年在工作中因為頻繁參與售前、研發(fā)、交付等不同階段，發(fā)現(xiàn)了大多數(shù)團隊在售前到交付的銜接非?！皞}促”。

所以，結合本人前些年的工作經(jīng)驗，以及所見、所聞、所學、所感，嘗試一篇和產(chǎn)品經(jīng)理似乎關系不大，但又有很多產(chǎn)品類同行，或者業(yè)務類同行在實際工作中會遇到的問題。同時也希望能給售前團隊、交付團隊工作者帶來一些啟發(fā)和參考，幫助我們更好的完成工作的階段性銜接，更快的開展交付工作。

文章很長，建議收藏。

一、為什么要做好售前和交付之間的交接工作？

以我們常見的項目制合作為主，面對日益激烈的市場競爭，銷售和售前拿新標的難度越來越大。

在公司銷售同事、售前同事的不懈努力下，甚至于在整個售前過程協(xié)調了很多資源（如產(chǎn)品資源，研發(fā)資源，其他條線的配合等等）的情況下，終于把這個新項目給拿下了，真是可喜可賀。短暫的慶祝之后，新的問題便要盡快面對，也就是交付過程的整個項目周期要開始了。

本次主題的重點不是闡述項目交付過程各個階段要面臨的問題和應對的策略，而是在交付負責人（如項目總監(jiān)、項目經(jīng)理，或者產(chǎn)品經(jīng)理、需求分析師）準備大顯身手之前，售前到交付的交接工作應該怎樣做才會更好？

俗話說，“不打沒有準備的仗”。現(xiàn)實中很多團隊由于缺乏了售前到交付之間的連接，導致交付前期的壓力爆棚，原本可以避免的問題屢屢暴雷，讓客戶在項目初期就大失所望，失去信心。

而第一印象又會對今后的長期工作產(chǎn)生“牽一發(fā)而動全身”的影響，也許一個成功的項目和一個失敗的項目，從這個項目開始之前，其命運就已經(jīng)決定了。

首先，先來初步了解一個新項目在中標之前，大體會經(jīng)歷怎樣的過程。

整體而言，新項目的形成包含了線索的收集獲取、商機的挖掘轉化、方案的溝通講解（多輪多次）、客戶演示及目標確認、招投標五大階段。

這五個階段并不是什么方法論，而是以個人經(jīng)驗總結的，可能和專業(yè)的售前階段有出入。

其中，不同的階段、不同的客戶、不同的行業(yè)以及項目背景，每個階段的工作任務也不盡相同，或者有些階段會省略，有些會變得很長。

比如客戶演示及目標確認這個階段，早些年很多項目都沒有這一步，售前人員靠一份PPT+一份解決方案，經(jīng)常做到“空手套白狼”。而近些年則越來越多的客戶在售前階段都要求，除了講解你們的方案，現(xiàn)在的產(chǎn)品、案例、實際的軟件，也要拿來看看，打打分，評估一下差異程度。而這一步又將在最終結果中占到很高的比例。

比如從線索到商機的轉換，很多企業(yè)會把這兩步合并為一步。但通過我最近的一些經(jīng)歷，認為線索和商機還是要區(qū)分開。而且銷售團隊如何把更多的線索轉化為商機，也是一個非常值得研究和思考的話題。

總之，當經(jīng)歷了千辛萬苦中標之后，如果只給交付團隊甩一份標書，或者之前的售前材料，簡單說說客戶要干啥，那一定是對結果不負責任、對交付團隊不負責任的表現(xiàn)。

另外，對于項目經(jīng)理、產(chǎn)品經(jīng)理來說，如果售前團隊沒有進行詳細的交接，我們也不能被動等待和盲目開展，應該主動詢問很多問題和現(xiàn)狀。

所以，知道了中標之前經(jīng)歷的大致過程，在后續(xù)提問題時才會更有重點，知道哪些階段的“故事”或“承諾”必須要了解，哪些信息必須要交接對齊。

而且交接是一個雙向的過程，兩個人、兩個團隊，或者多個團隊應該有一個明確的內(nèi)部交接計劃表（清單）來指引這個關鍵過程。

最終的目的，還是把這個項目做好，把客戶服務好，把售前吹的牛、挖的坑盡量落實。而真正在開干之前，雙方對齊哪些信息，則是重點。

二、售前過程的工作交接

從整體來看，我覺得售前到交付的交接過程，可以分為以下四個方面：售前過程（售前經(jīng)歷）、需求范圍、交付風險、其他補充。

本節(jié)先來看看售前過程中需要交接哪些內(nèi)容。

1. 本次項目的背景

其實就是客戶基于什么原因要做這個項目，希望通過此項目達到什么目的，或者解決什么問題？

其中涉及到多客戶部門的，要分別列舉。比如業(yè)務部門想要怎樣，而技術部門又想要怎樣，兩者之間是否存在沖突等等。

我認為項目的背景介紹要盡量詳細，盡量不要按照銷售、售前人員自己的理解表達，或者應該把信息同步完整之后，再發(fā)表個人見解。

因為大多數(shù)情況下，在售前階段接觸到的信息是不完整的，或者和一線訴求有偏差的。這時更應該客觀的反饋信息，讓交付團隊有一個通篇認識，他們在與客戶長期對接過程中逐步篩選和梳理，而非把個人的局部認知轉嫁到下一個團隊。

2. 項目的預算和合同額

當然，這些數(shù)據(jù)可能比較敏感，但作為項目經(jīng)理應該是要知道的。了解合同額方便項目經(jīng)理進行人員安排、進度安排，以便更好地進行成本控制，做到心中有數(shù)。

而知道預算額，對于有些客戶來說，已申請的預算如果剩余額度較大，在當年也會考慮花出去。所以項目經(jīng)理也能了解到后續(xù)的可操作空間，尤其是遇到需求變更、需求蔓延等階段，可以結合預算剩余額度，和客戶方慢慢“磨”。

3. 項目機會是怎么來的

一個銷售線索的來源方式有很多，可能是客戶主動聯(lián)系、公司主動營銷、其他項目同事挖掘、公開信息入圍、同行推薦等等。

為什么要介紹項目機會的來源方式？因為這能夠讓交付團隊更加理解本項目的“源頭”，并通過源頭理解和客戶各條線對接人之間的關系，以及對本公司團隊的認可程度等，為后續(xù)的交付細節(jié)進行評估和預演。

4. 合同范圍之外的附加承諾

這一點，很多售前團隊會遺漏。而對于客戶來說，很多其他形式的承諾會作為后續(xù)的驗收標準。

如果不進行相關問題的交接，當客戶主動詢問時一臉茫然，或者在出現(xiàn)一些問題時項目經(jīng)理與客戶扯皮，都會造成后續(xù)很多工作的困難。

客戶第一印象很重要，初期的印象最重要。如果能夠在項目團隊入場前期展現(xiàn)出自身的專業(yè)性和信息的全面性，能夠為后續(xù)的工作打下良好的基礎。

5. 客戶演示情況（如有）

如果本項目在售前階段有產(chǎn)品演示環(huán)節(jié)，則一定要把演示的結果、競爭對手的情況，自身的不足以及在演示時客戶重點關注的內(nèi)容進行全面交接。

畢竟，在一次次的售前溝通過程中，都會經(jīng)歷幾番“拉鋸”，再成熟的產(chǎn)品，進行客戶定制化交付時也會存在很多適配、個性化改造。而這些改造對于原產(chǎn)品的業(yè)務架構、技術架構都將或多或少的產(chǎn)生很多影響。

經(jīng)歷了售前過程中漫長的風雨，終于見到了彩虹，以上提到的“售前過程”便是交接的第一個范圍。把“售前過程”交接清楚之后，能夠讓團隊更加理解項目的目標和工作范圍。這些內(nèi)容都是在招標公告、投標文件中很難體現(xiàn)出來的。

三、需求范圍的工作交接

想必大家都能意識到新項目正式實施之前，需求范圍的重要性。無論我們的交接過程是否規(guī)范、完整，基本上都會包含“需求范圍”的交接。

但作為后續(xù)整個項目團隊的主要工作內(nèi)容和工作邊界，你覺得一份招標公告、一個投標文件、一版售前PPT夠嗎？。

下面我們一起看看，需求范圍應該包含哪些內(nèi)容，如果你作為交付團隊的項目負責人，或者產(chǎn)品經(jīng)理（需求分析師），你需要知道哪些信息之后，才有足夠的底氣開工呢？

我會把需求范圍的交接簡單分為五類，分別是整體情況、關聯(lián)方情況、我們欠缺的內(nèi)容、我們可利用的內(nèi)容、其他補充。下面來逐一介紹。

1. 整體情況

這一點不用過多贅述，如果一個團隊連需求的整體功能點交接都沒有的話，那你可以考慮跑路了

不過我來分享一個自己覺得效果更好的技巧：以講故事的方式重新整理一遍需求的整體范圍。

我不建議對照著word文檔或者Excel列表一條條的確認，更習慣用思維導圖，將功能分為三級，像剝洋蔥一樣以業(yè)務場景為核心路線，簡單串講各級功能情況。

這樣做一方面更容易讓聽眾理解，畢竟很多交付負責人或需求分析師之前并不了解這個業(yè)務；另一方面也能讓自己在重新梳理的過程中產(chǎn)生新的思考，發(fā)現(xiàn)新的盲區(qū)。

因為我們知道，對照著文檔講解，思路一定是被文檔中的內(nèi)容帶動的，很難真正獨立思考其中的合理性和全面性。

就像做產(chǎn)品講解之前一定要“試講”一樣，自己腦子里想的和嘴巴上說出來的，往往差異很大。

2. 關聯(lián)方情況

現(xiàn)在越來越多的項目不會是一個“業(yè)務孤島”或者“數(shù)據(jù)孤島”，都會或多或少和其他系統(tǒng)產(chǎn)生對接需求。所以需求交接的第二個重點便是關聯(lián)方的對接情況。

而且關聯(lián)方的對接情況很難做到標準化，因此這里的工作任務更多會反映到交付周期、交付工作量以及交付成本上，其重要性不言而喻。

很多團隊都有這樣一個不成文的規(guī)定：優(yōu)先搞清楚對外的工作任務，畢竟涉及到很多溝通協(xié)調和特色化改造。而自己產(chǎn)品內(nèi)所缺失的功能，實在不行就加班唄，起碼“自主可控”。

3. 我們欠缺的內(nèi)容

為了交付團隊方便梳理工作內(nèi)容，講我們現(xiàn)在具備什么功能，不如重點說我們欠缺哪些內(nèi)容。因為欠缺的內(nèi)容，都是后續(xù)最基礎的工作。

欠缺的內(nèi)容可能是場景和功能上，也可能是技術架構上，也可能是在設計層面或者文檔層面?？傊谑矍斑^程中能夠預知的，交付之前我們沒有的，都需要清晰的列出來。

之前我會梳理一個欠缺內(nèi)容的思維導圖給到項目經(jīng)理，再和他一起整理一份Excel列表。這份Excel列表后續(xù)便可以作為第一個版本的“需求矩陣”或“任務矩陣”進行逐項跟蹤。

好記性不如爛筆頭，無論是交出人還是接手人，都需要把這些已經(jīng)預見的事項。

寫清楚！

4. 我們可利用的內(nèi)容

這一點我相信大多數(shù)團隊在交接時都很少涉及。主要內(nèi)容是基于售前團隊對于現(xiàn)狀的分析，結合客戶各個對接部門、以及關聯(lián)方錯綜復雜的關系，而識別出的機會。

比如項目周期很緊張，按照正常交付工作量來看幾乎是不可能完成的任務。但是其中涉及到幾個關聯(lián)系統(tǒng)對接改造的任務，對方系統(tǒng)的配合度不足、或者任務排期很延后。這便是我們可以利用的，拉長交付周期的一個機會。

比如客戶方涉及到多部門協(xié)作，且存在一定的溝通壁壘。雖然看起來會影響整個項目的進展，但對于交付周期未定、需求評審未定的情況下，不見得完全是一件壞事。

比如客戶的技術方很支持我們，后續(xù)可以通過技術方的關鍵人幫我們協(xié)調哪些事情，尺度和張力是怎樣的。

其實，就像《反脆弱》這本書中提到的觀點一樣。每一次危機對于脆弱的人或組織，可能都是致命性的，但對于反脆弱能力強的組織，很可能是個機會。

畢竟有句老話叫“亂世造英雄”。

5. 其他補充

其余可能包含自己對于需求范圍的工作意見或建議，可以列舉客戶方需求對接的責任人、負責部門，以及這些人的脾氣性格，對我們前期的認可程度等（具體內(nèi)容在“人情世故”交接那一部分）

總之能想到的都可以先寫上。

我覺得交接不怕內(nèi)容多，更怕遺漏和不確定性。

以上五部分，基本涵蓋了需求范圍的核心要素，其他內(nèi)容可能會根據(jù)產(chǎn)品不同、行業(yè)客戶不同形成很多差異，所以需要我們結合實際情況整理出適用于自己團隊的“交接清單”。

四、交付風險的工作交接

售前過程中，其實我們能夠預知到很多后續(xù)的風險情況，如果能夠將“交付風險”做好交接，那一定是一件非常有價值的事情。

當我們在需求范圍交接中，把“我們欠缺的”這部分內(nèi)容梳理清楚，前期埋的雷應該能明確一大半。其他方面的風險可以大體分為以下幾類：

1. 人員風險

比如投標時對于人員的安排?？赡芎芏鄻藭袝懭藛T清單，但這些人員有幾個是可以真正具備入場條件？如果不滿足，需要找哪類人員進行置換？尤其是對于中大型的項目團隊，臨時組建一個10人以上的項目組，即便人數(shù)湊夠了，但真正的團隊戰(zhàn)斗力又將如何？

項目組中人員梯隊的建設、經(jīng)驗及年限的要求，人員入場時甲方是否有面試要求，入場后客戶是否有一些管理要求會限制團隊人員的穩(wěn)定性？

比如前兩年疫情，大多數(shù)項目組都會要求不允許跨市流動，對于長期出差的同事將是一個很大的考驗。即便是現(xiàn)在疫情結束，客戶方是否對于工作時間、著裝等有嚴格要求，入場人員是否能夠完全遵循。

這些看起來很小、很正常的事情，往往會對后續(xù)的實際交付產(chǎn)生不必要的影響。

之前我也遇到過一些從其他團隊借調過來，或者新招的人員，因為不滿意客戶方的管理制度而離職。

頻繁的人員變動會讓客戶方產(chǎn)生極大的不滿。

2. 成本與進度風險

很多項目受限于競爭壓力，首次中標都會壓低價格，進而導致成本不可控。再加上上述需求蔓延的問題，人員穩(wěn)定性的問題，最終導致進度延期。

很多項目其實在真正啟動之前，就已經(jīng)注定要延期、要超支。那么面對這樣一個難啃的骨頭，怎樣給交付負責人吃一顆定心丸？是否需要在交接時由領導出面給予一定范圍內(nèi)的授權？

記得之前參加一次項目管理培訓，老師說：賺錢的項目、容易的項目很多負責人愿意做。但不賺錢甚至明知賠本的項目，從公司考核角度來看，是否應該進行特殊對待？怎樣考核一個項目負責人的價值？

你做這個項目，能賠10個人月的工作量，我做能賠5個人月的工作量，這就是我的價值。但是我的價值在團隊考核層面能體現(xiàn)出來嗎？

這就像戰(zhàn)爭一樣，將軍派士兵出征前，這些問題要不要說清楚呢？

3. 技術風險

很多客戶對于技術棧的要求有自己的規(guī)范。比如數(shù)據(jù)庫有很多種，數(shù)據(jù)標準化管理規(guī)范也有各自的要求，一款產(chǎn)品在客戶方落地時，相應的技術組件改造也是一個非常大的工作量，而且是優(yōu)先級較高的。

這類技術風險如果沒有提前預判和交接，交付團隊按照原有的習慣評估推進的過程中，很容易對這些“額外”工作產(chǎn)生反感情緒。

即預期與現(xiàn)實嚴重不符，導致軍心渙散。

4. 風險一定要前置

因為我不是技術出身，所以對于技術風險相關的內(nèi)容可能整理的不全面。但我堅信這些風險一定要前置，并且以工作任務的形式系統(tǒng)化、具象化，并設定優(yōu)先級和跟蹤矩陣。

從時間管理的方法論上來說，風險都是重要但不緊急的事情，而我們更多的關注點可能在于當下已經(jīng)暴露的問題（即緊急但不重要的事情）。

而因為已經(jīng)暴露的問題占用我們?nèi)烤χ?，逐漸讓重要但不緊急的事情發(fā)展成重要且緊急的事情，從而形成小團隊內(nèi)部的惡性循環(huán)。

畢竟，項目交付是一套成熟的、體系化的管理過程，而非像救火隊員那樣哪里出了問題解決哪里。

提前把問題梳理好，其背后隱藏的價值比表現(xiàn)出來的價值高很多。

5. 沒有解決建議的提案都是“耍流氓”

“反正問題就是這些，你們看著辦吧”~這是我聽到過的非常不負責任的交接心態(tài)。

其實交付過程中的絕大多數(shù)風險，都是在售前過程中積累起來的。當然，這并不是說售前不能“挖坑”，因為本身兩者的目標存在差異。

售前過程為了拿標，做出一些承諾和妥協(xié)都是正常的，但我相信每一次在妥協(xié)時，雖然覺得有風險，但依然存在希望或者信心，相信交付團隊可以搞定。

所以這些親手挖的坑，要么給一些建議，比如某個需求和我們在另一個客戶那里的很像，可以找誰協(xié)助解決；比如哪些問題存在爭議，客戶方還沒有完全確認，但其中的幾個方案對于我們來講，A最優(yōu)、B次優(yōu)、C能做、D很難。我們要保B掙A。

或者表個態(tài)（比如需要我后續(xù)怎樣配合，我一定盡力之類的）。當然，這只是表態(tài)，到時做不做又是另一回事。

我們會發(fā)現(xiàn)很多團隊的內(nèi)耗及管理問題，就是這樣一點點積攢的。

五、人情世故的工作交接

所有的交接內(nèi)容，其實歸根結底都是為了“知己知彼”。

上文提到的內(nèi)容更多是客觀的、不可更改的事實，而下面的內(nèi)容，更偏向于主觀的，講究人情世故的內(nèi)容。

1. 客戶方主要干系人的性格

通過售前過程的接觸，相信我們的銷售團隊、售前團隊對于客戶方的主要對接人都有了一定的了解。通過對方言談舉止能夠大體評判此人的性格以及后續(xù)接觸過程中需要注意的事項。

對于這一方面的交接，我猜90%以上的團隊都會忽視。而這恰恰又是非常重要的一環(huán)。

比如有些客戶比較務實，對于細節(jié)很看重，如果沒有提前的心理準備，很多項目經(jīng)理在實際工作中會有很大的壓力。而這類客戶反而能夠通過專業(yè)的工作質量快速收獲認可。

比如有些客戶對于自己所負責的領域很精通，那么項目負責人或產(chǎn)品經(jīng)理最好不要“忽悠”對方。哪些能做、哪些可以盡量做、哪些不可以做都要分清楚，而不是幾次交流下來讓對方覺得你不專業(yè)。

再比如，前期和哪些對接人關系比較好，對方是傾向、支持我們的。對于這類人一方面要更好的維系關系，另一方面也可以想辦法和對方匯報一些實際情況，以求對方的建議和協(xié)助。

諸如此類，在交接過程如果能夠把未來將要面對的這些人員做一個初步介紹和預判，相信對項目負責人和前期入場的產(chǎn)品經(jīng)理會有很大的幫助。

2. 客戶間的組織關系

很多新建項目都不是一個部門在負責，涉及到主辦、協(xié)辦?？蛻舴揭彩沁@樣，尤其是一些大型企業(yè)、國有企業(yè)，部門間的職責分工很明確，部門間也存在或多或少的對接壁壘。

所以如果想更好的推進我們的項目交付，梳理客戶方各對接部門之間的關系，也將是一件很有意義的事情。

比如某項目由A部門主辦，B、C部門協(xié)辦，但是A和B之間因為某些歷史原因，在此項目上存在爭論點，可能會造成B部門不配合的情況。

這些可預見的問題要提前說清楚，同時也可以提供一些建議，比如可以找到哪位關鍵人來推進事情的進展。

3. 關聯(lián)系統(tǒng)之間的關系

除了客戶方的多部門對接，在交付過程中也經(jīng)常遇到多個系統(tǒng)之間的技術對接。而因為都是第三方公司，也可能存在目標不同、利益不同的情況，甚至可能出現(xiàn)過直接競爭關系，導致在對接時對方不配合。

這三個方面，其實都屬于“人情世故”的范疇。

項目交付既是做事，也是演出！

我們努力把項目做好，努力把角色扮演好，無論遇到哪些難題，最終的項目目標才是我們唯一為之奮斗的燈塔。

六、產(chǎn)品和交付何時介入售前流程？

通過上文的分享，我們可以結合自身團隊情況和行業(yè)情況，整理一個標準化交接清單，為一個順利的交付過程打下良好的基礎。最后，則聊一聊在售前過程中，產(chǎn)品經(jīng)理或交付經(jīng)理應該什么時候開始介入呢？

其實大多數(shù)團隊在售前過程中，或多或少會有產(chǎn)品經(jīng)理的介入，尤其是針對一些大客戶、重要客戶，需要方案經(jīng)理（售前）和產(chǎn)品經(jīng)理結合客戶的需求商討定制化方案。

而交付經(jīng)理很多都是在售前過程不介入的，除非在特定場景下需要技術支持，且研發(fā)團隊抽不開身的時候。

這件事可以和項目開發(fā)過程中，測試人員何時介入工作進行類比。

比如，大多數(shù)團隊都會在開發(fā)階段的后期委派測試開展工作，這樣可以降低人員成本。但較晚的介入會使測試對于項目的理解程度不足，進而引發(fā)測試覆蓋度不足等情況。

所以很多團隊開始將測試人員前置，前置到設計階段，甚至是需求階段。測試人員參與需求評審，為后續(xù)的測試工作打下夯實的基礎。

然而這種方式又會提升人員成本，降低測試人員的利用率。有時參與需求分析的是張三，等到真正開始測試的時候張三在忙別的，或者離職了，只能派李四去參與，那么張三之前的工作也就白做了。

放到售前過程是同樣的情況。面對不確定性極強的售前機會，公司要不要讓交付經(jīng)理參與支持？

參與，一定能夠提高售前方案的健壯性和合理性，也能夠在售前過程向客戶展現(xiàn)我們的專業(yè)能力。但交付經(jīng)理需要從現(xiàn)有工作中抽離出來，同時不確定付出的努力是否會保證項目中標。

有些團隊會讓交付總監(jiān)提前參與售前過程，經(jīng)過客戶交流、演示、招投標幾輪接觸之后，交付總監(jiān)便能直接開展后續(xù)具體工作。但是這種情況據(jù)我了解還是少數(shù)。

畢竟，售前客戶的數(shù)量級是比較大的，交付團隊無法按需匹配過多的資源支持，除非針對一些重要客戶、戰(zhàn)略客戶。

另外，從“鐵三角”工作模式來看，交付經(jīng)理也應該與銷售經(jīng)理、方案經(jīng)理一起介入客戶營銷的過程，提供應有的專業(yè)支持。但我覺得此時交付經(jīng)理的介入程度很淺，因為他可能還有很多項目需要做，很難投入更多的精力放在這些“不確定”的項目機會上。

其實，說到底還是商業(yè)模式和人員成本的問題，這些問題不在今天的討論范圍之內(nèi)。

所以，這個過程需要形成一種可執(zhí)行的協(xié)作機制，大致梳理不同工種之間的分工和準入準出標準，同時要有相應的應急和考核指標。

用流程推動人的行為，而非由人驅動行為。

這句話是最近兩個月從一位大領導口中聽到的，印象深刻的兩句話之一（另一句感興趣的可以私聊）。

不過，說到這種機制的建立，對于大多數(shù)企業(yè)或團隊而言，都屬于重要但不緊急的事情，優(yōu)先級排序一定是延后的，設立的過程也一定是緩慢的，最終的效果99%是無效的。

但是，這并不代表我們忽略，或者不重視這個問題。畢竟精細化管理中的“精細化”，就是體現(xiàn)在這些細節(jié)構成的大框架內(nèi)。

企業(yè)的降本增效和可持續(xù)發(fā)展，需要這些精細化流程作為支撐。

我們應該根據(jù)自身情況，結合華為“鐵三角”方法論進行嘗試，摸索出一套適合自身的售前—>交付的一體化管理體系。

七、寫在最后

本文的題目：從售前到交付，一場以交接為主的修行。這是我思考很久之后決定使用的題目，其重點在于最后的“修行”二字。

不同的團隊、不同的人、不同的性格，在面對不同的行業(yè)、市場、客戶、產(chǎn)品等細分情況時，一定會延伸出很多千奇百怪的情形。

而修行，就是要耐下心來，從中抽絲剝繭、尋找規(guī)律，最終形成一個體系化的雛形，再通過實踐逐步打磨，最終達到預期效果。

這個過程一定是以年為單位計算的。但如果想要做到自身經(jīng)營管理的降本提效，這些精細化管理流程勢必要改革、要行動。

如果讀完本文，能夠盡快形成一份相對標準的交接清單，也不枉我碼字八千！