不動產租賃管理｜總後台 + 員工行動端雙前端
2026
這是一套為不動產包租代管業者打造的內部營運系統。包租代管的業務本質是：業者向屋主承租房源，再轉租給房客，中間要處理帶看、簽約、收租、修繕、退租等一連串流程，而這些事情多半散落在 Excel、通訊軟體與紙本之間。
系統的設計核心是「以房間為單位」的三層資料模型：屋主可以擁有多個房間、房間隸屬於物件（一棟樓或一個社區）。實務上一個屋主可能在不同物件各有幾間房，而一個物件裡的房間也可能分屬不同屋主，因此屋主與房間之間是多對多關係，而不是常見的單向從屬。這個模型決定了後面所有流程能不能正確運作。
介面刻意拆成兩套：桌機端的總後台給管理者做大量資料維護與報表，手機優先的員工行動端（PDA）給第一線人員在現場處理帶看與回報。兩者共用同一個元件庫與同一組 GraphQL API，但操作情境完全不同，硬做成一套 RWD 反而兩邊都不好用。
包租代管最容易做壞的地方，是把「屋主擁有房子」寫成一條單向從屬。實務上不是這樣——同一棟樓裡的房間可能分屬不同屋主，同一位屋主也可能在好幾棟樓各有幾間。這張圖是整套系統的地基，收租、分潤、報表能不能算對，全看它。
因此屋主與房間之間是多對多，而房間對物件才是單純的從屬。把這層拆開之後，「某位屋主這個月該拿多少」與「某棟樓的出租率」才能各自算得出來，而不是互相打架。
以房間為核心的資料結構，屋主與房間為多對多關係，正確反映一屋多主、一主多屋的真實租賃結構
管理者的主要工作場域，以資料表格為核心，支援大量欄位檢視、批次編輯與篩選，處理日常的資料維護與營運報表
手機優先的獨立前端，供第一線人員在現場帶看、回報與查詢，操作路徑針對單手與行動網路環境設計
兩套前端共用同一個 UI 元件套件，確保視覺與互動一致，也避免同一個表單元件要維護兩份
後端不做任何後台畫面，只提供型別安全的 GraphQL API 與 JWT 認證，前端要什麼欄位就取什麼，不需為每個畫面各開一支端點
資料庫一律以 UTC 儲存，顯示時依使用者所在時區轉換，而營運日的判斷（例如帳款是否逾期）則固定以營運所在地時區為準
屋主、物件、房間、租約、員工各有規則化的編號格式，讓紙本作業與系統之間有共同語言，也方便電話溝通時對單
管理者、業務、現場人員可見的資料範圍與可執行的動作各不相同，權限在後端 Policy 層強制，不靠前端隱藏按鈕
一張預訂單從客人來電到房客拿到鑰匙，橫跨四種角色與兩套介面。這張圖標出每一步由誰執行、哪些由系統自動完成，開發期間是規格依據，交付後直接當教育訓練教材。
主線由第一線業務在行動端推進，每一步的結果由系統即時反映到房間與合約狀態；主管端負責覆核與例外放行。
房間與合約狀態一律由時間戳推導，不另存 status 欄位，避免資料與實際狀況不一致。
鎖房與逾期未入住都有排程主動處理，但判定邏輯不只依賴排程，排程沒跑也能算出正確狀態。
取消只蓋上時間戳，紀錄保留並標示已取消，同時自動把相關資源釋放回可用狀態。
總後台的工作是「一次看很多筆、批次改」，需要寬螢幕與密集表格；行動端的工作是「在現場處理眼前這一間」，需要大按鈕與最短操作路徑。這兩種情境對資訊密度的要求相反，用同一份版面做 RWD 的結果通常是桌機嫌空、手機嫌擠。拆成兩套前端、共用同一組 API 與元件庫，反而讓兩邊都能針對自己的使用情境最佳化，維護成本也沒有變成兩倍。
包租代管系統最容易做錯的地方是把「物件」當成最小單位。實際上租約、收租、修繕、房客都是綁在房間上，而不是綁在整棟樓上。此外一個物件裡的房間可能分屬不同屋主，所以屋主與房間必須是多對多。把最小單位定在房間、並把屋主關係做成多對多，後續的租約與帳務流程才不會出現「這筆錢該算給誰」的歧義。
後端是純 GraphQL API，完全不產生畫面。兩套前端都採伺服器端渲染，瀏覽器只跟自己的 Node SSR 層溝通，由 Node 在伺服器端帶 JWT 呼叫後端 API。這代表 API 完全不需要對瀏覽器開放 CORS，Token 也不會出現在前端，攻擊面比傳統前後端分離小很多。
總後台的核心是大量資料的檢視與編輯，採用專業表格元件處理欄位凍結、排序、篩選、虛擬捲動與行內編輯。這類需求若用一般 table 硬刻，資料量一上來就會卡；換成專業表格元件後，數千筆資料的捲動與篩選都能維持順暢。
跨國營運的系統最常見的 bug 就是時間。這套系統的規則是三層分離：資料庫一律存 UTC、顯示時依使用者時區轉換、營運判斷（帳期、逾期、當日報表）固定用營運所在地時區。三者分開之後，不論使用者人在哪裡登入，看到的時間與系統的營運判斷都不會互相矛盾。
這類系統不會一次取代所有紙本作業，過渡期一定會有電話對單、紙本簽名的情境。因此屋主、物件、房間、租約、員工都設計了規則化的編號格式，讓人在電話上唸得出來、在紙上寫得下去，也讓系統與現場作業有共同語言。這是純技術規格之外，實務上很關鍵的一個設計。
這是一套企業內部使用的營運系統，不是對外的公開網站，本身就沒有可以給外人點進去看的網址；同時我們與業主有保密約定，客戶名稱與實際後台畫面都不對外揭露。這一頁的重點放在系統架構、資料模型與技術決策上，這些是可以說明我們處理這類專案能力的部分。如果您正在評估類似的系統，我們可以在會議中就實作細節做更完整的說明。
因為所有跟錢與責任有關的事情都發生在房間層級。租約是簽在某一間房、租金是按房收、修繕是修某一間、房客也是住某一間。如果把整棟樓當成最小單位，一棟樓裡有五間房分別出租、分屬不同屋主時，帳就完全算不清楚。此外實務上很常見一個物件裡的房間分屬不同屋主，所以屋主跟房間必須做成多對多關係，而不是讓屋主直接掛在物件底下。這個模型如果一開始定錯，後面每一個流程都要繞路補救。
看起來比較省，實際上兩邊都不好用。總後台的使用情境是坐在桌機前一次處理幾十筆資料，需要密集的表格與批次操作；現場人員的使用情境是站在房子裡用手機回報一件事，需要大按鈕與最短路徑。這兩種對資訊密度的要求是相反的，用同一份版面去 RWD，結果通常是桌機版空曠、手機版擁擠。我們的做法是拆成兩套前端，但共用同一組 GraphQL API 與同一個 UI 元件庫，這樣針對各自情境最佳化的同時，維護成本並不會變成兩倍。
只要營運橫跨不同時區，時間就會變成最容易出錯的地方。我們把它拆成三層：資料庫一律以 UTC 儲存，避免夏令時間與時區換算污染原始資料；畫面顯示時依登入者所在時區轉換，讓每個人看到的都是自己習慣的時間；而營運判斷——例如租金是否逾期、當日報表的區間——則固定用營運所在地的時區，因為這是營運上唯一有意義的基準。三層分開之後，人在哪裡登入都不會影響帳務判斷。
