屏果園
LCD 零件廠的自家網購:料號自動上架,講不出型號也找得到貨

- 種商品自動上架
- 1,000+
- 種商品自動上架
- 秒網站打開的速度
- 1.5
- 秒網站打開的速度
做 LCD 面板和電子零件的工廠,以前報價靠 Email 一來一回。現在 ERP 裡的料號自動同步成商品頁,客戶自己搜、自己比、一次詢十幾個料號;講不出型號,就用口語問 AI 助理找貨。
實際情境
- 客戶講不出精確型號,只說「要 15.6 吋霧面的面板」,業務來回猜半天。AI 助理用口語就能找貨,附照片也行(可上傳多張);只依系統實際資料回答,查不到就說查不到,不會亂編,也沒有任何修改資料的權限。
- 客戶一次要問十幾個料號,信件寫成一大串,漏看一項就漏報一項。比較清單一鍵送出詢價單,後台自動整理成表格逐項報價;回覆同步進客戶聊天室並寄通知信——不漏項、不漏單。
- 來源系統改了產品資料,網站總是慢半拍。每小時增量同步、每天凌晨 2 點完整同步,料號、規格自動跟上,不用人工搬資料。
- 轉帳訂單對帳靠翻網銀,對到眼花。客戶回填轉帳末碼與金額,後台一鍵確認收款或退回,每筆審核都留時間紀錄。
成果
- 上架1,000+ 料號自動維護:每小時同步一次、每天凌晨 2 點全部對一次;2,922 張產品圖搬上 CDN
- 速度首屏 1.5 秒內出來;圖片自動壓縮,省 60% 以上流量
- 接單從只能電話、Email 報價,變成客戶自己逛、自己詢價下單的網站
背景
料號、圖片、相似品都鎖在內部 ERP,對外只能靠業務一封一封回信報價。上千個料號,不可能靠人一個一個上架。
為什麼這樣做
- 為什麼不動客戶的 ERP——最貴的風險,是去改一套跑了很多年的系統。屏果園的料號、圖片、相似產品關聯都在內部 MSSQL(TradeDB)的三個視圖裡:EEB2CWeb_View、EEB2CPhoto_view、EEB2CMList_view。我們不改它一行,只讀不寫——建一條唯讀同步管線,以 PNType-PNId 為唯一鍵、每批 50 筆批次 upsert 到雲端資料庫。ERP 繼續過它的日子,網站拿到它的資料。
- 為什麼同步排在每天凌晨 2:00——零人工介入的排程,比隨叫隨到的人可靠。每天凌晨 2:00,排程自動建立 VPN 連線、跑完三條同步、自動斷線。沒有人要記得做這件事,所以這件事永遠不會被忘記。
- 為什麼 2,922 張圖搬進 CDN 還要轉檔——省下的 60%+ 頻寬,就是手機上的轉單率。原始圖片是未壓縮的 JPG。全部遷入 CDN 後自動轉 AVIF(省 60%+ 檔案大小)、WebP 備援、響應式裁切、24 小時快取;首屏前 12 張預載入、並發限制 6 張。行動裝置上圖片先出來,訂單才進得來。
- 為什麼首屏敢承諾 1.5 秒內——效能不是調出來的,是一層一層架出來的。API 快取(5 分鐘 TTL+LRU 淘汰+Stale-while-revalidate)、批次請求合併 N+1 查詢(50ms debounce)、虛擬捲動只渲染看得見的區域、SSR+ISR。結果:FCP < 1.5 秒、API P95 < 500ms、快取命中率 > 80%。
- 為什麼運費是引擎不是表格——行銷策略會變,程式不該跟著重寫。本島/離島費率、物流方式、免運門檻,全部後台可設定,結帳時即時試算。促銷檔期改免運門檻,是店家自己點幾下的事。
- 為什麼 1,000+ SKU 敢一次全上——上架不是人工貼文,是管線的副產品。1,000+ SKU(LCD 面板佔 75%+)全面上線,靠的不是加班貼商品,是同步管線把 ERP 資料自動變成商品頁。從此新增料號=自動上架。
更多案例
全部案例有類似的需求?
說你的困擾就好,不用寫規格書。工作日 24 小時內回覆。
談類似的專案


