
最初の対象を一つの受付窓口に絞る
例では修理相談フォームから届く問い合わせを、二名の担当者が処理する画面を作ります。メール、SNS、電話を全て同期する仕組みから始めず、受付ID、件名、相談内容、返信先を保存します。最初の完成条件は、未対応の相談を担当者が引き取り、回答した記録を残せることです。AIには顧客向けの送信画面と社内向けの一覧を分けて説明し、顧客が管理画面のURLを知っても一覧を取得できない構成を指定します。受信メールの全件転送や自動返信は、管理の基本ができてから検討します。
相談、回答、担当変更を別々に記録する
ticketsには受付ID、現在の担当者、状態、更新版番号を置きます。messagesには受付IDに結び付く顧客文、担当者の回答、作成者、時刻、社内メモか顧客へ送る文かの区分を持たせます。担当変更は履歴へ残し、現在の担当者だけを書き換えて経緯を消さないようにします。LovableのSupabase連携を使う場合は、これらの表をどの権限で読むかも確認します。社内メモを公開画面の応答へ混ぜず、顧客自身の相談だけを照会できる仕組みが必要なら、その認証方法を別途決めます。
状態を操作の結果として変える
未対応、対応中、顧客の返答待ち、完了という例を用意し、それぞれへ移る操作を決めます。回答の下書きを保存しただけで完了にはしません。顧客へ確認事項を送信できたら返答待ちへ移り、作業が終わったと担当者が判断したら完了へ進む設計にします。利用者が直接任意の状態名を送っても、その変更が権限と現在状態に合うかサーバーで確認します。古い画面から完了済み案件を対応中へ戻す場合は、意図しない更新にならないよう再開理由と最新の状態を確認させます。
回答を取り消す場合は、下書きの削除と送信済み回答の訂正を区別します。送信後の文章を画面だけ書き換えても相手の受信内容は変わらないため、訂正文を別の履歴として残します。

回答文の保存と送信を分ける
下書きの保存、送信の依頼、送信先サービスの結果を別の状態で扱います。送信が失敗したのに画面だけ「回答済み」へ進む処理や、確認なしで同じ内容を何度も送る処理を避けます。回答を送る際は受付ID、回答の版、宛先を固定して送信要求を記録します。外部配信を追加する前は、下書きと手動送信した記録までの版でも構いません。自動化する場合は利用するメールサービスの仕様を確認し、再試行で同じ送信を識別するキーと、担当者が結果を照合する画面を用意します。
二名の担当者が触る例で確かめる
架空の受付T-021を二名が開き、一方が担当を引き取った後にもう一方が古い画面から担当変更を送る例を用意します。期待する動作は競合を表示して最新情報へ戻すことで、最後に押した人が無条件に勝つことではありません。続いて下書き、社内メモ、送信記録を一件ずつ作り、顧客向けの確認画面には社内メモが出ないことを照合します。これは設計上の練習例です。実際の顧客の連絡先や修理内容をAIへの説明や公開用のサンプルに使わないでください。
| 場面 | 残すもの | 避ける処理 |
|---|---|---|
| 担当者が引き取る | 担当変更の履歴 | 現在の担当だけで履歴を消す |
| 下書きを保存 | 回答の版 | 送信済みへ進める |
| 送信に失敗 | 送信要求と結果 | 回答済みとして閉じる |
| 送信後に訂正 | 訂正文と元の回答 | 受信済みの文章を上書きしたと扱う |
検索と通知は未対応を探すために作る
一覧には担当者、状態、受付日で絞り込む操作を設け、本文検索だけに頼らず放置された相談を発見できるようにします。受付直後と担当変更時では通知の目的が違うため、同じ全員宛て通知を繰り返さないようにします。完了済みを通常一覧から隠す場合も、削除せず履歴として検索できる設計にします。AIには一覧の並べ替えと保存状態の変更を混同しないよう指示し、別担当者の名前や検索語を変えただけで案件の担当が更新されないことも確認します。
社内メモと顧客向け回答を区別します。送信結果が不明な場合は記録を照合します。
費用は件数より履歴と配信量で見積もる
開発支援の利用枠とは別に、公開後の相談数、回答履歴の行数、添付ファイル、通知メールを数えます。一件の相談でも何度もやり取りすれば保存と配信が増えます。全ての一覧を短い間隔で読み直すより、操作後の更新や必要な条件の取得で足りるかを検討します。保管期間と閲覧できる担当者を決めることも運用費の一部です。まずテキストの相談と少数の担当者で始め、添付資料や他の窓口を追加する際に保存先と請求条件を再確認します。
移行と障害対応で履歴を失わない
既存の表から移行する場合は、元の受付番号を残して新しい受付IDとの対応を持たせます。完了案件だけを落としたり、担当者名の表記違いで別人へ割り当てたりしないよう、小さな件数から照合します。障害時は受付の一時停止または代替窓口を案内し、復旧後に重複分を受付キーで照合します。送信結果が不明な回答を一括再送せず、配信履歴を確認できる担当を決めてください。最後に、他人の案件、社内メモ、再開、二重送信がそれぞれ意図どおり扱われることを確認して公開します。
参照した公式情報
料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。
- Lovable — Connect to Supabase情報確認日: 2026-10-30
- Next.js — Forms情報確認日: 2026-10-30
- PostgreSQL — Constraints情報確認日: 2026-10-30
- Lovable pricing情報確認日: 2026-10-26
- Lovable subscription plans情報確認日: 2026-10-26
- Lovable credits and usage情報確認日: 2026-10-26
- Lovable GitHub sync情報確認日: 2026-10-26