時計修理サービス業 × 受付・顧客対応・修理管理 × 都内4店舗・年間2万件超の公開事例（従業員総数は原本未記載）
ウォッチ・ホスピタルは、都内4店舗と全国からの集荷で時計修理を受け付けています。
年間の修理件数は2万件以上。これまでに蓄積した顧客情報と修理履歴は約15万件です。
情報が多いことは、本来なら強みです。しかし、履歴を社内の人しか探せない、Webの受付内容を社内管理へ移し直す、氏名や伝票番号で結び付ける、といった作業が残ると、件数が増えるほど負担も増えます。
同社は、既存の修理管理を捨てず、外部受付と顧客向けの確認画面をつなぎました。
公開事例では、受付フォームから社内管理への転記作業がゼロになり、顧客が24時間いつでも修理履歴や状況を確認できるようになったと報告されています。
課題：15万件の履歴があっても、確認の窓口が人だった
改善前は、顧客が過去の修理履歴や現在の状況を知りたい時、スタッフが社内の情報を検索して回答する必要がありました。
受付フォームと社内のkintoneも分かれていたため、受け付けた内容を再び入力する工程があり、転記ミスや入力漏れの心配が残ります。
公開事例の課題を、会話形式に再構成すると次のような状態です。これは原文の逐語引用ではありません。
「前回の修理内容を確認したいです」
「履歴を探して折り返します」
「Webで入力した内容を、もう一度社内の画面へ入れます」
一件では小さな手間でも、年間2万件を超える受付では積み重なります。
さらに、氏名や伝票番号は入力ゆれや重複が起きます。同姓同名、表記の違い、番号の打ち間違いがあると、別の人の履歴を結び付ける危険もあります。
施策：外から見える画面と社内の情報を一意IDでつないだ
ステップ1：顧客と修理を結ぶ番号を見直す
氏名や伝票番号だけに頼らず、顧客ごとに重ならない一意のIDを使う設計へ見直しました。
情報をつなぐ時に大切なのは、画面の見た目より「同じ人、同じ案件だと何で判断するか」です。
ステップ2：顧客向けマイページを作る
Kanal-WEBを使い、顧客が自分の修理履歴や状況を確認できる画面を用意しました。
営業時間外でも確認できるため、「履歴を調べて回答する」という人手の窓口を減らせます。
ステップ3：受付から修理管理までをつなぐ
受付、利用者一覧、顧客情報、修理管理という複数の情報を、krewDataで連携しました。
受付フォームへ入った情報が社内管理へ渡るため、同じ内容をもう一度入力する工程をなくします。
ステップ4：既存顧客を一度に移さない
約15万件の履歴があるからこそ、全顧客へ一度に案内せず、分けて移行する計画にしました。
小さなグループで、ログイン、本人との結び付き、履歴表示、問い合わせ内容を確認しながら広げる方が安全です。
成果：受付転記ゼロと24時間の自己確認
| 項目 | Before | After |
|---|---|---|
| Web受付 | 社内管理へ再入力 | フォームから社内管理へ連携し転記ゼロ |
| 履歴確認 | スタッフが検索して回答 | 顧客が24時間マイページで確認 |
| 情報の結び付け | 氏名・伝票番号中心 | 重ならないIDを軸に整理 |
| 既存データ | 約15万件を社内で保有 | 顧客向け確認にも活用 |
| 問い合わせ削減 | 原本に数値なし | 削減を狙う設計、実績値は今後確認 |
「転記ゼロ」は受付フォームからkintoneへの工程についての事例値です。時計修理全体の入力作業がすべてなくなった、という意味ではありません。
また、問い合わせ件数や対応時間が何％減ったかは、今回の原本には記載されていません。24時間確認できる仕組みができたことと、問い合わせ削減の実績は分けて扱う必要があります。
なぜ効果が出たか：新しい画面より先に、情報のつながりを直した
一つ目は、受付画面だけを新しくせず、後ろの社内処理までつないだことです。
二つ目は、既存の約15万件を捨てず、安定したIDで使える形にしたことです。
三つ目は、顧客が自分で確認できる範囲と、スタッフが判断する範囲を分けたことです。
四つ目は、既存顧客の移行を段階的に進めたことです。
システム導入では、公開日が完成日ではありません。既存データを正しく結び、利用者が迷わず使え、問い合わせの変化を測れるところまでが運用です。
他のサービス業でも応用できる
この考え方は、履歴や進捗を顧客へ返す仕事に広げられます。
- 自動車整備：点検履歴、見積、入庫状況
- クリーニング：受付品、仕上がり予定、受取履歴
- 設備修理：訪問日、作業履歴、交換部品
- 士業：依頼資料、進行状況、提出履歴
- 医療・福祉：共有してよい範囲を限定した予約・連絡状況
最初に確認したいのは、「問い合わせを何件減らしたいか」ではありません。
どの履歴なら顧客へ見せられるか。本人を何で確認するか。更新が遅れた時に誰が直すか。誤表示をどう止めるか。
この四つを決めてから、小さな対象で試します。
導入後30日で確認する運用表
顧客向け画面は、公開した瞬間より、その後の運用で品質が決まります。最初の30日は、少数の顧客に限定し、週ごとに確認項目を変えると原因を追いやすくなります。
最初の週は、本人確認とデータの結び付きを見ます。新規登録した人の履歴だけでなく、氏名変更、複数回利用、家族からの問い合わせなど、通常とは違うケースも試します。別人の履歴が見える可能性があれば、利用者数を増やす前に止めます。
2週目は、受付から社内管理までを確認します。必須項目が空の時、写真が大きい時、同じ依頼を二度送った時、連携先が一時的に止まった時にどうなるかを記録します。「転記ゼロ」を維持するには、失敗したデータだけを人が見つけられる一覧が必要です。
3週目は、顧客の言葉を集めます。ログインできない、今どの段階か分からない、表示される時刻が古い、といった問い合わせを分類します。問い合わせ総数だけでなく、内容が「履歴を教えて」から「次に何をすればよいか」へ変わったかも見ます。
4週目は、担当者の負担を測ります。受付の再入力がなくなっても、エラー確認や顧客登録が増えていれば、全体では省力化できていないかもしれません。受付、修理、顧客対応の三者で、増えた作業と減った作業を並べます。
この30日で見る指標は、転記件数、連携失敗件数、誤表示件数、問い合わせ分類、担当時間の五つで十分です。公開事例に問い合わせ削減率がない場合も、自社の開始前の数値を残しておけば、導入後の判断を自分たちの実績で行えます。
気になる業務があれば、お気軽にお声がけください。弊社では、既存データを生かした顧客ポータル、受付画面、社内管理、AI活用の伴走支援を行っています。