ybuild 助力零售與在地店家

適合誰

• 在地店家與專營零售商
• 想把庫存和會員放在一處的店主
• 想開通線上接單又不想訂閱 Shopify 的店家

ybuild 如何契合

• 庫存、會員和商店共享同一套託管系統、同一份資料集
• 跑在你自己的網域上、由 ybuild 託管——沒有每月吞噬利潤的平台費
• 全端，帶託管資料和真實支付，而不是一個假的購物車
• 始終在線，帶版本記錄和當機復原

門店裡的一天，以及它背後那套唯一的系統

開店後你做的第一件事不是賣貨，而是核對。昨晚進來的線上訂單，背後真的有貨嗎？供應商今天要到的貨，對應的是哪張採購單？一家在地店家的生死，就繫於這些瑣碎的對帳上，而大多數店主是靠一台收銀機、一本筆記本、一串 WhatsApp 對話，加上一份只有一個人真正看得懂的試算表來處理的。真正制勝的做法，是把這一切收攏進一套託管系統裡：你收銀機讀取的那份商品清單，就是你線上商店讀取的那份，也是你補貨報表所依據的那份。

臨近上午，一位老顧客走進來。在靠紙筆運轉的店裡，這位老顧客只是一張你認得的臉，僅此而已。而在靠真實系統運轉的店裡，你掃一下他的會員碼或輸入他的手機號碼，就能看到他上次買了什麼、離下一個獎勵還差幾次到店，以及他特別訂購的那個零件已經到貨。這一次查詢——顧客檔案、購買記錄和點數餘額都在一處——正是把一次熱絡的寒暄變成一筆回頭生意的關鍵。

快遞送來供應商的貨。你對著採購單收貨，庫存數字隨之上調，一位顧客在線上預留的那兩件商品被標記為可自取。無需再把資料重新輸入一個獨立的庫存工具，因為根本不存在獨立的庫存工具——收貨、銷售和預留，全都寫入同一份資料集。

打烊時你結帳盤點。不再是數完抽屜裡的現金、盼著它能對上一份你打算明天才更新的表格；當天的銷售、線上訂單和庫存變動早已自動對平，因為它們從一開始就不曾分散在不同地方。這正是整個主張所在：不是五個勉強互通的應用，而是一套運轉中的系統——託管在 ybuild 上，跑在你自己的網域上——店家的每一個環節都寫入其中。

毛利、補貨點，以及先做什麼

零售是一門利潤的生意，而且利潤很薄。一家專營店也許加價 40% 到 60%，卻仍會被房租、人力和積壓在貨架上的滯銷貨吃掉大半。所以，首先要打造的不是漂亮的門面——而是那套守護你既有利潤的庫存系統。把每一個 SKU、它的成本、售價和現有庫存量都歸入一處，再為每個商品設定一個補貨點，讓系統在你缺貨之前就提示你該進什麼貨，而不是等顧客空手離開之後。

按這個順序來搭建。第一，把庫存作為唯一的事實來源：商品、成本價與零售價、現有庫存和補貨點。僅這一步就能取代試算表，而且第一次幫你避免熱銷品缺貨時就已回本。第二，在同一份資料之上疊加會員和顧客檔案——以手機號碼為索引的點數、等級和購買記錄，讓收銀台前的人真正能據此行動。第三，開通線上商店，讀取的正是同一份庫存資料，這樣你就絕不會把只剩一件的商品超賣出去。

你如何交付，決定了結帳是什麼樣子。街坊小店很少需要一整套配送與物流體系；它需要的是讓顧客線上預留、到店自取，或者透過 WhatsApp 確認訂單，再用 PIX、刷卡或取貨時結清。ybuild 把這些做成真實的結帳——背後是一個託管資料庫和真實的支付，而不是一個只會給你發一封訂單郵件、再由你手動重新輸入的假購物車。因為整套東西是一個全端應用，託管在 ybuild 上、在你自己的網域上運行，線上通路就不是另一門需要單獨對帳的生意；它只是通往同一批庫存、同一批顧客的另一扇門。

從窄處起步，讓它自己掙來下一個功能。成功的店家不會在第一天就試圖在功能上蓋過 Shopify。他們先上線庫存核心，用它經營一週，然後才加上會員層和門面——每一次新增，都建立在一份已經乾淨、已經上線、已經屬於自己的資料之上。

在地店家常犯的錯

最常見的錯誤，是那一堆彼此割裂的應用。這裡一個預約工具、那裡一份庫存表格、一張集點卡、一個用來接單的社群媒體私訊——每一個單看都合情合理，湊在一起卻是一套什麼都對不上、每個數字都要輸入兩遍的攤子。重複輸入不只是繁瑣；錯誤正藏在這裡。全美零售安全調查（National Retail Security Survey）顯示，平均庫存損耗約占銷售額的 1.6%——在全美零售業約合 1,120 億美元——其中很大一部分並非驚心動魄的竊盜，而是行政疏失：盤點錯、輸入錯，以及因兩套系統資料不一致而從帳面上消失的庫存。讓店家的每個環節都寫入同一份資料集，是最便宜的損失防範工具。

第二個錯誤，是把會員當成可有可無的東西。皮夾裡的一張集點卡，是一套沒人去衡量的會員方案。而貝恩公司（Bain & Company）的研究對回報直言不諱：僅僅把顧客留存率提高 5%，就能讓利潤提升 25% 到 95%。如果你的老顧客值這麼多，那麼記錄他們是誰、買了什麼，就該存在你的系統裡，而不是你的記憶裡——而且它應該就是收銀機和線上商店已經在用的同一份記錄。

第三個錯誤，是以為線上是另一門生意。電商如今約占美國零售額的 16%，而且仍在攀升，但那些硬貼上一個獨立商店的店家，最後會落得兩份庫存、兩份顧客名單，外加一筆每月吞噬他們辛苦守護的利潤的平台費。線上應當是通往同一批庫存、同一批顧客的一個通路，而不是一家你要手動對帳的平行店家。

最後一個錯誤，是脆弱——把整個經營押在一台筆電的一份表格上、一個人的登入帳號上，離一次誤操作釀成的混亂只有一步之遙。一套帶版本記錄和當機復原的託管系統，意味著錯誤只是一次點擊即可復原，而不是搭進去一個週末。在 ybuild 上、在你自己的網域上運行，店家的系統永遠在線、永遠有備份、永遠屬於你——這與一份只有對的人在場時才管用的表格恰恰相反。

常見問題

我能用 AI 不用寫程式就搭出一套零售管理系統嗎？

可以。描述你的店家是怎麼運轉的——商品、庫存、老顧客、訂單——ybuild 就會把庫存、會員和線上商店搭成一套全端系統，然後託管它、在你自己的網域上運行它。你得到的是一套能用的店家系統，而不是一堆要維護的程式碼。

它能把我的店內庫存和線上訂單放在一處管理嗎？

這正是重點。收銀機、補貨報表和線上門面讀寫的都是同一份商品清單，所以你在櫃檯賣出一件，網站上顯示的數量就會隨之減少。沒有兩份庫存，沒有超賣，也不用在工具之間重複輸入。

我還需要 Shopify、Square 或一個單獨的會員應用嗎？

不需要。那些正是這套系統要取代的割裂零件。ybuild 把庫存、會員和帶真實結帳的門面搭成一套託管系統，運行在你自己的網域上，這樣你就不必支付一疊每月的費用，也不必在它們之間對帳。

顧客到底怎麼付款——結帳是真實的嗎？

這是一套真實的全端結帳，背後是託管資料庫和真實支付——視你如何交付，可以是預留自取、WhatsApp 確認、PIX 或刷卡。而不是一個只會給你發一封訂單郵件、再由你手動輸入的假購物車。

如果我操作失誤或系統出了故障，我的資料會怎樣？

你的資料存在 ybuild 的託管系統裡，而不是某一台筆電上。版本記錄和當機復原意味著一次誤操作點一下就能復原、一次當機能自行恢復，店家照常運轉，而不是為此搭進一個週末。