依燃軟體 Everan 台北市在地服務

在台北 多數案子
不是從零開始

總部已經有系統 難的是接上去
依燃軟體在桃園 台北全市可約現場

台北的案子通常長這樣

你現在卡在哪一段?

台北的客戶很少是白紙一張。多半是總部已經有一套 ERP 或會計系統、分店各自買了預約或收單工具,然後發現資料兜不起來。這種情況要的不是再買一套,而是把缺的那一段補上、把既有的幾套接起來。

總部有系統 分店接不上去

總部的 ERP 或進銷存跑得好好的,但分店的預約、收單、會員資料進不去,月底要靠人工整理成 Excel 再匯總。這種情況通常不需要換掉總部系統,做一層串接把資料送回去就好。

多分店要看同一份報表

每家店的作業方式不完全一樣,於是報表欄位對不起來,總部看到的數字跟店裡認知的不同。重點在先把「哪些欄位全店統一、哪些可以各店自訂」講清楚,再談系統。

用了好幾套 SaaS 客人資料各自分開

預約一套、收款一套、電子報又一套,同一個客人在三個系統裡是三個人。要合併的不只是資料,還有「以誰為準」的規則,這一段釐清之後串接才有意義。

四個模組

可以單獨導入 也可以組合

共用同一套資料結構 之後加購不必重新建置或轉檔

台北網站設計與整合

官網能預約 能下單

  • 19 套版型可挑也可全客製
  • 原始碼與網域都交付
  • 不綁月租平台
看網站設計與整合

台北預約+雲端櫃台

總部分店同一份表

  • 約人 約場地 約設備三種規則分得清楚
  • 自動擋衝突與容量上限
  • 可先收訂金再佔時段
看預約+雲端櫃台

台北POS+掃碼點餐

收單資料回得到總部

  • 指定人員抽成與工單零件成本
  • 會員儲值與療程套票
  • 客人手機掃碼自助送單
看POS+掃碼點餐

台北客製化軟體

既有系統接得上去

  • 與既有 ERP 進銷存串接
  • 倉儲 工單與申報格式
  • 監控與工控整合
看客製化軟體

做法

一個案子實際會怎麼跑

不必先想好要什麼系統 講現在怎麼做的就可以開始

  1. 先看你現在怎麼做 第一次碰面不需要準備規格書,也不用先整理好資料。把現在的實際作業講一遍就好:哪一段要靠人工搬資料、每天大概幾筆、有幾個人在用。台北的案子通常還要多問一件事 —— 既有那幾套系統分別是誰在維護、能不能開放介接,這決定了是串接還是替換。
  2. 把範圍切成一定要有跟有更好 一次做完所有想到的功能,是專案失控最常見的起點。我們會把需求分成「不做就不能上線」與「之後再加也可以」,先做前者。範圍越明確,報價落差越小,後期爭議也越少。
  3. 分段做 分段給你驗 不是做完才給看。每一段做完就給你一組實際帳號登入操作,在你自己的資料上跑。理解落差越早發現越便宜,拖到最後才對,改的就不只是那一個功能。
  4. 上線之後才是長期成本 新舊做法通常要平行跑一段時間。教育訓練、異常回報管道、後續調整怎麼計價,這些在簽約前就會講清楚。交付含原始碼與網域,你要換人接手也帶得走。

做過的系統

現場交易型 連鎖健身教室的課程規則

基於客戶保密 只寫產業類型與卡住的環節 不列客戶名稱

卡在哪

同一堂課有四個地方可以被預約:LINE 的文字訊息、會員專區的日曆、官網的公開預約頁、以及櫃台後台代客建立。前三個都是客人,規則必須一模一樣。這類系統最常見的失敗是四個入口各寫一份規則,於是跑出「櫃台幫你取消會退點、自己取消不會退」這種對不起來的行為,而且通常要到客人抱怨才會被發現。

怎麼做

把「一堂課的規則」抽成一支獨立模組,四個入口都只負責呼叫,不各自判斷。規則有三條:時數怎麼算(標準時長的整數倍、以 30 分鐘為單位自選、或整天一口價)、要不要指定教練(可指定、必須指定、或不需要教練因此不佔教練容量)、哪些會員等級看得到。

結果

新增一堂課從改程式變成後台勾選,櫃台自己就能開課,不用等工程師排時間。

另外兩種生意形態的案例在客製化軟體指南裡:卡在哪、怎麼做、結果如何

服務範圍與進行方式

辦公室在桃園 但整個北台灣都可以約現場

台北市可約現場的區域

中正區、大同區、中山區、松山區、大安區、萬華區、信義區、士林區、北投區、內湖區、南港區、文山區。需要看現場設備或動線的案子,我們會直接過去一趟。

北台灣其他地區

台北市、新北市、基隆市、桃園市、新竹縣市、苗栗縣都在可約現場的範圍內。其他縣市以線上進行,內容與品質沒有差別。

線上怎麼進行

需求討論用視訊、畫面確認用線上連結、測試環境給你實際帳號登入操作。全程留書面紀錄,不會只有口頭講過。

台北的常見問題

你們在台北有辦公室嗎?

沒有。依燃軟體的辦公室在桃園市桃園區藝文一街 86-3 號 12 樓,台北全市可以約現場,我們過去。需要看設備或動線的案子本來就該到現場,不必勉強在線上講。

已經有 ERP 或 POS,一定要換掉嗎?

不用,而且通常不建議。能串就串,串不了才談替換。常見做法有三種:對方有 API 就直接介接;沒有 API 但資料庫可存取,就用中介程式定時同步;兩邊都不開放時,以匯出匯入的排程檔案交換。

多分店的案子會不會比較貴?

差別不在店數,在於各店的作業方式差多少。流程一致的連鎖,加店只是設定;每家店規則都不同的,要先決定哪些統一、哪些保留彈性,這一段的釐清成本比寫程式高。

可以只做其中一個模組嗎?

可以。四個模組都能單獨導入,共用同一套資料結構,之後要加購不需要重新建置或轉檔。建議一次只換一件事,先換最花時間的那件,跑順了再換下一件。

如果現成的 SaaS 就夠用呢?

那我們會直接建議你用現成的。流程標準的生意硬要客製,多花的錢換不到對等的好處。要注意的只有一件事:先問清楚資料與網域能不能帶走,免得以後想換換不掉。

為什麼要約現場

系統要對得上你現場真正的做法

流程這種東西用講的最快,講不清楚就走一趟。台北市可以直接約在你的店裡、辦公室或廠區, 看你現在怎麼記、怎麼排、怎麼算,再判斷該用現成模組還是要客製。 如果現成軟體就能解決,我們會直接說,不會硬接。