# 2025-11-10 會議紀錄整理（宮廟 & 通訊客戶）

使用來源：雅婷逐字稿語音轉文字 https://asr.yating.tw/

---

## 一、會議主軸概覽

1. **宮廟專案**
- 為台中某宮廟規劃一套 **「感謝狀開立系統」**，將香油錢、普渡、點燈等收入流程電子化。
- 目標是做成可複製到其他宮廟的樣板，成為新的客戶族群與商業模式。
- 收費模式採 **月租 + 客製化費用**，不是一次性的發包專案。

2. **既有通訊客戶（與新等）**
- 希望實現類似 Adidas / Nike App 的 **會員 & 折價券** 功能，但全部做在 **Line 官方帳號裡**。
- 需求包含：會員綁定、標籤 Tag、分眾發送訊息、圖文選單、二手機與報表功能等。
- 部分需求（如二手機報表、序號嚴格模式）重要但時程可往後排。

3. **合約與客製化商業模式**
- 需要整理出一份通用的 **軟體租用 + 客製化合約**。
- 條款要清楚規範：月租、客製費、不退費原則、功能確認流程、硬體責任切割等。

---

## 二、宮廟系統：需求與構想

### 1. 感謝狀 / 香油錢開立流程

**基本概念：**
- 不再使用「銷售出貨單」的名義，而是新增一個名稱為 **「感謝狀開立」** 的專用畫面。
- 底層資料仍然寫進 **銷貨單 + 會員資料表**，方便會計與統計。
- 對宮廟方來說，是「感謝函 / 感謝狀」；對系統來說仍是一筆銷售紀錄。

**畫面與欄位需求：**

1. **快速金額按鈕**
- 香油錢的習慣是拿整張鈔票，不太會找零。
- 需要像「1000 / 500 / 100 / 50 / 10 …」這種按鈕，透過 **按鈕累加金額**，而不是人工輸入 950 這種零頭。
- 先以滑鼠點擊為主，不考慮觸控投幣機整合。

2. **捐款人 / 會員基本資料**
- 姓名（可用「謝先生」這種簡化稱呼）。
- 電話。
- 地址。
- 出生年月日（至少要有出生年月日，扣稅 / 八字需求可再延伸）。
- 這些資料要同步寫入 **會員資料表**，方便後續查詢與推播。

3. **商品 / 項目設定**
- 宮廟實際有普渡、光明燈、箱、燈位等品項。
- 系統裡視為一組 **預先建立好的商品**：
- 例如：`普渡`、`光明燈`… 單價可固定或可調整。
- 感謝狀畫面上可以只秀「目前選到的項目」，不要顯示太多干擾選項。

4. **感謝狀輸出（報表 / Word / PDF）**
- 需要依照現有紙本感謝狀的 **大小與版面** 來設計。
- 固定欄位：宮廟名稱、地址、統編等，直接寫在樣板裡。
- 變動欄位：捐款人姓名、地址、金額、日期等，由系統套入。
- 初期可用 **Word 先排版樣板** → 之後再轉成 PDF 或報表引擎實作。
- 印章仍由宮廟自行蓋，不由系統處理。

5. **實際操作流程（由宮廟內部人員使用）**
1. 宮廟人員開啟「感謝狀開立」畫面。
2. 輸入 / 選擇會員資料（也可現場新增簡易會員）。
3. 選擇對應商品（普渡 / 香油錢）與金額（透過快速金額按鈕）。
4. 按下「確認」 → 產生一筆銷貨單 → 產生感謝狀 PDF / 列印。
- 目前評估 **不適合讓信徒自助操作**，以宮廟兩位小姐為主要操作對象。

---

### 2. 志工管理與打卡

- 宮廟有固定的志工，需要記錄每位志工的出勤與服務時數。
- 需求包含：
- 誰有來、來多久，以便發服務證明或感謝狀。
- 構想是把既有的 **點名 / 打卡系統** 延伸到宮廟：
- 志工透過 Line / 報到機制打卡。
- 系統累積每位志工的服務時數。
- 目前屬於 **下一階段可延伸功能**，不是本次報價的最急項目，但被視為後續重要方向。

---

### 3. 活動管理與會員推播（四大節慶）

- 宮廟每年有 **四個固定大活動**（中元普渡、媽祖生日、端午、中秋等）。
- 需求包含：
- 活動的供品、普渡項目、花籃往來、輪流請客等的管理。
- 使用 **Line 官方帳號** 對信徒 / 會員推播活動訊息。
- 未來希望：
- 能依會員屬性分眾推播，例如：老人、年輕人、志工、有功、委員等。

---

### 4. 系統架構與擴展策略

1. **資料庫層儘量不動**
- 仍然沿用既有的：銷貨單、會員資料表等結構。
- 宮廟功能主要是新增：
- 前端操作畫面（感謝狀開立）。
- 感謝狀報表 / 樣板。

2. **複製到其他宮廟的可能性**
- 每間宮廟是獨立個體，沒有「分店」概念。
- 透過主委、人脈、「有功宮廟」等關係，有機會向其他宮廟擴散。
- 先在這一間做成功案例，接著一兩年內慢慢發酵。

3. **與政治與地方人脈的連動**
- 主委本身是市政顧問，宮廟與地方政治、選舉有高度連結。
- 覺得這條線長期有商機，也是「多一條路」。

---

### 5. 宮廟專案商業模式與時程

1. **收費模式**
- **月租費**：半年 / 年約，宮廟財力充足，預期可接受。
- **客製化費用**：
- 這次主要為「感謝狀開立畫面 + 感謝狀輸出版型」。
- 定位為「半買半相送」，透過友善價格換取長期合作與樣板案例。

2. **合作流程設計**
1. 先畫出 **Demo 畫面 + 感謝狀樣板**（可用假資料）。
2. 提供 **報價單**（含月租 + 客製化費用）。
3. 提出 **合約書**（可線上簽署 / 存檔）。
4. 對方確認畫面與金額 → **畫押 / 確認** → 才正式進入開發。
5. 開發完成後安排 **教育訓練**，教會宮廟人員使用。

3. **時程重點**
- **本週五之前**：
- 要交付「感謝狀開立 Demo 畫面」。
- 出具「半年月租 + 客製化」報價。
- 準備一版可用的合約草案。

---

## 三、與新通訊行及其他通訊客戶的需求整理

### 1. Line 官方帳號 + 會員綁定 + 折價券

**需求來源與目標：**
- 老闆希望有類似 Adidas / Nike App 的：
- 會員管理。
- 折價券 / 點數。
- 歷史消費查詢。
- 但不想再做一個新 App，偏好全部整合在 **Line 官方帳號** 下。

**功能構想：**

1. **整合進 POS「整合行銷平台」**
- 在 POS 畫面新增一個「活動 / 優惠券建立」入口。
- 由店家建立折價券或推薦連結，透過 Line 推播給會員。

2. **折價券運作機制**
- 參考馬尼作法：
- 例如折 50 元，視為店家自己的「獲客成本」，從毛利中吸收。
- POS 在結帳時要能識別折價券並抵扣。

3. **會員綁定流程（Line ↔ POS）**
- 店家已經在 POS 有很多會員，也已經有 Line 官方帳號。
- 目標流程：
1. 顧客掃描 QR code → 加入官方帳號。
2. 點「加入會員」按鈕。
3. 若 POS 內已有相同電話號碼：
- 可直接判斷為同一人，自動綁定；或
- 傳簡訊驗證碼 → 顧客輸入 → 完成綁定。
- Line 不會主動提供電話號碼，必須透過表單 + 驗證來完成綁定。

4. **歷史消費查詢**
- 顧客在 Line 介面裡可以查詢自己的歷史消費與折價券狀態。
- 這些功能未來可變成「可選功能」，店家願意付月租就開啟。

5. **圖文選單注意事項**
- 之前掛在某個 Channel 的圖文選單因到期被刪，Demo 當場掛掉。
- 未來要在 Demo 前先確認：
- Channel 狀態正常。
- 圖文選單已重新掛好。
- 所需 LIFF / API 均運作正常。

---

### 2. 會員分類 / Tag 機制

- 目前發送訊息頁面缺乏搜尋與分類，會員一長串不好用。
- 需要新增：
- **會員層級**：例如 A / B / C / D 等級。
- **Tag 標籤**：如 信徒、有功、委員、未綁定、已綁定等。
- 發送訊息時可根據 Tag 或層級篩選對象。
- 也可用來區分：Line 內部會員 vs. POS 已綁定 / 未綁定會員。

---

### 3. 二手機、維修、報表與 12/1 清庫存

**目前有提到但時程較後面的需求：**

1. **序號嚴格模式**
- 與新希望有「一機一序號」嚴格控管方式，方便管理二手機。
- 需再與客戶確認細節後設計。

2. **經銷月報表**
- 既有月報表是為協訓設計，欄位不適用與新目前重點。
- 新報表需加上二手機、維修等欄位。

3. **12/1 庫存清空作業**
- 12 月 1 號要做一次特定項目的庫存清空與序號重置。
- 二手機庫存不動。
- 需要工具或腳本來協助執行。

4. **手機版畫面調整**
- 目前手機版登入 / 首頁是外包畫面，難以修改。
- 構想是改成：
- 直接進入自家實作的盤點畫面。
- 參考舊 UI 色調，畫面邏輯重新設計。

---

## 四、合約與客製化模式整理

### 1. 合約種類

- **軟體租用合約**（包含月租與基本服務）。
- **客製化功能合約**（附加條款，描述客製功能內容與金額）。
- 可參考既有「維護合約」中的硬體責任條款。

### 2. 條款重點

1. **月租與退費規則**
- 租用期內不退費。
- 客戶中途停用，已繳費用不退還。

2. **客製化流程**
1. 由公司提供畫面 / 規格與正式報價。
2. 客戶確認內容與金額後「畫押同意」。
3. 若之後追加新功能，視為新一輪客製，另外報價。
4. 即使後續減少功能，價格不因而降低（可少做，但不退差額）。

3. **硬體責任切割**
- 客戶自備或自行購買的硬體故障與軟體無關。
- 可以協助處理，但責任與費用需在合約中寫清楚。
- 可將舊維護合約中的相關條款整理進來。

4. **版本管理**
- 合約可有 v1 / v2 / v3 …，集中存放在 NAS。
- 隨經驗累積與案例增加，逐步修正條款。

---

## 五、明確待辦事項（Task List）

### A. 宮廟專案（最急）

1. **感謝狀開立 Demo 畫面**
- 新增名稱為「感謝狀開立」的前端畫面：
- 包含快速金額按鈕（1000 / 500 / 100 / 50 / 10…）。
- 包含捐款人基本資料：姓名、電話、地址、出生年月日。
- 至少預設一個商品（如「普渡」或「香油錢」）。
- 初版可不接後端，只需能 Demo 操作流程。

2. **感謝狀版型樣板**
- 用 Word 先排出與實體感謝狀一致大小與版面的樣板。
- 區分固定欄位與變動欄位，未來可轉 PDF / 報表。

3. **宮廟報價單**
- 列出半年月租 + 客製化費用。
- 說明客製範圍與後續追加功能的收費方式。

4. **合約草案（第一版）**
- 將舊合約 + 維護合約內容整併：
- 月租與退費規則。
- 客製化流程與不退費原則。
- 硬體責任切割條款。
- 先做出一份「可用版本」，之後再依案例修正。

5. **時程目標**
- 本週五前完成：Demo 畫面 + 報價單 + 合約初版。

---

### B. Line / 會員 / 與新相關（重要但較不急）

1. **Line 會員綁定與加入會員畫面**
- 完成 LIFF 加入會員表單（姓名、電話、地址等）。
- 若電話與 POS 會員一致 → 自動綁定或透過簡訊驗證綁定。

2. **會員 Tag / 層級系統**
- 會員資料新增層級與 Tag 欄位。
- 發送訊息介面新增依 Tag / 層級篩選功能。
- 可區分：未綁定 / 已綁定會員。

3. **圖文選單檢查與修復**
- 定期確認 Demo 用與實際客戶使用中的圖文選單是否因 Channel 到期而失效。
- 重新掛載必要的圖文選單與 LIFF。

4. **二手機 / 報表 / 清庫存**
- 記錄並保留：序號嚴格模式、新經銷月報表、12/1 清庫存工具等需求。
- 宮廟專案告一段落後再排期實作。