旺季排隊與重複謄寫
第一次受理就建立可沿用資料，後續收據、名冊與服務進度不再重新抄寫。
廟務行政有章法，
信眾服務不斷線。
神機廟算 TempleOS 讓宮廟的信眾資料、服務受理、收款與稽核，在廟方後台、官網與 App 三端保持同一套紀錄。
誠實揭露：目前為高擬真雛型，尚未開放公開註冊，也尚未串接真實金流、會員與正式資料庫。
Direct answer
宮廟管理系統是什麼？
宮廟管理系統是把信眾資料、點燈安太歲、法會報名、捐款收據、收款對帳與志工活動集中管理的工具。神機廟算進一步讓廟方後台、信眾官網與 App 共用同一份資料。
適合誰有固定信眾服務，想改善排隊、紙本謄寫或跨通路對帳的宮廟。
核心差異不是代辦平台；系統由廟方使用，規則與資料主權回到廟方。
目前階段高擬真雛型與早鳥共創期，尚未公開註冊或正式收費。
先解決老問題
不是廟方不想數位化，是工具常只接住其中一段。
收款好了，名冊還在紙本；官網做好了，櫃台仍各自輸入；付款完成了，服務是否執行卻沒有同一個答案。
信眾與家戶資料分散
把同一信眾的現場、官網與 App 服務歷程接回同一主檔，保留關係與來源。
付款與服務狀態混在一起
訂單、付款、安奉、法會執行與通知分開記錄，再在同一歷程中查詢。
三端一體
三個入口，共用同一份即時資料。
不是三套系統每天互傳檔案。規則只在後台設定一次，官網與 App 依同一套服務、金額、名額與流程運作。
神機廟算後台
- 信眾與家戶主檔
- 點燈法會與訂單受理
- 交班、對帳與稽核
宮廟官網
- 服務瀏覽與線上申辦
- 進度查詢與補件
- 公告、文化與交通資訊
保庇通 App
- 家庭代辦與通知
- 服務與電子憑證
- 活動導覽與 QR 報到
受理一次 → 人工核對 → 執行留痕 → 通知信眾 → 對帳可追溯。
比較定位
不是取代所有工具，而是把斷掉的流程接起來。
我們尊重廟方既有工具與工作慣性；以下比較的是產品定位，不點名競品，也不宣稱第一、唯一或最大。
| 比較項目 | 神機廟算 TempleOS | 線上代辦平台 | 傳統單機／區網軟體 |
|---|---|---|---|
| 使用者 | 廟方自己使用 | 平台代廟方受理 | 廟方現場人員 |
| 資料範圍 | 信眾、服務、財務、稽核三端共用 | 以平台受理範圍為主 | 以現場單機功能為主 |
| 資料可攜 | 規劃可匯出、備份與終止服務流程 | 依平台政策 | 依軟體與主機狀況 |
| 跨通路 | 後台、官網、App 同一資料來源 | 平台頁面與廟方系統可能分開 | 官網／App 通常需另外整合 |
產品立場
把信任做成系統規則。
宮廟是公共服務與信仰空間。科技的角色是協助行政、說明與核對，不是刺激消費或替代宗教判斷。
不消費信仰
不做倒數促購、功德點數或誇大宗教效果。
AI 不越界
只協助行政與核准內容，不算命、不生成神諭。
異動可追溯
作廢取代刪除，高風險操作留下經手、原因與覆核。
導入不是交付帳密
五步把系統貼合現場。
早鳥共創從真實流程開始，先理解再設定，不要求廟方自行把多年工作方式翻成技術規格。
需求訪談
盤點現行受理、交班與例外。
資料整理
確認匯入範圍、欄位與責任。
系統設定
設定服務、角色、流程與樣板。
教育訓練
以櫃台情境演練並修正。
試營運
小範圍上線、記錄問題、再擴大。
常見問題
先把現況與限制說清楚。
FAQ 內容與產品現況同步更新，不把規劃中能力寫成已正式提供的服務。
神機廟算 TempleOS 是什麼？
神機廟算 TempleOS 是給宮廟自己使用的雲端廟務管理系統。廟方後台、信眾官網與 App「保庇通」共用信眾、訂單、服務、收款與稽核資料。
跟線上點燈代辦平台有什麼不同？
代辦平台由平台方代替廟方受理；神機廟算則是廟方自己的作業系統，規則由廟方設定，資料可由廟方匯出與備份。
跟傳統單機版廟務軟體有什麼不同？
神機廟算規劃為雲端服務，讓櫃台、官網與 App 共用同一資料來源；不需要把各通路資料另外匯檔再對帳。
目前已經正式上線了嗎？
尚未。目前是高擬真雛型與早鳥共創階段，尚未公開註冊，也尚未串接真實金流與正式營運資料。