予約スケジュールの統合
SuperSaaSで作成したリソースタイプスケジュールは統合、連携することが可能です。 定員制スケジュールにおいては異なるスケジュール間の統合、連携機能はありません。
| 使用例 | 統合タイプ |
|---|---|
| 施術の予約には、部屋とセラピストの両方の空きが必要です。 つまり、システムは両方のリソースが同時に空いていることを確認する必要があります。 | 1件の予約に複数のリソースが必要 |
| ユーザーが予約する際に、複数の治療メニューから選択肢が与えられます。異なる治療には、それぞれ異なるセラピストの空きが必要です。 | 異なるサービスに異なるリソースが必要 |
| 支援は、ボランティアが手伝いの枠に登録した場合にのみ予約できます。 これにより、必要な支援を提供する人が常に存在するようにできます。 | 1つのリソースの確保により他が利用可能になる |
| 貸し出し用の同じ機器が20台あります。レンタル者が特定の1台を選択できるようにする代わりに、どの機器でもよいランダムな1台を予約してもらうようにした場合です。 | 複数のリソースを1つのエンティティとして提示 |
| クラブでは会員がテニスコートを予約できますが、来店客も利用できます。 会員には同じコートをより安い料金や、より先の予約枠で予約できるように設定できます。 | 1つのリソースを複数のエンティティとして提示 |
| 週の特定の曜日だけ異なる制約を適用したい場合です。その曜日専用のスケジュールを作成し、それを他のスケジュールと組み合わせることで、ユーザーには1週間全体の統一されたビューを提示できます。 | 複数のスケジュールを1つのビューに統合 |
サービススケジュールはリソーススケジュールを利用可能
SuperSaaSの3つの異なるスケジュールタイプにおいて、サービスタイプのみが統合機能を利用可能であり、統合対象はリソースタイプスケジュールに限られ、定員制スケジュールにおいては異なるスケジュール間の統合機能はありません。(デメリットとしてこの機能には、繰り返しの予約やサービススケジュールで予約時間の可変型の予約を作成できないというトレードオフがあります。)
1件の予約に複数のリソースが必要な場合
特定のサービスが同時に複数のリソースを必要とする場合、システムは予約を許可する前に全てのリソースに空きがあることを確認します。 たとえば、マッサージでは、リソースとしてセラピストが必要であり、また、 プロジェクターを備えた会議室のサービスでは、会議室とプロジェクターが各1つずつ必要です。 サービスタイプスケジュールは、異なるリソーススケジュールを横断して必要なリソースの空き状況を確認し、予約が可能となります。 これを実現するために、サービスが依存する1つ以上のリソースタイプのスケジュールを作成します。このスケジュールは、サービススケジュールを作成する前でも後でも設定できます。 詳細はこちらチュートリアルで手順を確認できます。
すべてのリソースを単一のリソーススケジュールへ、または個別のスケジュールに配置することも可能です。 原則として、交換可能なリソースがある場合、たとえば、複数の部屋があり、そのいずれかでサービスを提供できる場合、それらを同じリソーススケジュールに配置することが最善です。
変形例として、1件の予約に対して同一のリソースを2つ必要とするように指定する場合もあります。 たとえば、パーテーションを使って2つに区切れるミーティングルームを持っている場合や、テニスコートを2つのピックルボールコートに分割できる場合などが該当します。 その場合、テニスコート用のサービスを別途定義し、このサービスには2つのピックルボールコートが必要であると指定し、同時にそれらを個別に予約できるように設定します。
異なるサービスに異なるリソースが必要
予約時にユーザーに複数のサービスから選ばせるようにすることができます。 各サービスは、必要なものに応じて1つまたは複数の特定のリソースを必要とします。 たとえば、特定の施術は、必要な資格を持つセラピストでのみ提供可能である場合があります。 ユーザーがサービスを選択すると、カレンダーは自動的に更新され、そのサービスを担当できるセラピストが空いている日時のみが表示されます。
あるリソースの予約により別のリソースが利用可能になる
通常、サービスは、接続されているすべてのリソースが利用可能な場合にのみ利用可能です。また、サービスが予約されると、接続されているすべてのリソースが使用中、占有済みとしてマークされます。ただし、サービスを設定するときに、ボタンをクリックしてから、リソースの横にあるボタンをクリックすると、そのロジックが反転します。 その場合、サービスは、リソースが占有されている場合にのみ利用可能になります。そのサービスを予約しても、「使用中」とマークされたリソースには影響しません。したがって、たとえば、「使用中」リソースに加えて通常のリソースも接続するなどして、サービスが複数回予約可能になるのを防ぐ必要があります。
プールされたリソースを単一のエンティティとして表示
同種のリソースをユーザーに選ばせるのが不便、あるいは望ましくない場合に役立ちます。例えば、候補者が面接官を選ぶのではなく、最初に空いている面接官を自動的に割り当てる設定が可能です。
複数のリソースを持つリソーススケジュールにサービスを接続すると、、つまり任意のリソースに接続するオプションが表示されます。 また、スケジュールを超えたリソースの統合は、ボタンより設定可能です。 サービススケジュールの設定 > サービスページにおいて、では、ユーザーがリソースを選択、またはランダムにリソースを選択、そしてスケジュールにリストされている順序で最初のリソースを利用できるようにするなどのオプション設定が可能です。
単一のリソースを複数のエンティティとして提示
リソースの総数を超えて重複予約されないようにしつつ、異なるユーザーグループに異なるスケジュールを提示できます。 たとえば、複数拠点で働くコンサルタントが、各拠点ごとの条件(料金・営業時間・サービス)で独自スケジュールを見せたい場合です。
このケースでは、基準となるリソーススケジュールを作成してから、同じリソーススケジュールに接続する1つ以上のサービススケジュールを作成します。 ユーザグループを定義して、あるスケジュールを対象としたユーザが別のスケジュールにアクセスできないようにすることができます。詳細はこちらのユーザーグループを参照してください。
スケジュールを単一画面にまとめる
スケジュールを組み合わせると解決策が得られるという点で、単一のスケジュールの設定よりも柔軟性が必要になる場合があります。例として、平日とは異なるバッファータイムを週末に設定したい場合、または、金曜日にはユーザーあたりの予約の制限数を変更して、より多くの予約を促したい場合など
この場合、2つまたはそれ以上のリソースタイプスケジュールを作成し、それらを「平日」と「週末」に分け、それぞれに異なる制約を適用します。その後、サービスタイプスケジュールを作成し、「平日」、 or 「週末」に依存するサービスを定義します。これにより、各スケジュールの設定が論理的に組み合わさった結果が得られます。スケジュールがどのように相互作用するかについての詳細は次のセクションをご覧ください。
スケジュール同士の相互作用
システムが空き状況を確認する際には、当然ながら、要求されたリソースに対して競合する予定があるかどうかを考慮します。ただし、設定できるスケジューリング制約は他にも多数あります。:- 営業時間
- 休日などの特別な日
- 予約がどれくらい前から可能かの制限
- 期間ごとまたは合計での予約数の制限
- GoogleまたはOutlookカレンダーが同期されていることの確認
ある期間が利用可能であるためには、サービスが依存する各リソースの制約を含む、これらすべての制約を満たしている必要があります。
⊗ 「占有時に利用可能」とマークされたリソースについては、すべての制約、営業時間、およびその他の可用性制限は無視されます。 サービスの可用性に影響を与えるのは、これらのリソースの予約が占有している期間だけです。
スケジュールのその他すべての設定は、その特定のスケジュールで行われた予約にのみ適用されます。例えば、確認設定で定義されたように、予約を作成したスケジュールでは1回のメールリマインダーのみが送信されます。また、価格と支払いの設定も、予約が行われたスケジュールにのみ適用されます。
サービス定義のANDとORという用語を理解することも重要です。 たとえば、スケジュールAが9:00と10:00に利用可能で、スケジュールBが10:00と11:00に利用可能である場合、スケジュールA AND スケジュールBの両方に依存するサービスは、10:00にのみ利用可能です。一方、サービスがスケジュールA OR スケジュールBに依存している場合は、9:00、10:00、11:00に利用可能になります。
依存するスケジュールでの通知のトリガー
各スケジュールの設定 > プロセスページにおいて、サービススケジュールでは、予約が連携されたスケジュールにおいて通知やWebhooksのトリガーとなるかどうか指定できます。予約が複数のスケジュールに影響を与える場合、影響を受けるスケジュールごとに追加のメールが1通送信され、影響を受けるリソースごとにWebhookが1つ送信されます。例えば、ツアーの予約で「自転車1・2・3」を確保する場合、ツアー用スケジュールで1通、自転車スケジュールで1通+3回のWebhookがトリガーされます。