有個經典的企業數字化段子：做了那么多系統，到最后用戶還是導入導出Excel。

很多人用這個段子來揶揄or自嘲企業做數字化轉型“無用”，但段子本身揭示了數字化的需求和痛點：業務流程復雜且變動，系統難以及時滿足邊邊角角的需求。

所以永遠需要“導入導出Excel”：導入導出是手動打通數據孤島；Excel是數據的中轉站，是易操作的數據處理平臺，所見即所得。

本期我們討論的主題就是Excel、企業數字化和飛書業務三件套。

飛書最初是用Office為團隊提供辦公協同，后來People致力于組織管理，到這個月飛書發布多維表格、應用引擎和集成平臺業務三件套，代表飛書想從產品走向業務，用輕量級前端深化連接千行百業核心系統的數字化能力。

本場直播嘉賓是西貝餐飲集團CEO助理魏骍然和飛書高科技行業解決方案總經理周琪，由我跟科技觀察者倪叔共同主持。

餐飲行業的數字化階段進程

魏骍然 餐飲行業最早都是用最原始的手抄單。前廳把菜譜給客人，看完菜譜點菜，服務員在紙質手抄單子上記下來，把復寫的單子前廳留一聯，給收銀臺一聯，給后邊廚房一聯，三聯，廚房按照單子去做菜再上菜。之后開始有了點菜寶，前臺點菜可以聽客人說你記住菜的編碼，用點菜寶把菜記下來之后，收銀臺打單機出了單子之后，再送到廚房出菜。后來，整個 POS 系統比較成熟了，從前廳點了菜之后直接把單子分到收銀臺和廚房，廚房會自動出紙質單，這樣終于把訂單接收和廚房生產就連起來了。但那時這套系統只是單店版的，每家店想要裝這些東西，得在店里裝一個服務器，屬于局域網那種感覺。

進入移動互聯的時候，手機上出現了跟吃飯相關的APP，最早是點評的 APP 化，后來出了美味不用等，再后來就是美團餓了這樣的外賣平臺。人們逐漸習慣于在手機上去做餐飲的日常消費，但那時很多店里還不支持在線點餐或在線結賬。到15年左右，店里既有手機結賬的終端，也有刷銀行卡的POS刷卡機，因為很多人還習慣用銀行卡結賬現場刷卡。

大約在這個時期西貝開始成立自己的數字團隊，開發門店里手機點餐排號結賬這一整套客用的服務系統。在前廳客用的這套服務系統建立起來之后，西貝又開始往后延伸跟用友之類的合作伙伴去共同開發，把整個的財務系統、門店的KDS生產看板系統，全部都連通在了一起。現在西貝全國 300 多家門店前一天的實時營收數據，第二天早上會發送到所有核心高管的手機上，現在西貝已經習慣于這樣的工作方式。

周琪 魏總說的很形象，特別有畫面感。我說一個很關鍵的詞，就是被時代推著走。這么多年每個不同的時間段，大家數字化做得不太一樣。

我分享我看到的，第一個階段可能是偏信息化，第二個是大家非常有體感的移動化，第三個階段我們會看到很多企業都開始去做云化，把IDC這些基礎能力都托管給公有云，自己專注核心業務系統的建設。

我覺得現在是來到第四個階段，在整個市場其實從一個所謂的增量市場轉向存量市場，或者是我們增長速度下來的時候，企業真正開始做數字化，以及做整個數據治理，不管是關注整個組織，還是關注企業內部的提效，以及關注企業內部業務系統的連通。講究更科學、更高效的競爭。當然各個行業可能階段不一樣，但我覺得趨勢大概是這個樣子。

多維表格和Excel的區別

潘亂 3月22號飛書發布了多維表格、飛書應用引擎和飛書集成平臺業務三件套，意味著飛書它從協同辦公、組織管理，在更緊密地走進業務。但盡管中國 SaaS 行業發展了這么多年，做了那么多系統，到最后各家公司最習慣的還是導入導出Excel。如果現在大量的使用 Excel 來進行管理，它可能會有什么問題？

魏骍然 Excel 我們以前用的比較原始。比如總部一個部門要下發一個什么東西，需要一個表格來把信息裝進去。表格制定完了以后就開始分發，層層往下發，發到中間可能有新版的要求再發一遍。折騰一兩次以后，可能有時信息就亂了，而且分發的過程中也經常會有遺漏。

因為餐飲行業屬于勞動密集型行業，尤其我們做連鎖經營，全國各地都要開店，它跨地域的范圍很廣，人也多。雖然現在你可以線上隨時發這些東西，但是發完以后，是不是每個人都發到了，是不是每個人都看了或怎么樣，你沒法去追。這些事都很瑣碎，你要是用比較傳統這種方式，他就會遇到這種問題。

但是現在我們靠飛書把問題相對改善了，相當于所有的東西都是跟你的花名冊和任務系統捆綁在一起。你一個文件你丟出去，我想給誰看，我拉拉名單，拉完了以后這些人看不看，收沒收到我知道，并且我還能隨時點它。用起來很輕松，不需要額外的再去琢磨這個東西怎么用，使用門檻也比較低。

潘亂 周琪你來補充一下，多維表格跟 Excel 有什么樣的區別？包括它能夠承載的客戶業務的維度，包括它功能的深度上，又往什么方向去做拓展呢？

周琪 其實之前見了特別多各行各業的企業，大家基本有一個共同的體感，數字化的盡頭就是 Excel。每個系統每個行業在做什么分析的時候，最后很多都是在 Excel 上去做。

我說下多維表格跟 Excel 最核心的區別。我認為多維表格是本質上是一個行列的數據庫，而且它實現的最好的功能就是讓所有人可以在線同時編輯，而且我可以定義清楚每一列每一行的權限，也就是我可以實現行列權限精準控制。不同人看到的信息是不一樣的，從這個基礎上你會發現它拓展了非常多業務的可能性。

如果你做一個業務場景的時候，你用 Excel 可能很難搭出來一個業務系統。但是你用多維表格，有了這些行列權限的控制，有了每個不同的字段的定義，可以讓這些人輕松的把自己想實現的業務系統給搭建出來，而且因為它沒有代碼，一線業務人員就可以很輕松的把搭建起來。所以它應用的領域是非常廣，而且有點像是讓每個人可以搭建一個自己的業務應用這種感覺。

多維表格的應用場景

潘亂 再問一下魏總，在西貝使用多維表格，它能夠覆蓋什么樣的場景？

魏骍然 我們現在多維表格在學著用，舉比較典型的兩個例子。一個是我們客服部門跟財務部門在用多維表格，把他們的業務流給他打通了。之前因為我們客服部門要接到全國各地客訴或是問題需求，我們400電話有百分之十幾到二十的比例是要開發票的，補開發票的。因為我們發票都可以線上開，但線上開有幾個月的時限，經常有顧客超了日期打客服電話補開發票，如果顧客打電話過來幫他開發票，以前的流程是接到電話后把顧客需求記下來，給顧客郵箱，顧客把他的消費小票或者消費記錄發過來之后，客服人員需要根據消費記錄去找到這是什么時間在哪家店消費的，找到對應的這家門店或區域的財務負責人，找到他之后說顧客什么時間把消費憑證發過去。財務發票開好再傳回給客服人員，跟顧客再聯系要郵箱或者是加微信之類傳回去。

后來飛書的效能顧問幫我們用多維表格把這套流程搭起來了。現在客服人員接到這種顧客需求，只需要把消費記錄填到表格里，后面流程自動跑，自動提醒。我們全國有300 多家店，十幾家分公司有十幾位財務負責人，客服人員不需要這個店歸哪個區域，這個人是誰，不需要再去找這家店的財務負責人。他只需要把這個東西填進去，把門店選擇好，自動跑后面的流程。在財務收到任務提醒之后，把事情處理完，直接再點反饋按鈕，把發票回傳回去，客服人員收到之后直接給客人回復就好了。相當于這是我們用多維表格把原來一套比較長，比較繁瑣，但是很每天有很多種重復型工作的跨部門工作流程給它整個打通。很多原來需要大量電話溝通或者是微信溝通的事情，現在就自動化就完成了。客服人員體驗就非常好，提效確實不少。

第二個是我們產品的研發管理。西貝有兩三百號人的研發隊伍，有九個研發工作室，每個工作室負責的菜系和產品分類又不一樣，但是所有的新菜研發出來之后，或者是老菜改良出來新的樣子之后，最終都得去到我們的食品工程工作室去做檢測。研發工作室同事們，他們每天可能有幾十個品甚上百個品在并行地跑，之前就是靠 Excel 表格統計，每天人為的去篩抓進度或者是推進度，去找人把這個事情確認清楚，進度效率相對來說不是那么理想。現在用多維表格把所有的產品，從研發起點到最終交到食品工程工作室去做檢測，檢測完之后再把結果再反饋怎么樣，也是用多維表格把整套流程搭起來。他起的最大作用就是食品工程工作室的同事可以同時對好多個產品的進度做掌控，他不再需要人工一個一個過，同時每個都會有一個結果，它的進度怎么樣就一目了然。這是我們比較典型的兩個例子。

潘亂 除了多維表格，我看到飛書也推出了項目管理工具飛書項目，這跟多維表格是什么樣的關系？飛書項目是面向誰的？

周琪 簡單解釋一下。表格剛才我們講過了，是一個行列數據庫，它是給業務人員輕松搭建這些應用的。飛書項目跟多維表格最大區別是，飛書項目在多維表格基礎上又加了一個流程管理，你不僅可以把業務定義清楚都有哪些步驟，并且你可以把這些步驟定義清楚流程，而且這個流程是非常靈活可配置的。比如剛才像魏總提到，菜品研發，我們可能有內部特別多的業務流程，我們就把流程配置好，我能同時看到剛才也說的多個任務進到什么程度，可以大大加速我們整個菜品研發管理的效率。

就像剛才多維表格一樣，它可以用在很多業務場景。我們有些產品研發的同事會用在產研的這些項目管理，因為飛書項目最初是字節內部服務抖音做的一個項目管理工具。另外像剛才講的這種餐飲里面的門店開店的管理，菜品研發的管理，包括我們可能跨行業的，包括一些比如銷售流程的管理，只要有復雜業務流程情況下，用飛書項目會更適合去做整個業務流程的提效，整個業務流程的數字化。

飛書集成平臺和飛書應用引擎（aPaaS）的應用場景

潘亂 順著數字化繼續往下聊。飛書業務三件套里的飛書應用引擎和飛書集成平臺，西貝具體會在什么樣的場景里面使用到？

魏骍然 應用集成平臺的話，我們現在把以前我們跟泛微做的審批系統，還有人資管理系統，還有跟用友的合作的財務系統，現在全部都接到飛書里面去了，并且用審批把這些東西都串起來，所以我們現在整個的各項業務和職能的審批管理、工作管理全都在這里面在在跑。另外我們還有一個事情目前正在推，就是把我們自研的門店個人工作臺，看能不能跟飛書集成在一起。

飛書發布會我也去了，我聽海底撈周總講到海底撈一個產品管理，用多維表格，從源頭一直到給顧客出菜，做了一個產品問題的溯源管理，相當于從采購到倉儲到物流到門店到出品全流程，任何一個環節只要出了問題，拍照寫說明，往表格里一填，自動向上一個環節去溯源去。這樣一環一環的溯到最后，到底問題出在哪？是因為今天出品不合格，還是原料質量有問題，直接把流程在這里邊跑起來了。

潘亂 像是飛書應用引擎，跟多維表格是什么樣的關系？是低代碼和無代碼？

周琪 說說我個人理解，其實多維表格像你剛才提到無代碼，更適合給到業務人員去搭建自己所需要的一些基礎的業務系統，這個會非常高效。但 aPaaS 或者是飛書應用引擎，它其實還是給 IT 人員的，因為它本質上是把 IT人員一些復雜的，重復的，基礎的這些開發功能，給封裝起來，你只需要去完成你上游應用層的這些代碼開發，會大幅提升這些開發的效率。他們兩個定位還是有非常明確的差別的。

魏骍然 說到我也補充一下，剛才說到海底撈感觸，漏了個最關鍵的，就是聽他們講完應用之后，我就覺得用多維表格真的就是，我可能不再說是需要依靠程序員大哥們，你有限的時間和精力了。我可能自己把這事我想清楚了，我知道這個東西該怎么弄，我可能自己就搞定了。真的很輕便，但是管用，把很多工作就能優化了。

潘亂 企業的數字化問題不一定都得靠程序員來解決。之前大公司里面可能都是財務、行政、采購這些部門，他們的訴求一般都是先反饋到 IT 部門， IT 部門把它翻譯成他所理解的需求去做落地。現在有多維表格之后，之前那些不具備 IT 能力的公司，或者他原來公司里面不具備 IT 能力的那些從事業務的人，他也可以參與到流程的優化里面去。

周琪 從另一個視角你可以這么理解，很多大企業，它是有特別多的定制開發需求或者業務需求，這個時候它實現方式我會找一些外包公司，或者我有自己 IT 團隊，我可以去開發去實現。但反過來想，我們特別多的中小企業，或者是一些大企業的邊緣的或者創新的部門，它其實沒有這么多資源和實力去做這件事兒。

其實本質上多維表格是滿足了大量的這些部門的業務的需求，他們自己可以去搭，把想法去沉淀在一個表格上。作為一個業務系統，快速的推進業務往前迭代，整個效率效果上都會比原來得到大幅的提升。本質上是滿足了一些業務人員原來的很多需求。

潘亂 有位同學想問一個對于這件事情業務終局的判斷，譬如無代碼開發，它會是一個平民化的嗎？它會是這種主要是一線員工里面的聰明人，還是甲方專家或是乙方專家主導？后面是誰來主導這件事情？

周琪 先說我的理解。如果談終局，可能我們得分三類系統。第一類可能是一個比較垂直的業務系統，比如像 Salesforce SAP，它是非常垂直的一些業務系統。第二類就是我們剛才提到 aPaaS 或者是飛書應用引擎之類的這些低代碼的開發平臺。第三類是我們剛才提到的多維表格，其實它本質上從前到后是一個從專業性到靈活性的一個趨勢的迭代。所以其實在這種專業系統里面，可能確實是由甲方提需求，乙方來主導實現。

飛書應用引擎就在這種低代碼的環節里面，其實我們看到的更多的是甲方跟乙方內部去做這種需求的對接和實現，更多的是提升 IT 的這些研發的效率。回到再往末端，再往這種應用層，再往業務端，像多維表格，它本質上是大幅降低了去搭建業務系統具的成本，所以是由甲方實現。我想清楚了，我馬上可以有個東西去把系統實現出來。所以我們經常有個開玩笑是業務系統次日達，所以甲方還是乙方主導實現，在不同的業務系統上，它的定位還是不太一樣的。

潘亂 公司他來做低代碼是不是有什么前提？如果公司的業務沒有實現標準化的抽象，他的數據也沒有建立統一的標準的時候，它適合來用低代碼嗎？

周琪 回到我剛才講的從專業性到靈活性，如果他們沒有想清楚業務形態是什么，也沒有想清楚流程或者是業務能不能跑得出來，我可能就用這種多維表格無代碼去搭一套就 OK 了。當我想清楚了之后，我希望流程更固化，性能更好，以及實現的這種方式更復雜，我可能不只是基于行列，我還有特別多其他要求的時候，我去用低代碼去搭一個平臺。當然等我業務變得最復雜的時候，我可能是采購一個專業的業務系統。

我們經常跟客戶講的是叫主干清晰，末端靈活。我們看到很多 CIO 大量的時間在救火，把時間花在的都是末端。這些用低代碼無代碼的工具能解決的問題，其實是他們大量花時間的地方。我們把問題幫很多CIO解決掉，大家就可以把這個時間效率給提升，第二讓業務自身的活力更強了。因為我們現在都說市場變化非常快，你怎么可以敏捷地去響應市場的變化和需求？其實除了很多業務的決策之外，我們的工具能不能跟得上，我們的這些實現方式能不能很快速的把業務需求給落出來，其實還是蠻重要。

潘亂 這是低代碼無代碼產品，那像是飛書集成平臺 Anycross這個產品的核心價值是什么？它面向誰？解決什么問題？它是否有能力去鏈接客戶現在已有的這些系統，并且實現數據的交互。

周琪 飛書集成平臺要實現的就是讓數據在企業內部高效流動。字節跳動做得很核心一件事是在做信息的分發，而飛書本身也是圍繞信息分發，讓信息在組織間更高效流動，促進信息給到最合適的人來做業務決策。其中信息一部分就是數據，這個數據除了我們在飛書一些產品內產生的像多維表格，其實很大量的是企業自建的業務系統，集成平臺解決的是這些系統跟飛書的有機結合。我們希望實現的一個目標是讓數據找人。有了這個問題，找到你，直接通過飛書一點，完成。還有很多BI分析，很多任務執行等，都可以通過這些數據的打通來實現一鍵的推送。當數據找人這個事情跑起來之后，你會發現業務效率會提升非常大。

第二個是我們怎么跟現在的企業已有的包括自研的系統做集成。我覺得可以比較確定的回答兩個。第一個是我們會不會長期持續做這件事，答案一定是確定的。第二是我們能不能實現這件事，也是確定的。但實現的方式它是分優先級的，比如我們其實跟不管是SAP、Oracle、 Salesforce 用友，包括剛才魏總提到的泛微等等，我們都實現了一些打通。但是我們也知道這些不同的產品，它是有不同的版本和特別多的接口的，所以實行的過程是需要時間的。我們是把市面上比較常見的應用實現了接口打通。所以大家在用了飛書之后，馬上能實現數據找人、數據流通這么一個效果。當然長期來看，好處是隨著我們服務的客戶越來越多，所以我們建的系統越來越多。隨著我們自己的這些接口的完備性，穩定性、成熟性越高，我們未來可以兼容打通的系統也會越來越多，來幫大家把整個數據串起來，幫大家更好的去實現數據在內部的高效流動。

如何走進千行百業

潘亂 傳統企業的服務都相對比較重的，但對要做數字化底座的公司，他們很多 CSM 都是純互聯網背景的，其實是不懂傳統企業的。譬如像飛書，你做這些工具可能是隨意的拖拉拽，但其實別人他可能點個審批都是要小心翼翼，他其實不敢亂動系統的。當先進工具要跟傳統企業的數字化結合的時候，是不是會碰到這個問題？怎么解？

魏骍然 我說說體感，這種必然會有。你像我們現在還有很多同事說是飛書里一些新的功能，自己也沒掌握，我還是習慣于用一些傳統的。比如我習慣用PPT，尤其一些飛書會議的，它其實很完整。你把文件寫下來以后，用云文檔直接逐頁播放，去線上開會也很好用。但是很多同事，我還是習慣用PPT，我喜歡寫 PPT 或怎么樣的。這種觀念的改變，讓大家邁出第一步是可能比較難的，但真的你邁出這一步之后，對于新的東西接入起來，它也不慢。

所以剛才潘老師說這種沖突，你免不了，但是遇到這種沖突的時候，你就想辦法，就可能更多是靠磨合，想辦法磨合完善沖突，給他磨合掉以后，讓人們去接受或者進入一個新的環境去用它。

周琪 其實魏總提的一個點特別好，大家還是挺抗拒改變的，擔心用不起來或者擔心出問題。我覺得其實飛書在這里其實做了我覺得還比較核心的兩個方向，持續在投入。第一個其實是產品本身，我們在一直降低我們產品的使用門檻，大家可以用，而且可以很清晰的知道這個東西怎么用，不至于，我跟你的業務系統打通了，好像你用了不會用就把系統的數據包括很多流程給搞壞了，這個不會。其實我們也是在產品，讓大家把功能用起來，把產品本身給用起來，以及給用好，其實這塊還是下了非常大的功夫。

我覺得第二個，飛書有特別強的客戶成功團隊。其實我們很多時候要跟哪些系統打通，并不一定是我們自己會懂，而是客戶告訴我們。但我們的好處是在客戶告訴我們之后，我們可以基于我們對飛書的了解，對客戶業務，對客戶系統了解，幫他去實現他想要的效果。而且好處是通過我們服務一個客戶，有了這些實踐，有了這些經驗之后，我們可以把變成一個相對普適的能力，給到行業的更多的客戶，告訴他們其實這樣效率會更高。所以通過讓企業可以安全的拿到自己想要的東西，以及實現更高的價值和效果來去滿足企業的需求，并且把需求很好很平穩地沉淀成經驗。有可能很多時候固化在我們的一些行業通用的服務這些環境里面去，這種是我們持續在做的。

飛書怎么看待合作伙伴？

倪叔 我想請問一下周琪，像你們飛書是怎么去看待合作伙伴的？飛書的三大件其實對很多產品會產生影響。我這次我參加發布會的時候，甚至有朋友跟我說，誒，華為好像也做類似的事情了，包括金蝶還專門發了一個聲明，華為以后雖然跟我們是同行了，但是也會跟我們合作得很好。我們把問題延展一下去看，說飛書怎么去看待它的開放性問題，以及飛書能不能被集成，你覺得？

周琪 說一下我個人理解，其實金蝶回答還挺負責任的。其實在 ToB 領域不像 to C大家競爭非常激烈，你會看到 To B 很多時候大家是一個競合的關系。舉個例子，比如我們也做一些招聘的產品，但我們其實也會跟很多市面上的招聘產品做集成，我覺得大家本質上是一個競合的關系，本質去跟客戶交付的是一個客戶價值，讓客戶真正用產品把價值給做出來。

至于第二個說我們是不是可以被集成，其實我們飛書最強的就是一些開放能力，我們有我們自己的開放平臺，有我們非常多的開放能力。比如鯨準這個產品是給投資人做整個投資管理系統的，其實它的整個系統都是基于飛書的開放能力搭建的，底層是由飛書能力去承載的，而且我們能看到飛書很多這些文檔里面可插入的一些這種第三方的工具，包括我們這些開放平臺實驗能力怎么跟第三方去調用，包括我們未來推出的這些開放引擎就是飛書開放引擎。這些開放平臺其實也會讓大家很好的把飛書給集成到自己的很多業務場景里面去。所以我是覺得長期大家一定是一個競合的關系，而且長期一定是一個集成跟被集成的關系。

倪叔 還有一個問題想問，對KA來說，很多東西是自研的，不好接。另外KA原有的系統，也沒有多少好的SaaS，比如海外的就把salesface 就跟谷歌微軟深度集成，國內可能對方api也沒弄好。海外天生接口被集成，國內沒有很多好的SaaS，也沒有好的集成，兩位咋看這個問題？

魏骍然 我們是想系統越簡便越好，越包容性越強越好，因為我們就吃過這樣的虧。一開始我也說了，我們彎路直路，沒少走。有時候有一個比較緊急的需求，短期內你就要趕緊上線去用，去跑起來，業務這需要。為了完成任務，我們有時候做開發，把它會寫的比較固定，就寫死了，過兩天就有一個新的東西需要跟他配合起來，需要往一塊接。他說發現這不行了，又再重寫一遍。如果大家天然就是插拔式的，或者是開關式的，我們作為使用者來說，當然是希望這就能用的東西都都長這樣。并且是我兩個系統放一塊它都能夠直接通，不用我再等著大家去把接口再做完了再弄。所以這還是從使用者的愿望，這種包容性或者是開放度越高越好。

周琪 我們其實在服務很多 KA 的時候，他有特別多自己的系統，我們也是一方面看怎么去一次性的解一類問題，而不是一個個的解每個客戶單獨的問題，這是我們在每次解問題時候一個大的思考。從另一個層面回答，其實飛書本身做的還是一個投入蠻大時間蠻久的一件事，我們本身也是堅信中國的 SARS 市場會成為一個比較繁榮的狀態。所以我們在整個 API 生態的搭建，包括我們自己接口的這些標準性、穩定性的這些方面，我們其實投入了非常多精力。

我是覺得 To B 它不太像很多 c 端產品會非常快的得到爆發，但我覺得生態的長期共建是我們非常堅持且非常認可的投入方向。當大家慢慢標準趨同，或者慢慢API生態像海外一樣變得非常好了之后，這個時候我們不管是對飛書去服務客戶，包括客戶本身的這些產品體驗也會好起來。只不過可能確實需要時間，但我們還是持續在往這個方向去堅持。

潘亂 我想問，比如飛書想要去切入業務，先從什么再到什么，中間業務思考是怎樣的？因為企業內部的這些管理工具，它其實都是有習慣跟遷移成本的。習慣的人越多，企實遷移的成本越高。

周琪 其實我們也是一直在持續嘗試。這個問題我覺得可以從兩個視角去看。第一個，我們去先做哪些？這些接口的對接可能對客戶的體感或者價值帶來的更強烈。比如我們可能對接了你的SCP，對接你的這些 Salesforce 之后，會讓你整個使用門檻下降，使用體驗提升。包括這種拉群，包括數據的這些吞吐分析等等。我覺得這是一類。

其實第二類，我們也是會遵循行業本身的邏輯，其實每個行業都用哪些系統，哪些系統使用頻次很高，甚至是有哪些 ISV 是相對比較透明的？所以我們只要是按大邏輯，從客戶的這種需求出發，從市場的這些最高優的系統出發，我覺得大方向一定是不會錯的。所以我們也是按這個持續在走，因為隨著飛書走進行業，跟各個行業耦合的越來越深。其實我覺得這是一個長期持續要回答的一個問題，我們也在按這個方式去解。

走進行業，飛書打算走到多深？

潘亂 走進行業，飛書打算走到多深？比如商業航天或者高端制造，或者是汽車行業里面，里面都有非常多的非常專業系統，且國內基本上現在都沒辦法復制。飛書要往業務走，想走到多深，你總不可能這些東西都干吧？

周琪 對，邊界還是相對清晰的。一些行業的專業系統，你會發現飛書是不碰的，比如像剛才提到的 PLM 系統， 包括一些 ERP 等等，其實這些我們是不碰的，我們更多的是希望跟這些系統做鏈接，做數據的打通，做這些流程打通，做一些效率的提效。包括我剛才提到像數據找人，像自動化的通知等等。讓他的系統架在飛書上，把各個煙囪給打通。我覺得這是一個很核心的點，我覺得邊界在這里。

第二個，從我們自身能力出發，其實我們也在給企業很多的靈活性和可能性。因為剛才也提到一個詞叫主干清晰，末端靈活。在我們服務客戶之前，他可能只有主干，他的末端就是那些Excel。但現在我們去服務很多客戶之后，它可以基于飛書應用引擎，基于我們的多維表格來把這些末端，原來這些核心業務系統它無法去實現的這些效果其實給覆蓋掉。這樣對整個企業的組織生命力，對整個數字化的活力其實是大大的激發了。覺得這是我們可能去服務很多行業客戶，真正在發力和真正希望幫客戶解決的問題。

倪叔 魏總，問個您具體的，像從您的實踐經驗出發，有沒有一些更加實際的落地的案例或者做法，可以給大家一些數字化上的建議，讓大家少踩坑。因為你開始講你們其實是直路彎路的，走了很多也交過很多學費的。能不能幫助其他的也想做數字化的企業，看我們怎么樣能把學費少交一點。

魏骍然 正好我看評論區有同學在問西貝覺得飛書哪里最有價值？其實我可以把這兩個事放在一起講。按照我們這么多年趟過來的經驗，數字化絕對不是一個人、兩個人或少數人的事情。企業的數字化轉型一定是全員的事情，尤其是你做數字化辦公轉型的時候，你想一定是大家共同參與，才能夠在短的時間內或者是理想的時間內，把這個事情給它做到理想的狀態。如果你說只是少部分人，大家相當于在轉變的過程中，時間成本、人力成本就不可估量了，并且很多變數你是也沒法控制的，飛書就可以把人和事充分的聯動起來，讓每個人都有機會參與其中，讓數字化辦公與每個人有關，這與飛書的all in one和各個功能細節都有關系，也是我認為飛書價值最大的地方。

我覺得可能行業不同，或者是大家工作習慣不同，比如在互聯網行業可能習慣于快速迭代，可能大家對于這種事情習以為常，但對于我們餐飲行業來說，我們可能習慣于自己本身的業務的快速迭代，但不習慣于數字化工作這種新環境適應的快速迭代。如果有別的企業要進行整個工作模式的數字化升級改造，一定是強有力的去組織做全員的參與，這樣讓會讓事情順利很多，也會能更及早更快的暴露一些問題，讓大家去解決它，最終把這個事情去弄好。

周琪 對，其實你會發現我們很多業務系統，它其實是給一個企業的少部分人去用的，但飛書是給一個企業全部的人去用的。其實這一點就會讓很多不管是溝通方式，甚至構建企業文化，包括其實大家發動起來做件事會變得更簡單。其實基礎對整個企業做事情還是蠻重要的。

潘亂 我理解到最后幫飛書貢獻收入的，其實大部分也都還是 KA。我有一個問題好奇，中國值得做的 KA可能也就大幾千家，能夠支撐起規模收入的可能不到 1 萬家。類似于這種新經濟客戶，有些品牌輻射的以及愿意付費的用戶，就是這一類的甜點用戶飛書是不是已經吃了不少？下面還能再往什么方向去走，去拓展？

周琪 說我個人一些理解。其實飛書整個商業化也就三四年的時間，剛才講到中國可能就大幾千家這些 KA 客戶，對我們來來說 KA 客戶的數量遠還沒有這么多，我們還有特別大的空間去增長，我們要持續地不斷地去獲取更多的 KA 客戶的信任，去給大家帶來價值。

第二，其實不光是這些頭部的客戶，其實飛書也服務了巨量的中小型的企業。我們很多中小的客戶，其實剛才講到把多維表格當自己的業務系統，比如真正用飛書項目把自己可能業務流程管起來，把自己研發效能去提升，其實這些都是非常常見的，所以在中小企業我們也是有自己的商業化團隊，再去服務這類的客戶。

但第三個，飛書發布會上也提到，飛書本身也一直在看海外的機會。因為字節跳動本身也是一個全球化的公司，我們在海外很多地區也有我們自己海外的 Lark 產品在去做海外的商業化，其實我覺得對我們而言還是能看到大量的機會，以及大量的成長空間，只是我們還要繼續努力把這些事情給做得更好。

潘亂 可能十個公司就有 10 種不同的管理思路跟流程。如果你要真的要去拓展非常非常多客戶，你怎么去抽取這一些通用的、規范的流程，幫助這些公司去做提效呢？可能中小客戶不知道自己要什么，中大客戶可能覺得自己也很牛逼，覺得數據都是機密不愿意 SaaS， 大型客戶肯定妥妥就自研了，人家要搞定制。

周琪 其實說實話，這個確實是我們在商業化過程中遇到的問題，但實際上目前解的都還挺好的。因為你如果看現在飛書的客戶已經是來自各行各業了，每個行業對飛書用法其實差異還是蠻大的。我們服務的有像餐飲領域的客戶西貝，有像醫療器械的企業聯影，其實你會發現大家用的是非常不一樣，我們怎么能去滿足大家各行各業不同的需求？本質上我覺得還是做兩件事情。

第一件事情是明確邊界。我們一定是做我們自己擅長的，然后不擅長的，或者是更專業的。我們來去做數據的打通和集成。所以從我們看去服務客戶，我們會服務很多所謂的不同行業的通用場景。我舉個最簡單例子，大家都要開會，我們把這個場景能不能做極致對吧？大家都想寫文檔等等。我覺得這是第一個通用。

第二，我們其實還會服務很多核心的業務場景，每個行業業務場景它的做法還是挺不一樣的。而這個時候其實就需要兩個能力。第一個是我們靈活的跟客戶的業務場景去結合的能力。不管你基于我們的多維表格，我們的飛書應用引擎，包括我們的這些飛書繼承平臺的能力去繼承，去解決業務場景提效。還有我們一個很核心的是我們有我們的客戶成功顧問去深度的提升的服務客戶，幫他把這些場景的效率給提升，把場景價值給做出來。我覺得持續沿著這兩個方向走，在我明確我們邊界基礎上，其實你會發現在剛開始我提的飛書在每個行業怎么用，其實是客戶在教給我們的，它一定不是互聯網公司的用法。

團隊人數為什么這么多？

倪叔 我想順著這個話題我們再聊一個問題。重服務其實是飛書非常重的一個標簽，一方面它帶來了客戶的體驗很好，但另一方面它帶來了很重的團隊服務成本，你們怎么去看待這一種取舍？業內在去年其實有一個很大的討論，在講飛書的人員的問題，甚至出現過一個說法，拼多多才 7000 人，飛書為什么需要 8000 人？但是我覺得它是放在一個不同的視角去看的。對于飛書來說，是 DAU 這個事更重要，還是 ARR 這個事更重要？我們外部應該怎么去理解飛書這家公司？

周琪 我先說一下我個人理解。其實在發布會上謝欣也大概解釋一下這個問題，飛書其實有幾千人，但你如果看全球最大的這種 ToB 的公司，都有幾萬人，其實我們還有很大的成長空間，因為我們也會做更大的市場。我覺得從另一個維度，如果我們講飛書，整個服務團隊的這些效率，我們還是回到一個企業，長期一定是需要去關注自己的盈利能力，要不然其實你很難去構建一個很好的生態，你可能周圍的這些合作伙伴不會去跟你玩得很好。所以其實從這個角度，其實本身我們的盈利能力是在持續提升的，我們服務的客戶的這種效率也是在持續提升的。

當然為什么早期會鋪那么重，其實我覺得本質上還是因為你在走進不同的行業，你有非常大的學習的成本。你的客戶怎么用飛書，怎么去幫他把這些業務給做得更好，需要我們去深入客戶去把這些事情做出來。但反過來就是當這個事情做到一定程度，其實后面的邊際效應也就會比較高了。我們整個產品的適應性，整個產品的所謂的通用性、靈活性，也會得到更強的這些保障。這樣我們再去服務新的客戶的時候，其實我們的整個服務的這些專業程度，甚至我們服務的這些效率，都是會得到大幅的提升的。