一個 AI = 1000 個客服？2100萬美元融資，這家丹麥創業公司憑什么讓 Perplexity、Replit 搶著用？

你有沒有想過,客戶支持這件事可能徹底變了?當 Perplexity、Replit、Framer 這些全球頂尖的 AI 公司都在使用同一個客戶支持系統時,我開始意識到這個領域正在發生一場革命。更讓我震驚的是,這個系統不僅僅是回答用戶問題,它還被授權直接處理退款、訪問公司的 Stripe 賬戶、在沒有任何人工監督的情況下移動資金。這聽起來像科幻小說,但這正是 Parahelp 正在做的事情。

最近,這家由兩位丹麥年輕創始人打造的公司宣布完成了 1800 萬美元的 A 輪融資,由 Alt Capital 的 Jack Altman 領投。加上此前 320 萬美元的種子輪,Parahelp 總共融資超過 2100 萬美元。更有意思的是,他們的客戶流失率為零。是的,你沒看錯,零流失率。在 SaaS 領域,這幾乎是不可能完成的任務。這讓我非常好奇:他們到底做對了什么?為什么那些本身就擅長構建 AI 系統的頂級 AI 公司,會選擇使用 Parahelp 而不是自己開發?

從音樂 App 到 NFT 投資平臺的探索之路

我一直相信，偉大的創業故事往往始于一些看似不相關的早期探索。Anker 和 Mads 的故事也不例外。Anker 在丹麥一個只有 200 人的小村莊長大，那里除了戶外活動，幾乎沒有其他娛樂方式，這反而讓他很早就開始接觸編程。而 Mads 則在中學時期就創辦了自己的時尚公司，負責設計和營銷。兩人在高中時期通過一個朋友相識，共同創立了一個面向丹麥年輕創業者的組織，將對創業感興趣的高中生聚集在一起。這個決定改變了他們的人生軌跡。

在丹麥，創業文化遠不如硅谷那樣濃厚。事實上，丹麥語中甚至沒有"創業公司"這個詞匯，人們只會問"你的項目進展如何"。這種文化差異讓 Anker 和Mads 在學校里顯得格格不入。一旦他們發現了創業和編程的魅力，就很難再集中精力上課。他們開始合作開發各種消費類應用。Anker 負責編程，Mads 則負責設計和產品，這種分工一直延續到今天。

他們開發的第一批產品包括一個音樂應用，用戶可以在活動現場實時創建協作播放列表。為了實現這個功能，他們甚至逆向工程了 Spotify 的 API。他們還開發了一個活動發現應用，雖然這個想法并不新穎，但卻被附近所有高中的學生使用。這些早期項目雖然沒有帶來商業成功，但培養了他們對打造優秀產品的熱愛，也讓他們積累了寶貴的技術和產品經驗。

在高中最后一年，Anker 已經開始學習 Solidity 編程，當 NFT 市場開始爆發時，他們的朋友們都在詢問如何購買 NFT，但流程太過復雜。雖然他們自己并不熱衷于交易 NFT，但他們看到了一個有趣的產品機會：讓非技術用戶也能輕松購買 NFT。這個想法最終成為了他們的第一個正式創業項目。

在 Anker 高中畢業后，Mads 還有一年才畢業，他們搬進了哥本哈根一家麥當勞樓上的一個小辦公室。Anker 甚至在那里睡了一段時間。他們開發了一個投資應用，成為第一家在歐洲與 Stripe 合作的公司。經過多次嘗試說服 Stripe 理解他們的系統運作方式后，他們終于實現了用戶可以通過 Apple Pay 購買 NFT，而他們的系統會處理所有技術細節。

但他們很快就學到了殘酷的一課。當他們終于通過監管審核并推出產品時，NFT 市場已經從數百萬用戶萎縮到只剩幾千人。更糟糕的是，他們此前并沒有真正與用戶交流。當他們開始與剩余的用戶對話時，發現這些用戶只關心市場漲跌，對他們精心打造的產品功能并不感興趣。他們無法控制市場走勢，這意味著他們的產品前景黯淡。

兩年的瘋狂 Pivot 之旅

面對失敗，Anker 和 Mads 展現出了超越年齡的成熟。他們沒有固守原有想法，而是進入了全面 Pivot 模式。我認為這種快速調整方向的能力，是優秀創始人最重要的特質之一。很多創業者會因為沉沒成本而繼續投入到一個明顯不可行的方向上，但 Anker 和 Mads 從一開始就建立了一套系統化的 Pivot 方法。

他們受到另一家 YC 公司 Slope 的啟發，采用了一種"三周沖刺"的方法。每個新想法只投入三周時間去嘗試，這樣即使失敗了，沉沒成本也不會太大，同時也能讓他們有勇氣嘗試那些看起來可能很愚蠢的想法。如果某個想法最終沒有繼續推進，他們會寫一份事后總結，強迫自己真正去構建和銷售一些東西，而不是停留在空想階段。

在這個過程中，他們第一次來到舊金山，訪問了一些黑客屋，并立刻愛上了硅谷的創業氛圍。2024 年 1 月，當時 Anker 21 歲，Mads 只有 18 歲，他們搬進了伯克利的一個黑客屋。在那里，他們遇到了 same.dev 的團隊，這些人說服他們申請 Y Combinator。這個決定成為了他們創業旅程的轉折點。

在黑客屋里，他們開始探索 B2B 領域，最初開發了一個 co-pilot 工具并成功進入 YC。但在 YC 的 retreat 期間，他們發現雖然有客戶在使用他們的產品，但客戶并不真正滿意，銷售周期也很長，因為人們感受不到迫切的痛點。就在這時，Claude Sonnet 3.5 發布了，這個模型的出現讓半可靠的 agentic 變革成為可能，至少在他們的測試中是這樣。

這促使他們在 YC 批次中期做出了一個大膽的決定：全力投入端到端解決支持工單的方向。Mads 在一周內發送了 700 封個性化的冷郵件。他們的早期客戶，包括 Captions 和 Perplexity，都是通過冷郵件獲得的，因為他們在硅谷幾乎沒有任何人脈。他們向所有他們認為很酷的公司發送郵件，然后很快意識到，如果專注于軟件創業公司，他們可以打造一個更好的產品。這些公司有共同的痛點：都需要與各種工具深度集成，都面臨著快速增長帶來的知識管理問題。

Parahelp 的核心價值：不只是回答問題，而是解決問題

當我深入了解 Parahelp 后，發現它與市場上其他 AI 客服解決方案有本質區別。大多數 AI 客服系統只是回答問題，但 Parahelp 的 AI agent 會實際采取行動來解決客戶的問題。這種區別看似微小，實則是一個巨大的跨越。

舉個最典型的例子：退款請求。當客戶提出退款請求時，傳統的 AI 客服可能會告訴客戶退款政策是什么，或者說"我會幫您聯系相關部門"。但 Parahelp 的做法完全不同。它會首先理解公司設定的退款標準，判斷這個客戶是否符合退款條件。如果符合，Parahelp 會直接連接到公司的 Stripe 賬戶，處理退款操作。沒錯，Parahelp 實際上連接了公司的銀行賬戶，被授權在無需任何人工監督的情況下代表公司轉移資金。

這聽起來可能有些激進，但 Parahelp 在這方面做了充分的考慮。對于敏感操作，他們設置了 Slack 審批流程。AI agent 會說"我剛剛請求了一位團隊成員審查這個問題，稍后會回復您"。但因為他們把 agent 設計成像真實人類客服那樣工作，agent 知道有一個待審批的請求正在處理中，所以它會繼續與客戶聊天，回答其他問題。當計費經理在 Slack 中批準操作后，agent 就會執行必要的操作并跟進客戶。

更有意思的是，對于某些客戶的某些計費操作，Parahelp 在一段時間內達到了 99% 的成功率后，甚至不再需要人工審批。這種從需要監督到完全自主的演進，就像人類客服的成長路徑：從處理小客戶開始，隨著經驗積累和可靠性提升，逐漸被信任處理更重要的客戶。

Parahelp 的客戶名單讓我印象深刻：Perplexity、Replit、HeyGen、Framer、11 Labs、Photoroom 等等，幾乎都是最快速發展的 AI 原生公司。Perplexity 竟然是 Parahelp 的第二個客戶，這發生在他們 YC 批次期間。一些客戶甚至已經授權 Parahelp 處理擁有上千個席位的企業客戶，這可能是一個六位數的大客戶。讓 AI agent 與這樣重要的客戶對話，顯然需要極高的信任度。

我特別好奇一點：這些 AI 原生公司本身都在構建 agentic 系統，為什么他們不自己開發客戶支持 AI，而是選擇使用 Parahelp？Anker 和 Mads 給出的答案很有說服力。大多數公司都會嘗試自己構建或啟用現有工單系統中的默認 AI 功能，比如 Intercom、Zendesk 或 Front 自帶的 AI。但這些系統在開始時效果很好，處理那些不需要工具調用的簡單問題沒有問題。但隨著時間推移，問題就暴露出來了。

這些系統并不是為快速增長的軟件公司的知識管理而構建的。它們默認不會連接到公司的所有知識源：Linear 中的技術信息、Notion 中的文檔、Retool 中的內部工具、Slack 中的討論。而這些信息每天都在變化。由于沒有人真正維護這些 AI 系統，它們的解決率會逐漸下降。更糟糕的是，客戶可能會因為過時的信息而獲得糟糕的體驗。沒有內置的審查系統來監控 AI 的表現。

工具調用聽起來可能很簡單，很多其他 AI 支持解決方案也聲稱支持工具調用。但深入了解后會發現，工具調用遠不止是調用 API 端點那么簡單。它需要適當的護欄機制，需要建立完善的評估系統，確保當你能訪問 Stripe 這樣的敏感工具時，它應該始終被正確調用。Parahelp 在工程方面花費最多時間的就是建立評估系統：如何運行評估，如何持續運行評估以確保系統沒有退化。

從手動監控到自動化評估的演進

Parahelp 的成長歷程讓我看到了 AI agent 公司在擴展過程中必然面臨的挑戰。在最開始，他們接入了第一個客戶 Captions AI，一周后又接入了 Perplexity AI。這一切都發生在他們 Pivot 后的四周內。由于一切都還不確定，他們必須手動觀察每一個工單處理過程，試圖弄清楚如何運行適當的評估，以確保 agent 朝著正確的方向發展。

但隨著客戶數量增長，這種方式顯然無法持續?，F在 Parahelp 每天處理數千個支持工單和查詢。他們根本不可能手動監控這些。所以他們必須建立自動化系統。我認為這是所有 agentic AI 公司都會面臨的共同挑戰：如何從手動監督過渡到自動化評估和優化。

更大的挑戰還在于，客戶的需求總是在變化。每當客戶推出新功能、修復 Bug 或更新政策時，Parahelp 的 agent 需要立即了解這些變化。這就像是一個移動的靶子，你需要不斷調整才能保持準確性。大多數嘗試自建系統的公司會發現，即使他們擅長 AI 技術，也很難維持評估的持續通過、避免系統退化，以及時刻與產品、工程、營銷和銷售團隊保持同步。

這就是為什么 Parahelp 能夠成功的關鍵原因之一。他們不僅構建了一個能解決復雜問題的 AI agent，還構建了一整套系統來確保這個 agent 能夠隨著客戶業務的發展而不斷進化和優化。這不是一次性的技術實現，而是一個持續運作的智能系統。

Forward Deployed Engineering 的自動化革命

在去年夏天，Parahelp 遇到了一個嚴重的瓶頸：他們無法招聘足夠的工程師來為所有想使用 Parahelp 的客戶提供 forward deployed engineering 服務。Forward deployed engineering 是硅谷過去兩年最熱門的趨勢之一，指的是工程師深入客戶現場，了解客戶的具體需求，然后為客戶定制解決方案。

這種方法的問題在于它不具備規?；芰Αnker 和 Mads 意識到，他們可以嘗試大量招人，但他們并不擅長建立一個以執行和運營為主的組織。他們的優勢在于打造產品。他們想招聘的工程師也更擅長打造產品，而不是做大量手動工作，更像是顧問而非工程師。

他們想要保持小團隊規模，同時實現極快的增長。這看起來幾乎是不可能的任務，直到 Claude Opus 4 的發布改變了一切。他們花了整個夏天的兩個月時間，暫停了增長，完全重建了他們的 agent 架構。Opus 4 是第一個在他們的內部基準測試中具備足夠智能，能夠動態生成評估集的模型。

這意味著什么？本質上，他們構建了一個 AI forward deployed engineer。它能夠替代之前需要 Parahelp 員工完成的工作：與客戶交談，了解需求，然后更新系統。自從推出這個系統后，他們再也沒有編寫過任何定制的評估集，因為他們的 agent 會為客戶自動完成這些工作。

我認為這可能代表了 forward deployed engineering 的下一代演進。對這種模式的批評一直是它無法規?；５绻械?forward deployed engineer 都是 AI agent 呢？那么規?；筒辉偈菃栴}了。Parahelp 從編碼 agent 的設計中汲取了大量靈感，特別是兩個關鍵要素：能夠運行確定性代碼，然后讓 agent 進行優化，這樣它就可以工作更長時間；以及擁有一個審查系統。

現在 Parahelp 的 agent 可以輕松工作 30 到 40 分鐘來優化自己的策略，運行測試，然后進行審查。這兩個特點讓他們能夠處理比簡單問題復雜得多的場景。Opus 4 能夠管理所有這些復雜的上下文，并推理如何改進系統。

Parahelp Assistant：AI 驅動的持續優化引擎

Parahelp 最近推出的新架構包含兩個核心 AI agent：Parahelp Agent 和 Parahelp Assistant。Parahelp Agent 直接在客戶的工單系統中工作，處理實際的客戶支持請求。而 Parahelp Assistant 則是一個更加革命性的創新，它讓客戶能夠快速設置 Parahelp，構建和優化策略，設置工具，并在發布到生產環境之前徹底測試所有內容。

Assistant 的設置過程非常簡單?？蛻糁恍枰?Parahelp agent 發送一個電子郵件邀請，就像邀請一個新員工加入工單系統一樣，然后系統就上線了，不需要工程師安裝任何 SDK 或連接任何渠道。這種極簡的設置流程是 Parahelp 能夠快速擴展的關鍵因素之一。

但真正讓我印象深刻的是 Assistant 的智能優化能力。在過去六個月里，Parahelp 的客戶選擇他們主要是因為他們能解決復雜的工單。但這也意味著在接入客戶時需要運行大量復雜的評估。由于模型還不夠智能，很多情況下需要手動完成這些工作。他們會通過內部工具運行評估來優化 agent，如果需要修復任何問題，他們常常需要進行 prompt 優化。這種 forward deployed engineering 的方法效果不錯，但也意味著他們需要為每個客戶編寫大量無法復用的定制 prompt 優化。

隨著客戶增長和需求激增，他們發現自己在快速設置和保持高解決率方面開始落后，除非雇傭大量人員為每個客戶做定制工作。作為非常注重產品的創始人，他們不喜歡這種方式。然后 Opus 4 發布了，他們意識到可以暫停增長，重建 agent 架構。

現在，Parahelp 有了一個研究 agent，它可以一次搜索多達 20000 個工單，然后用多個子 agent 來管理上下文，仔細分析通常 50 到 500 個工單。它會打開完整的工單內容，當然會移除所有敏感信息，然后分析 AI agent 是如何處理的、何時轉交給人工、人工是如何處理的。最后它會提供一份詳細的研究報告，附帶來源和分析的所有工單，然后主動提出改進建議。

更酷的是，這些改進建議可以由支持經理直接在同一個會話中實施，只需要提示 agent："請實施這個建議，我剛添加了這個工具，請制定一個策略來調用這個工具以填補知識空白。"或者研究 agent 會自動查看人工客服如何回復類似問題，然后說："看起來我們需要有這個策略，人工客服就是這樣做的，我認為通過這個策略我可以多解決 5% 的工單。"

這創造了一個持續的優化循環。你可以發現人工解決工單的模式,然后配置和測試這些模式并發布它們,讓這個持續的循環在任何時候都能優化 agent 能夠處理的工單數量。自從兩周前為 Perplexity 推出這個系統并建立這個自動化飛輪后,他們的解決率提高了 12 到 15 個百分點,因為團隊實際上已經做出了 250 多次發布。這相當于 10 名以上的團隊成員能夠根據他們的專業領域進行發布。

從客戶支持到收入增長引擎

Parahelp 的愿景不僅僅是自動化客戶支持,而是將支持系統轉變為公司的收入增長引擎。我認為這是一個非常前瞻性的思考方式。傳統上,客戶支持被視為一個成本中心,企業總是希望盡可能降低支持成本。但 Parahelp 看到了不同的可能性。

他們即將推出的一個功能特別讓我興奮:批量跟進工具。假設客戶想知道為什么他們的待辦事項中有 700 個未解決的學生折扣相關工單。Parahelp Assistant agent 會分析這個情況,確定需要哪些端點、如何驗證、應該如何回應,然后不僅為未來的類似工單建立策略,還會問:"我應該跟進所有這 700 個工單嗎?" 一旦獲得批準,它就會在工單系統中生成大量 Parahelp agent 來處理這些工單。

更進一步,這個批量跟進功能結合研究能力和所有系統的上下文后,Parahelp 實際上可以開始充當客戶成功經理的角色,向客戶追加銷售或聯系已流失的客戶告訴他們新功能。每當客戶推出新功能或修復 Bug 時,研究 agent 會自動提示他們:"我們應該跟進每一個曾經要求過這個功能的客戶嗎?" 然后它可以啟動這個 agent 說:"嘿,這個功能現在在我們的 Pro Plus 計劃中可用了。"

這是一個超級智能版本的客戶關系管理,能夠回溯并回復過去兩年中所有詢問過某個功能的人,現在你終于發布了這個功能。對于某些客戶,Parahelp 已經解決了數十萬個工單,這意味著 Parahelp agent 擁有數十萬個潛在客戶的郵箱,這些客戶可能被追加銷售到商業計劃或顯著擴展。但普通團隊沒有資源或全局視角來做到這一點。

Parahelp 還推出了一個工具,讓 agent 可以在客戶流失前給予折扣,或者發送追加銷售鏈接?？蛻艨梢暂p松定義他們想要的策略,突然之間,這不再只是成本節約,而是實際的收入生成。我問 Anker 和 Mads,Parahelp 的價值主張有多少是關于降低雇傭人類客服的成本,有多少是關于做一些用人工根本無法做到的事情,比如通過以前無法規模化的追加銷售方式來增加收入。

他們的回答很明確:主要是后者。由于他們只專注于快速發展的軟件公司,在很多情況下,這些公司今天并沒有龐大的支持團隊。支持成本本身并不是特別大。但如果他們必須跟上業務增長,支持成本就必須變得很大,因為他們必須雇傭很多人。所以更多的是實施 Parahelp,然后 Parahelp 成為他們本來需要雇傭的 100 個客服。而且由于所有這些 agent 擁有統一的大腦,它們不僅具有一個可以 24/7 工作的單一 agent 的影響,而且具有如果所有處理特定工單的 agent 都擁有統一大腦并能做各種事情的影響。

Parahelp 如何成為公司的知識中樞

一旦公司接入 Parahelp,一個有趣的現象就會發生:Parahelp 開始在公司內部傳播開來。因為對于快速發展的軟件公司來說,支持系統實際上是知識的大腦。公司員工開始把所有的知識轉儲和信息都導向 Parahelp Assistant,而 Assistant 也會主動提示他們提供更多知識。

很快,Parahelp 中就會有數百頁只存在于 Parahelp 系統中的知識。他們遵循的一個原則是讓公司員工極其容易訪問這些知識。所以他們為銷售、工程、企業和客戶成功團隊創建了"Ask Parahelp"頻道,甚至為仍在回答問題的支持代理創建了類似 co-pilot 的頻道。

對于某些客戶,這些頻道中有數百名員工,他們只是在向 Parahelp 提問,基本上把它當作支持團隊以前作為資源提供服務的延伸?，F在有了深度研究功能,他們不僅能夠問"請告訴我如何將解決率提高 10%"這樣的問題,產品團隊、工程團隊和領導團隊實際上還可以問"我們的退款在過去一個月里是如何演變的,這與情緒、新功能或 Bug 有什么關聯",然后找出如何通過遵循 Parahelp 提供的洞察來將退款百分比減少 20%。

這些洞察來自于 Parahelp 能夠交叉比對退款分析數據和實際的客戶對話,甚至包括產品反饋。如果他們推出了一個新功能并想了解客戶對該功能的反應,他們也可以從中發現模式。產品團隊可以使用這些作為改進新功能的參考?；蛘咴诠δ苷埱笾邪l現模式,看到很多客戶都在要求構建某個功能,那就應該優先考慮這個功能,因為現在有數據支持。Bug 報告也是同樣的道理。

Parahelp 變成了一個在整個組織中部署更廣泛的工具,因為在很多方面,這是軟件公司特有的,但對于軟件公司來說,支持確實是客戶知識和產品知識的中心,是組織其他部分大量工作的起點。

結尾

也歡迎大家留言討論，分享你的觀點！

覺得內容不錯的朋友能夠幫忙右下角點個贊，分享一下。您的每次分享，都是在激勵我不斷產出更好的內容。

歡迎關注深思圈，一起探索更大的世界。

- END -

兩個“特別坑”的AI產品創業方向，你知道嗎

速度將成為AI時代唯一的護城河

a16z重磅預測：Vibe coding贏者通吃？錯了，垂直專業化才是未來