住宅のアフターサービスをデジタル化するなら、受付と対応記録から
「洗面台の下が濡れている」。こうした連絡を受けたら、発見時刻や濡れている場所、設備の型番、写真、止水栓を閉めたかどうかが分かると対応を進めやすい。とはいえ、慌てている施主に最初から長いフォームを埋めてもらうのは難しい。住宅のアフターサービスで使うデジタルツールには、必要な情報を少しずつ集め、次に誰が何をするかを明確にする役割を持たせたい。
引渡し後の相談は、修理だけではない。設備の使い方、定期点検、保証内容の確認、部品交換など、接点は長く続く。受付フォームと案件管理、住宅ごとの資料、日程調整、現場記録をつなげれば、担当者が替わっても経緯を追いやすい。ただ、ツールが増えて窓口まで分散すると、施主はどこへ連絡すればよいか迷ってしまう。
まず「受付」と「対応記録」を分けて考える
施主から見た入口は、できるだけ分かりやすくする。アプリやWebフォームを主な窓口にしても、電話をなくす必要はない。水漏れや停電など緊急性のある相談では電話を優先し、受けた担当者が後から同じ案件台帳に記録する。窓口ごとに記録先が違うと、折り返しが重複したり、対応が漏れたりしやすい。
氏名・住所・連絡先を毎回入力してもらうより、本人確認後に受付内容を住宅情報へひも付ける設計がよい。最初に尋ねるのは「場所」「症状」「いつから」「写真を添付できるか」程度にとどめ、足りない情報は担当者が追加で確認する。写真は全景と気になる箇所の近景があると位置をつかみやすいが、危険な場所に近づいてまで撮影を求めてはいけない。

案件台帳には、次の行動が分かる情報を残す
社内の案件管理画面には、受付日時、対象の住宅、相談内容、緊急度、担当者、次の連絡予定、現在の状態をそろえる。状態が「確認中」だけでは、施主にも引継ぎ先にも先が見えない。「設備業者へ確認依頼済み・翌営業日に施主へ連絡」のように、誰の返答を待ち、いつ連絡するかまで記す。完了時には作業内容、使用部品、写真、施主へ説明した内容を残しておくと、同じ症状が再発したときに役立つ。
緊急度をツールの自動判定だけに任せるのも避けたい。漏電の疑い、大量の漏水、ガスの臭いなどは通常の予約フローから分け、受付画面に緊急連絡先と安全上の案内を表示する。夜間・休日に誰が電話を受け、協力業者へどう連絡するかは、通知設定とは別に決めておく。
住宅ごとの資料を「探せる」状態にする
修理のたびに紙の引渡しファイルを探すのは、施主にも事業者にも負担だ。住宅ごとの保管場所に設備の取扱説明書、保証書、点検記録、施工時の写真を分類しておけば、問い合わせ時に参照しやすい。ただし、図面や写真をまとめて置くだけでは探しにくい。設備名、設置場所、型番、引渡し日を検索の手掛かりにする。
資料ごとの公開範囲も分ける。施主向けの説明書、社内用の施工メモ、協力業者に渡す作業情報は同じ扱いにはできない。図面を共有する前に不要な個人情報が含まれていないかを確かめ、外部業者が閲覧できる期間も設定する。写真の撮影日や図面の版が不明なら、現況と一致すると決めつけず、訪問時に確認したい。
施工から保守への引継ぎを整理する際は、建設業務のデジタル化を情報の受け渡しから見直す考え方も参考になる。アフター担当が必要とする資料を、引渡し時に誰が登録するかまで決めておけば、入居後の問い合わせを受けてから集め直す手間を減らせる。
施主への通知は「返信できる約束」に絞る
自動返信で受付完了をすぐ伝えられても、「担当者が確認します」だけでは、施主はいつ連絡が来るか分からない。営業時間内の確認目安、営業時間外の扱い、緊急時の電話番号を短く示すほうが役に立つ。点検予約の通知には日時に加え、訪問予定の時間帯、所要時間の目安、事前に確認してほしい設備を添えると、施主も準備しやすい。
進捗通知を送るのは、施主に関係する状態が変わったときでよい。たとえば訪問日の確定、部品の入荷予定の変更、作業完了と報告書の公開といった節目だ。社内作業が進むたびに通知すると、肝心の連絡が埋もれる。アプリ通知を見ない施主もいるため、希望する連絡手段を受付時に確認しておく。
定期点検と修理依頼を同じ画面で混同しない
予定を組んで行う定期点検と、突然の不具合相談では、必要な操作が違う。点検画面には対象期間、予約候補日、当日の確認項目、点検結果を順に示す。修理依頼画面では症状の受付と折り返し予定を優先する。どちらも同じ「お問い合わせ」欄に入れると、点検予約の変更と緊急相談が一つの一覧に並び、優先順位を付けにくくなる。
訪問担当者がスマートフォンで点検結果を記録するなら、項目ごとの選択肢だけでなく、所見を書ける欄も設ける。「異常なし」の一語では、どこを確認したのか後から追えない。施主向けの報告書では専門用語を並べず、確認箇所、結果、今後の対応を分けて書く。修理を提案するときも、点検で確認できた事実と、追加調査が必要な推測は区別する。

IoTのデータは診断結果ではなく、確認の手掛かり
住宅設備のアプリやセンサーで、温湿度、機器の稼働状況、異常通知などを確認できる場合がある。施主から給湯器のエラー表示を伝えてもらえれば、訪問前に取扱説明書や確認項目を用意しやすい。一方、通知が出ていないから故障していないとは言えず、遠隔で見える数値だけで原因を断定することもできない。
機器データをアフター対応に使う前に、取得するデータ、閲覧できる人、保存期間、施主の同意、通信できないときの扱いを確認する。家族の生活パターンを推測できるデータまで常時集める必要があるかは、慎重に考えたい。機器同士の連携を検討するなら、スマートホームの相互運用規格Matterの概要が規格の背景を知る手掛かりになる。ただし、設備が規格に対応していても、修理受付システムとのデータ連携まで保証されるわけではない。
小規模な住宅会社は、一つの対応業務で試す
施主アプリ、現場報告、設備データを最初からすべて連携させようとすると、設定も運用も重くなる。まずは修理依頼の受付から完了報告までを一つの案件台帳で扱い、既存の電話窓口も含めて試す。試行時には、次の点を確かめたい。
- 電話・メール・フォームから入った相談を、誰が案件台帳に登録するか
- 担当者が休みのとき、未対応案件を誰が確認するか
- 施主への初回連絡と次回連絡の予定を、どこに記録するか
- 協力業者へ渡す情報から、不要な個人情報を除けるか
- 完了後に、施主と社内の双方が作業結果を確認できるか
効果はアプリの登録者数だけでは測れない。受付から初回連絡までの時間、予定どおり折り返せたか、同じ内容を施主に聞き直した回数、点検後の報告書作成にかかる時間など、待ち時間や手間に近い指標を見る。数字をよく見せるために案件を形式上「完了」にすると、再連絡を見落としかねない。何をもって完了とするかも先にそろえておく。
ツールを選ぶときは、スマートフォンでの入力しやすさに加え、案件一覧の書き出し、権限設定、操作履歴、退職者のアカウント停止、障害時の代替手順を確認する。アプリを使えない施主にも、電話で同じサービスを提供できるようにしたい。一本化するのは施主の連絡手段ではなく、社内の対応記録だ。
試行する最初の案件では、受付直後に「次回連絡予定日」を必ず入力してみる。その日になったら担当者以外も一覧で確認できるようにする。部品待ちで作業が止まっていても、施主への連絡まで止めないための、小さく始められる運用だ。