Laravel 客製 CRM 開發實戰：把業務流程從套裝軟體手裡拿回來

是公司在用 CRM，還是 CRM 在綁架公司的業務流程？這幾年我最常聽到的企業主抱怨不是「網站跑不動」，而是「這套 CRM 真的超難用」——套裝軟體要你削足適履，把流程改成它的樣子。這篇用 Laravel 客製 CRM 的開發實戰，示範怎麼把業務流程的主導權拿回來。

現在是 2026 年，市面上的 SaaS CRM 雖然功能強大，但往往這也成為了致命傷。你為了一個簡單的報價流程，可能要點擊七次滑鼠；或者是為了配合軟體的邏輯，強迫業務團隊改變原本高效率的工作習慣。這就像是買了一件不合身的西裝，還要削足適履去穿它，怎麼想都不對勁吧？

今天這篇文章，不談高大上的理論，我們來聊聊如何利用 Laravel CRM 開發實戰，打造一套真正屬於你、貼合你流程的業務系統。說實話，這可能是你今年最值得的技術投資。

為什麼 2026 年你該考慮用 Laravel 自建 CRM？

我知道你會說：「Eric，Salesforce 或 HubSpot 不好嗎？」它們很好，但它們是為了「通用需求」設計的。當你的企業規模達到一定程度，或者你的商業模式比較特殊（例如 B2B2C 混合、或是需要高度整合物流與產線）時，通用的 SaaS 就會變成一種束縛。

選擇 Laravel 開發 CRM 的幾個核心理由：

• 資料主權與安全性： 2026 年，資料就是石油。自建系統讓你擁有 100% 的資料庫控制權，不用擔心 SaaS 平台漲價或條款變更。
• 流程完全客製： 你的業務流程是 A -> B -> C，系統就該這樣設計，而不是強迫你走 A -> Z -> B。
• 開發速度與生態系： 隨著 Laravel 12（及後續版本）的演進，加上 FilamentPHP 這種強大的 Admin Panel 工具，開發一套後台的速度已經快到不可思議。
• 長期成本： SaaS 是租房，自建是買房。雖然初期開發成本高，但長期維護成本通常低於按人頭計費的 SaaS 訂閱費。

架構設計：別急著寫 Code，先畫流程圖

很多工程師（包含年輕時的我）拿到需求就想開 VS Code。但在做 CRM 時，這絕對是災難。Laravel CRM 開發實戰的第一步，是「業務邏輯拆解」。

1. 定義你的核心實體 (Entities)

一個標準的 CRM 至少包含以下幾個核心 Model，但在客製化系統中，我們通常會加入更複雜的關聯：

• Lead (潛在客戶)： 尚未確認意願的名單。
• Contact (聯絡人)： 具體的對口窗口。
• Organization (公司/組織)： B2B 的核心單位。
• Deal (商機/交易)： 正在進行中的銷售案。
• Activity (活動)： 電話、會議、Email 紀錄。

在 Laravel 中，利用 Eloquent 的多型關聯 (Polymorphic Relationships)，我們可以讓 `Activity` 輕鬆掛在 `Lead`、`Contact` 或 `Deal` 底下。這在 2026 年的開發中是標準起手式，避免資料庫欄位一大堆 NULL。

2. 狀態機 (State Machine) 的設計

業務流程的核心就是「狀態的流轉」。從「新建商機」到「報價中」再到「成交」。不要用簡單的字串或 Enum 來管理，我建議使用像 `spatie/laravel-model-states` 這樣的套件，或是自行設計 State Pattern。

這不僅是為了程式碼乾淨，更是為了讓業務流程「防呆」。例如：一定要上傳報價單（PDF），狀態才能轉為「等待簽核」。

實戰程式碼：打造彈性的 pipeline 邏輯

這裡我們來看一段經典編輯器友善的程式碼範例。假設我們要設計一個 Service，用來處理商機階段的轉換，並自動觸發後續的自動化任務（例如通知主管、寫入 Log）。

在 Laravel 12+ 的環境下，我們可以這樣寫：

namespace App\Services\CRM;

use App\Models\Deal;
use App\Events\DealStatusChanged;
use App\Exceptions\InvalidStageTransitionException;
use Illuminate\Support\Facades\DB;

class DealPipelineService
{
    /**
     * 處理商機階段轉換
     * 
     * @param Deal $deal
     * @param string $newStage
     * @return Deal
     */
    public function transitionStage(Deal $deal, string $newStage)
    {
        // 1. 驗證轉換邏輯 (例如：不能從 '新建立' 直接跳到 '已成交')
        if (!$this->isValidTransition($deal->stage, $newStage)) {
            throw new InvalidStageTransitionException("無法從 {$deal->stage} 轉換至 {$newStage}");
        }

        return DB::transaction(function () use ($deal, $newStage) {
            $oldStage = $deal->stage;
            
            // 2. 更新狀態
            $deal->update(['stage' => $newStage, 'stage_changed_at' => now()]);

            // 3. 觸發事件 (讓 Listeners 處理通知、Email 或 Webhook)
            event(new DealStatusChanged($deal, $oldStage, $newStage));

            // 4. 自動化：如果是成交狀態，自動產生合約草稿
            if ($newStage === 'won') {
                $this->generateContractDraft($deal);
            }

            return $deal;
        });
    }

    protected function isValidTransition($from, $to)
    {
        // 這裡可以讀取設定檔或資料庫中的流程規則矩陣
        $rules = [
            'new' => ['qualified', 'lost'],
            'qualified' => ['proposal', 'lost'],
            'proposal' => ['negotiation', 'lost'],
            'negotiation' => ['won', 'lost'],
        ];

        return in_array($to, $rules[$from] ?? []);
    }

    protected function generateContractDraft(Deal $deal)
    {
        // 呼叫 PDF 產生服務...
        // 這是客製化 CRM 的精髓：自動化那些瑣碎的事
    }
}

看到這段 Code 的重點了嗎？我們把「狀態轉換」變成了系統中的核心邏輯，而不是讓業務在資料庫裡隨便改欄位。這就是客製化系統的價值——強制執行企業的最佳實踐 (Best Practices)。

UI/UX 的選擇：FilamentPHP 是你的好朋友

以前開發後台 UI 是最痛苦的，要寫 Blade、又要搞 Vue/React，還要切版。到了 2026 年，如果你還在手刻這些，真的太沒效率了。

我們在浪花科技的專案中，大量使用 FilamentPHP。它基於 TALL stack (Tailwind, Alpine.js, Laravel, Livewire)，能讓你用 PHP 程式碼「寫」出漂亮的後台介面。

你可以只用幾行程式碼，就產生一個帶有搜尋、過濾、匯出功能的強大表格。這省下來的時間，可以讓你專注在「業務邏輯」和「API 串接」上，而不是在調 CSS 的 margin。

與 WordPress 及外部系統的整合

通常會找我們做 Laravel CRM 的客戶，官網大多是用 WordPress 架設的。這時候，Laravel 的 API 能力就派上用場了。

想像一下這個場景：

1. 客戶在 WordPress 官網填寫諮詢表單（Gravity Forms 或 Contact Form 7）。
2. 表單透過 Webhook 瞬間傳送到你的 Laravel CRM API。
3. CRM 自動判斷來源（Google Ads, FB, SEO），建立 Lead，並根據地區自動指派給對應的業務。
4. 業務的手機立刻收到 LINE Notify 通知（透過 CRM 觸發）。

這種無縫接軌的體驗，是通用型 SaaS 很難透過簡單設定就做到的，尤其是當你需要複雜的「自動指派邏輯」時。

從「記錄工具」進化為「戰情中心」

傳統 CRM 只是業務的「填表地獄」。但在 2026 年，自建 CRM 應該結合 AI 能力。你可以整合 OpenAI 或本地部署的 LLM（例如 OpenClaw），對每一筆業務的對話紀錄進行情感分析，或者自動生成跟進信件草稿。

當系統能夠幫業務「省事」，而不是「找碴」，他們才會願意用。這才是系統導入成功的關鍵。

結論：這是資產，不是費用

開發一套 Laravel CRM 確實需要初期投入，但請把眼光放遠。當你的競爭對手還在受限於 SaaS 軟體的功能限制，或者為了每個月高昂的訂閱費頭痛時，你已經擁有一套隨時能隨著市場變化而調整的數位武器。這，才是真正的數位轉型。