ConnectWiz Booking
データベースに芯のある予約台帳。
担当者が取っても、AI が取っても、フローが取っても、顧客自身が取っても、予約はすべて1つの台帳に落ちます。その台帳では部屋・機材・担当者が正しく交差し、二重予約はストレージ層そのものが弾き、実際のカレンダーとは双方向で同期します。
4つの入口
誰が取っても、同じ真実に対して押さえる
チームは予約台帳で
日表示の予約台帳と、予約管理の全体。種別、場所、担当者、サービスのバリエーション、テナントごとに定義できるステータス表記、無断キャンセルの扱い、明細行まで。
AI は2つの動詞で
Wiz は実際に空いている枠を提示し、顧客が選んだ枠を押さえます。あえて2段階にしています。最初の空き枠を相手のために勝手に押さえるのは、サービスではなくデモの小技だからです。
訪問者は自分で
ConnectWiz の ウェブサイトのウィジェットの予約ミニアプリでは、顧客がリアルタイムの空き状況から自分で選べます。表示されるのは、予約できるサービスを実際に提供しているときだけです。
リソースのモデル
部屋・機材・人が、現実と同じように交差する
「空いている」は3つの軸の問いです。担当者と部屋と機材が、同時に空いていなければなりません。多くの予約ツールは1つの軸だけをモデル化して祈ります。こちらは交差そのものをモデル化しています。
役割と入れ子
1件の予約は、役割ごとに複数のリソースを押さえます。部屋、機材、担当者です。入れ子の関係があるので、予定の入った部屋の中にある機材は、誰もその機材を予約していなくても正しく「使用不可」になります。
ルールではなく、制約で
重複の防止は、排他制約としてストレージ層にあります。同時に走った2つの要求が両方とも通ることはありません。2つ目の書き込みが物理的に拒否されるからです。ルールエンジンは約束しますが、制約は保証します。
定員は「口」で数える
8席のクラスは、カウンターの数値ではなく8つの口です。だから「残り1」は特定の1口についての事実になり、返金で計算が狂うこともありません。
可否の判定は別建てで
「この部屋でこのサービスを提供できるか」は、稼働状況とは別の独立したマトリクスです。だから空いてはいるが不適切なリソースが提示されることはなく、その理由もあとから確認できます。
カレンダー同期
自社のカレンダーを、空き状況から差し引く
予約は外へ送り出す
予約は Google、Outlook、Apple のカレンダーに予定として現れ、キャンセルすれば消えます。担当者のスマートフォンのカレンダーが、予約台帳より1日遅れることはありません。
予定ありの時間は取り込む
外部の予定は空き状況から差し引かれます。個人の Google カレンダーに木曜15:00の歯医者が入っているなら、AI がその枠を提示することはありません。
取得元ごとに役割と向きを設定
接続した取得元には、それぞれ設定があります。読み取り、書き込み、両方、予定ありの時間だけ。だから院内の共有カレンダーと個人のカレンダーが、けんかせずに別の役割を果たせます。
リマインダーと運用
やりきる部分を自動化
ちゃんと発火するリマインダー
設定したリードタイムで、顧客への確認とリマインダーを送ります。メールで、必要なら SMS も。新規予約時にはスタッフへの通知も出ます。「あとで連絡する」が、記憶に頼らなくなります。
履歴は移行して持ち込む
ほかの CRM から乗り換える場合はどうなるか。移行エンジンが、既存の予約履歴を同じ台帳に取り込みます。予約台帳が記憶喪失の状態から始まることはありません。
包み隠さない但し書き
計画を立てる前に明記しておくこと
単独の予約リンクはまだなし
顧客自身による予約は、ウェブサイトのチャットウィジェットの中にあります。メールで送れる Calendly 型の公開予約ページは、まだありません。それが事業の中心の動きであれば、お知らせください。ロードマップに影響します。
外部 CRM が運べる情報は少ない
予約を接続済みの CRM へ書き出すとき、機材や消費の詳細は残らないことがあります。ベンダーの API がその軸を公開していないためです。同期は、黙って捨てるのではなく、何を落としたかを伝えます。
台帳は常に当社側
どのカレンダーや CRM を接続しても、予約の台帳は ConnectWiz 自身のテーブルのままです。外部システムは取得元であり鏡であって、原本ではありません。これは設計上の立場であり、明示しておきます。