ホーム/ 導入事例/ 予約・シフトの書き出しと電話番号の申込書を、同じ仕組みで発行

予約・シフトの書き出しと電話番号の申込書を、同じ仕組みで発行

DocRelay の画面と事例の題

予約・顧客・シフト・スタッフのデータの書き出しと、AI 電話受付の番号の申込書を DocRelay で発行しています。書き出しと書類の作成を同じ仕組みにまとめました。

導入前の課題

  • 予約・顧客・シフト・スタッフのデータを表計算で使いたいという要望
  • AI 電話受付の番号の申込書など、決まった様式の書類も必要だった
  • 出力ごとに処理を開発すると、保守の負担が大きくなる懸念があった

導入後の効果

  • データの書き出しと申込書の PDF を、DocRelay から発行
  • 項目や様式はテンプレートで管理し、変更にも柔軟に対応
  • 開発を予約とシフトの機能に集中できるように
導入企業SaaS 企業
導入製品DocRelay
導入時期2026 年 10 月

同社は、歯科医院やクリニック、整備工場などの店舗に向けて、予約とスタッフのシフトをまとめて管理するクラウドサービスを提供しています。予約の受付から、スタッフの勤務の割り当て、AI による電話での予約の受付までを一つのサービスで扱えることが特徴で、複数の拠点を持つ医院や店舗にも利用されています。

予約やシフトの情報は、日々の受付の中で着実に蓄積されていきます。利用する医院や店舗からは、その情報を手元の表計算ソフトで扱いたいという声が寄せられていました。あわせて、AI 電話受付で使う電話番号の申し込みには、決まった様式の書類が欠かせません。同社は 2026 年 10 月、データの書き出しと書類の作成を DocRelay にまとめました。その取り組みを順にご紹介します。

医院や店舗が手元で使いたい、予約とシフトのデータ

予約・シフト管理のサービスには、予約の日時や内容、来院・来店する顧客の情報、スタッフの勤務の予定といったデータが日々記録されます。多くの医院や店舗は、こうしたデータをサービスの画面で確認するだけでなく、表計算ソフトに取り出して独自に活用したいと考えています。

たとえば、月ごとの予約の件数をメニュー別に集計して経営の判断に使う、スタッフの勤務の実績を給与の計算に回す、顧客の情報を院内や店内の別の台帳と照らし合わせるといった使い方です。サービスの画面だけでは、医院や店舗ごとに異なるこうした使い方のすべてに応えることはできません。

そのため同サービスでは、予約・顧客・シフト・スタッフのデータを書き出す機能を提供しています。利用する医院や店舗が自分たちのデータを自由に扱えることは、サービスを安心して使い続けてもらうための前提でもあります。

書き出しの機能に求められるのは、表計算ソフトで開いたときにそのまま使えることです。項目の並びがわかりにくかったり、日付や時刻の表記がそろっていなかったりすれば、利用者は書き出したあとに手作業で整える必要が生じます。データを取り出せるだけでなく、取り出したあとの作業が少ないことが重要でした。

また、顧客やスタッフの情報には個人に関わる内容が含まれます。書き出しの内容に誤りがあれば、医院や店舗の業務に支障が出るだけでなく、情報の扱いに対する信頼にも影響しかねません。書き出しの項目を正確に保ち、変更のたびに結果を確かめられる仕組みが求められていました。

書き出しごとに異なる項目と、処理の保守

書き出しの対象となるデータは、予約、顧客、シフト、スタッフと種類が多く、それぞれに含まれる項目も異なります。予約であれば日時やメニュー、担当のスタッフ、顧客であれば氏名や連絡先、シフトであれば勤務の日と時間帯といった具合です。

同社が当初想定していたのは、書き出しの種類ごとに出力の処理を開発する方法でした。しかしこの方法では、項目を追加したり、並び順を見直したりするたびに処理を書き換える必要があります。サービスの機能が増えれば、書き出しに加えたい項目も増えていきます。

同サービスは、歯科医院やクリニック、整備工場など、性格の異なる業種の医院や店舗に使われています。業種によって予約のメニューの名前や項目の呼び方が異なるため、書き出しの項目にもそれぞれの業種に合った表記が求められます。書き出しの種類と業種の組み合わせが増えるほど、処理を個別に持つことの負担は大きくなります。

データの書き出しは、サービスの中心となる機能ではないものの、利用者の信頼に関わる大切な機能です。その保守に開発の時間を取られ続けることは避けたいというのが、同社の考えでした。

電話番号の申し込みに必要な、決まった様式の書類

もう一つの出力が、AI 電話受付で使う電話番号の申込書です。同サービスの AI 電話受付では、医院や店舗が専用の電話番号を持ち、かかってきた予約の電話に AI が応対します。この電話番号を使い始めるには、申し込みの内容を記載した書類を整える必要があります。

申込書は、利用する医院や店舗の名称や所在地、申し込みの内容など、決められた項目を決められた様式で記載した書面です。データの書き出しとは異なり、表計算ソフトで扱う一覧ではなく、体裁の整った PDF として発行することが求められます。

同社は当初、この申込書の作成もサービスの中で独自に開発することを検討していました。しかし、書面のレイアウトを一から作り込み、様式の見直しのたびに処理を修正していくことは、データの書き出しとは別の保守の負担を生みます。書き出しと書類という性質の異なる出力を、それぞれ別の方法で抱えることへの懸念がありました。

書き出しと書類を、同じ基盤で扱うという選択

同社は、データの書き出しと申込書の作成を、同じ基盤で扱える方法を探しました。表計算ソフト向けの書き出しだけを扱える方法や、書面の作成だけを扱える方法では、出力の仕組みが別々に分かれ、保守の手順もそれぞれに必要になります。独自に開発する案も、書き出しと書面の双方を社内で作り込むことになり、当初の懸念を解消できるものではありませんでした。

DocRelay は、Excel のテンプレートとレイアウトのテンプレートを同じ基盤で扱い、API にデータを渡せば CSV や PDF を発行できます。データの書き出しは Excel のテンプレートで項目を定め、申込書はレイアウトのテンプレートで様式を定めるという形で、性質の異なる出力を一つの仕組みにまとめられる点を評価しました。

出力の項目や様式をテンプレートの側で管理できることも重要でした。サービス側はデータをそろえて渡すことに専念し、どの項目をどの順で並べるか、書面のどこに何を記載するかはテンプレートが受け持ちます。この分担であれば、項目の追加や様式の見直しをサービスの開発と切り離して進められます。

テスト環境と本番環境が分かれていることも、選定の理由の一つです。顧客の情報や申し込みの内容を扱う出力であるため、本番環境に反映する前に、テスト環境で結果を確かめられることは欠かせない条件でした。

Excel のテンプレートで項目を定め、テスト環境で確かめる

導入は、データの書き出しから進めました。予約・顧客・シフト・スタッフのそれぞれについて Excel のテンプレートを作成し、項目の並びや見出しの表記、日付と時刻の書式を定めています。業種によって表記が異なる項目も、テンプレートの側で扱えるようにしました。

テンプレートを作成したあとは、テスト環境で実際の利用に近いデータを使って書き出しを行い、表計算ソフトで開いたときの見え方を確かめました。項目の抜けや表記の揺れがないか、件数の多いデータでも問題なく書き出せるかを一つずつ確認しています。

申込書は、レイアウトのテンプレートで様式を作成しました。名称や所在地の長さが医院や店舗によって異なるため、記載が長くなった場合でも欄に収まるかを、テスト環境でさまざまなデータを使って確かめています。

切り替えにあたっては、書き出しの種類ごとに、従来の想定どおりの項目がそろっているかをテスト環境で一覧にして確かめました。予約と顧客、シフトとスタッフのように関連するデータは、書き出した結果を突き合わせて食い違いがないかも確認しています。

確認を終えたテンプレートから本番環境に公開し、サービスの画面から書き出しや申込書の発行を行えるようにしました。利用する医院や店舗の操作は画面の中で完結し、出力の仕組みが DocRelay に移ったことを意識する必要はありません。

社内では、書き出しの種類ごとにどのテンプレートを使っているか、項目を変えるときに何を確かめるかを手順としてまとめ、開発の担当者の間で共有しました。業種ごとの表記の違いもテンプレートの側で扱うと決めたことで、サービス側の処理に業種ごとの分岐を増やさずに済んでいます。出力の扱い方が一か所にまとまったことで、担当者が替わっても同じ手順で対応できるようになりました。

導入後の構成(データの書き出しと申込書)。SaaS → レンダリング API(HTTPS(API キー))。テンプレート → レンダリング API(公開された版)。テスト環境・本番環境 → テンプレート。レンダリング API → データの書き出し(ファイルを返す(HTTPS))。レンダリング API → 番号の申込書(ファイルを返す(HTTPS))。

書き出しと申込書の発行を、サービスの外に

現在、同サービスでは予約・顧客・シフト・スタッフのデータの書き出しと、AI 電話受付の番号の申込書の PDF を、DocRelay から発行しています。性質の異なる出力が同じ仕組みにまとまり、サービス側はデータを渡すだけで済むようになりました。

出力の項目や様式はテンプレートで管理されているため、変更にも柔軟に対応できます。書き出しに項目を加えたい場合や、申込書の様式を見直したい場合も、テンプレートを修正してテスト環境で確かめ、本番環境に公開すれば反映されます。

サービス側は出力の処理を個別に持つ必要がなくなり、同社は開発を予約やシフトの機能に集中できるようになりました。予約の受付の流れやシフトの組み方といった、利用する医院や店舗の日々の業務に直結する機能の改善に、より多くの時間を充てられています。

利用する医院や店舗にとっても、書き出したデータをそのまま表計算ソフトで扱えることで、集計や照合にかかる手間が軽くなっています。AI 電話受付の申し込みも、必要な情報を画面で入力すれば決まった様式の書類が整うため、書類の作成に迷うことが少なくなりました。申込書の記載の漏れや様式の誤りによる差し戻しを防ぎやすくなったことも、申し込みを円滑に進めるうえでの利点です。

お知らせの書類にも活用を広げる

同社は今後、医院や店舗に向けたお知らせなどの書類にも、DocRelay の活用を広げていく予定です。書面の様式をテンプレートで管理し、サービスからデータを渡して発行するという同じ流れで、新しい書類も扱えます。

データの書き出しについても、利用する医院や店舗の要望に応じて、項目の追加や新しい書き出しの種類を検討していきます。テンプレートの追加で対応できるため、要望を受けてから反映するまでの道のりも短くなりました。

AI 電話受付の申し込みについても、申し込みに必要な項目や様式に見直しがあった場合には、テンプレートの修正で応じていきます。医院や店舗が迷わずに申し込みを進められるよう、書類の分かりやすさを保ち続けることも、同社が大切にしている点です。

予約とシフトの管理を通じて医院や店舗の業務を支えるという同サービスの役割は変わりません。同社は、出力の仕組みを DocRelay に任せることで、その役割に一層集中していく考えです。

主な利用機能

  • Excel のテンプレート
  • レイアウトのテンプレート
  • CSV・PDF の発行
導入事例一覧へ戻る
導入後の構成(データの書き出しと申込書)。SaaS → レンダリング API(HTTPS(API キー))。テンプレート → レンダリング API(公開された版)。テスト環境・本番環境 → テンプレート。レンダリング API → データの書き出し(ファイルを返す(HTTPS))。レンダリング API → 番号の申込書(ファイルを返す(HTTPS))。

DocRelay のご相談

業種や規模を問わず、まずはお話を伺います。