求助通知已送出卻沒人接手，家庭事前要約定什麼？

求助通知送達手機卻無人回應：家庭面臨的真實關懷空窗

許多家庭在為長輩添購居家感測或求助設備時，往往會產生一種心理上的安全感，認為「只要長輩按得下去、手機收得到訊息，事情就解決了」。然而，現代生活步調緊湊，家庭成員可能正在主持重要會議、騎車開車、搭乘捷運，或者只是將手機切換為靜音模式。當求助通知在螢幕上亮起時，這則訊息很可能在鎖定畫面中靜止數十分鐘甚至數小時，形成一段完全沒有真人介入的關懷空窗期。

未接手的原因需要進一步了解，不能單憑單一畫面直接排除設備或通訊問題，也不應一味歸咎於家屬疏忽。在求助流程中，從按鈕觸發到真人回應之間存在不同階段；即使手機收到推播，後續由誰看見、由誰確認、由誰付諸行動，都需要仰賴家庭內部清晰的事前共識。對於尚未確認的環節應如實保留未知，並逐段檢視已知進度。

• 訊息顯示於手機只代表通知階段已觸發，不代表已有人看見或理解狀況。
• 求助發出後若未獲回應，原因可能涉及通訊品質、推播設定或家人忙碌，各環節需逐一確認。
• 家庭應將「未即時接手」列入日常應變準備，事前建立分工與手動回覆默契。

解構求助流程五階段：按下、接收、送達、接手到現場的斷點

要建立可靠的家庭備援，首先必須客觀拆解從長輩求助到實際獲得協助的完整歷程。在實務運作上，這段過程至少包含五個明確的斷點。第一階段是「住戶主動按下按鈕」，這需要長輩在有需求時身邊能取得按鈕，且具備按下的意願與動作；第二階段是「居家主機成功接收訊號」，這仰賴設備間的通訊連接；第三階段則是「系統將事件整理並推播至家人手機」，讓訊息出現在家庭軟體的通知清單中。

然而，最容易被忽視的關鍵往往落在第四與第五階段。第四階段是「真人承接責任」，也就是某位家庭成員看見通知後，在群組或軟體中明確表態「這件事我來處理」；第五階段則是「實際關懷或到場協助」，包括打通長輩的電話確認無礙、請同住鄰居探視，或是本人親自趕回現場。設備的設計角色在於如實記錄前三個階段並發出推播，但第四與第五階段的責任交接與物理行動，本質上無法由軟硬體代勞。唯有清楚劃分這五個階段，家人才能看見每個環節可能出現的中斷點。

• 第一階段：長輩取得按鈕並主動按下（受限於按鈕擺放位置與意識狀態）。
• 第二階段：主機接收到按鈕觸發事件（受限於居家硬體連線品質）。
• 第三階段：手機端接收到求助推播通知（受限於外網環境與手機通知權限）。
• 第四階段：特定家庭成員出面確認並承接聯絡責任（真人責任建立點）。
• 第五階段：完成電話確認、委託鄰里探視或實際抵達現場（實體協助落實）。

假設家庭情境：上班開會漏接通知時，預先約定的家庭備援啟動

為了具體說明備援約定如何運作，我們以一個典型雙薪家庭的日常情境作為參考。假設長輩獨自居住於台南，主要聯絡人是住在同縣市、白天在工廠上班的女兒，次要聯絡人則是住在高雄的兒子。某個平日上午十點半，長輩在家中按下了求助按鈕。此時，女兒正在進行例行品管巡檢，手機放在置物櫃未隨身攜帶；而兒子則正好在開客戶專案會議，手機雖然震動，但無法立刻中斷發言。

在沒有事前約定的家庭中，這則通知可能長時間未被注意。但如果這個家庭已預先完成手動備援約定，看見通知但無法離場的成員便能依約定主動分工。例如兒子在會議空檔看見求助推播，隨即在手動家庭聯絡群組回覆：「我開會中無法離場，已先撥媽媽市話未接，現已傳訊請對門鄰居林太太按鈴探視，後續有進展即時回報。」家庭成員看見求助但無人接手時，依事前約定主動聯絡與分工，不需空等特定倒數；若在過程中得知有緊急救助需求，應直接撥打 119 求助，而不必等待鄰居或設備進一步回報。這個假設情境說明了：技術負責傳遞求助事件，而家庭預先約定的手動步驟與分工，有助於降低無人接手時的混亂。

• 假定第一順位聯絡人失聯時，第二順位聯絡人應具備何種行動權限。
• 利用手動訊息回報目前進度，避免多位家人因資訊不同步而重複驚慌或互相推託。
• 鄰里信任人選的預先建立，有助於在遠距家人無法即時抵達時提供初步探視支援。

求助未獲即時接手時的家庭實務約定清單

家庭若希望避免「通知響了卻沒人接手」的困境，建議在設備安裝當週，召集所有共同關懷的成員，共同填寫並確認一份實體或手動的應變備忘錄。這份清單不需要複雜的技術設定，而是將責任落實為具體的聯絡先後順序與應變原則。每位成員都應清楚知道，自己如果在特定時段無法接聽電話，該時段的守望工作會由誰接替。

除了核心家屬之間的輪替，這份清單更應向外延伸至長輩居住周遭的人際網絡。例如將長輩常去的社區藥局、熟悉的大樓管理室、甚至同里的親戚電話整理成冊，並在取得對方同意後列為備援聯絡人。透過明確的手動規範，看見求助且尚未有人接手時，可依事前約定主動聯絡分工，不必等特定時間；緊急時直接求助。任何看見訊息的成員都能依照清單上的步驟逐條執行，不再因為慌亂而不知所措。

• 建立明確的順位名單：列出第一、第二、第三聯絡家屬的電話與方便接聽時段。
• 定義家庭手動回覆口訣：看見通知者主動在群組發出「我來聯絡，預計下一步…」，避免責任真空。
• 約定未接通時的處置流程：撥打長輩電話未接時，依序啟動第二順位聯絡或委託鄰里探視，不需空等固定時限；若已知危急應直接求助官方專線。
• 建立在地實體聯絡點：預先徵求熟識鄰居、大樓管理員或附近親友同意，作為緊急按鈴探視人選。
• 備用鑰匙授權規劃：如需討論備用鑰匙，由住戶同意保管人、用途與使用界線，不把保管等同任意進入權限，緊急進入交專業人員依適用程序處理。

長照支援與急難專線的適用分界：1966 與 119 的角色說明

在梳理家庭求助與外力支援時，必須清楚區分「長照與家庭照顧者支持諮詢」與「官方急難救助專線」的不同角色。根據衛福部長照專區說明，1966 專線為長照資訊與家庭照顧者支持服務的諮詢與聯絡入口，可提供家庭照顧者了解相關支持服務與家照據點資訊。1966 並非處理即時緊急事故的救援專線，不可將其視為急難派遣電話。

相對地，消防署說明 119 為台灣火災與急難救助的報案專線。如果在求助事件發生時，家庭成員透過聯繫或現場探視，已明確知悉長輩面臨立即性危險或急難事故，絕不應等待家庭成員逐一讀取通知，也不需等待感測設備回報，應由知情者立即撥打 119 報案求助。清楚掌握 1966 作為長照與照顧者支持資訊入口、119 作為火災與急難救助報案專線的定位，才能在不同情境下尋求合適的官方管道。

• 1966 長照專線：長照與家庭照顧者支持資訊的諮詢入口，非急難救援專線。
• 119 報案專線：台灣火災與急難救助報案專線，知有立即危險應即刻撥打。
• LUNAKARE 未提供自動代撥 119 或官方緊急救護派遣的承諾，家庭不能預設官方救援已被通知，若知有立即危險應由真人直接撥打報案。

定期演練與共識建立：如何與長輩溝通「按鈕後的期待」

除了家屬端的備援安排，與住戶長輩本人的雙向溝通同樣是落實求助機制的關鍵一環。許多長輩因為擔心「給子女添麻煩」，即使身體極度不適或拿不到助行器，也寧可硬撐而不願意按下按鈕；另一種極端則是長輩誤以為按鈕連通了醫院急診室，只要一按就會有救護人員破門而入，因而在短時間內因焦慮而反覆按壓。這兩種極端期待，都源自於對設備角色缺乏客觀理解。

家庭成員在配置設備時，建議以溫和務實的態度與住戶溝通按鈕的真實角色：「需要日常協助時可以按，但按下後系統無法保證家人一定即時看見或立刻到場；若遇到真正緊急危險的情境，不要只等待按鈕，請直接撥打 119 求助。」有關設備的測試方式、檢查頻率、固定或攜帶配件及適用空間，應依服務方的正式說明為準。透過平實的溝通建立共識，長輩才能在充分知情下使用求助工具。

• 明確功能期待：向住戶說明求助按鈕是通知家人的起點，但無法保證即時到場。
• 緊急處置共識：提醒住戶若遇立即急難危險，應直接撥打 119，不應只依賴按鈕。
• 確認配置與動線：按鈕之固定方式或適用空間，請參考原廠正式說明並依生活習慣配置。
• 口頭走過應變流程：平時可純口頭演練聯絡步驟與備援順位，確保家人與住戶共識一致。

LUNAKARE Help 與 Family 如何支持家庭責任交接而不做救援承諾

在 LUNAKARE 的產品架構中，LUNAKARE Help 與 LUNAKARE Family 正是為了支援上述家庭關懷流程而設計，但其角色界線非常嚴謹。LUNAKARE Help 是一款自製核心硬體求助按鈕，其設計初衷是讓住戶在有需要時能夠主動按下，建立求助事件並向家屬發送通知。系統在設計上將「按鈕記錄」、「主機接收」、「發出通知」與「家屬接手」各階段清楚分開，忠實呈現客觀歷程，而不對外提供專業官方救援派遣承諾，亦無法保證在極端斷網環境下依然能突破通訊限制。

而 LUNAKARE Family 作為家庭軟體服務，其核心價值在於整理生活紀錄、變化提醒與家庭協同通知。當 Help 按鈕被觸發時，Family 旨在協助將事件整理並推播給家庭成員，促進家人協同關懷。LUNAKARE 沒有提供自動官方救援派遣或送達的承諾；軟體是否具備外撥、排程或特定提醒設置，請向服務方確認最新正式說明。成員看見通知後主動在家庭聯絡管道中表態接手，本質上是家庭內部責任的落實。科技是記錄與傳遞的工具，關懷仍有賴家人之間預先確立的應變約定。

• LUNAKARE Help 專注於忠實傳遞求助事件，不宣稱具備代叫救護車或急難派遣能力。
• LUNAKARE Family 協助家庭成員共享求助事件資訊，促成真人責任的交接與確認。
• 系統無法預測成員何時能實際抵達現場，實體到場仍仰賴家庭手動安排的在地備援名單。

常見問題