予約スケジュールの統合

SuperSaaSで作成したリソースタイプスケジュールは統合、連携することが可能です。定員制スケジュールにおいては異なるスケジュール間の統合、連携機能はありません。

1件の予約に複数のリソースが必要施術の予約には、部屋とセラピストの両方の空きが必要。システムは両方のリソースが同時に空いているか確認する必要がある。
あるリソースの予約により別のリソースが利用可能になるサポートは、ボランティアが登録しているときのみ予約可能。常にサポートが提供可能な状態を保証する。
プールされたリソースを単一のエンティティとして提示する場合同一の物品が20個あり、借り手に特定のものを選ばせたくない（ランダムに割り当てたい）。
単一のリソースを複数のエンティティとして提示する場合テニスクラブでは会員も非会員もコートを予約できるが、会員は割引価格または早期予約が可能。
複数スケジュールを同一画面へ表示する曜日によって異なる制約を設定したい場合、該当する曜日だけ別のスケジュールを作成し、それらを組み合わせて1週間ビューにまとめる。

サービススケジュールはリソーススケジュールを利用可能

SuperSaaSの3つの異なるスケジュールタイプにおいて、サービスタイプのみが統合機能を利用可能であり、統合対象はリソースタイプスケジュールに限られ、定員制スケジュールにおいては異なるスケジュール間の統合機能はありません。(デメリットとしてこの機能には、繰り返しの予約やサービススケジュールで予約時間の可変型の予約を作成できないというトレードオフがあります。)

1件の予約に複数のリソースが必要な場合

特定のサービスが同時に複数のリソースを必要とする場合、システムは予約を許可する前に全てのリソースに空きがあることを確認します。たとえば、マッサージでは、リソースとしてセラピストが必要であり、また、プロジェクターを備えた会議室のサービスでは、会議室とプロジェクターが各1つずつ必要です。サービスタイプスケジュールは、異なるリソーススケジュールを横断して必要なリソースの空き状況を確認し、予約が可能となります。これを実現するために、サービスが依存する1つ以上のリソースタイプのスケジュールを作成します。このスケジュールは、サービススケジュールを作成する前でも後でも設定できます。詳細はこちらチュートリアルで手順を確認できます。

すべてのリソースを単一のリソーススケジュールへ、または個別のスケジュールに配置することも可能です。原則として、交換可能なリソースがある場合、たとえば、複数の部屋があり、そのいずれかでサービスを提供できる場合、それらを同じリソーススケジュールに配置することが最善です。

例えば、「マッサージ」というサービスには、セラピストが空いている必要があります。同様に、「プロジェクター付き会議室」というサービスを提供する場合は、会議室とプロジェクターの両方が同時に利用可能である必要があります。

バリエーションとして、1件の予約に2つの同一リソースが必要になるよう設定することが有用な場合もあります。例えば、仕切りを使って2つに分割できる会議室や、1面を2つのピックルボールコートに分けられるテニスコートなどです。この場合、テニスコート用に別のサービスを設定し、2つのピックルボールコートを必要とするよう指定するとともに、それぞれを個別に予約できるようにします。

あるリソースの予約により別のリソースが利用可能になる

通常、サービスは、接続されているすべてのリソースが利用可能な場合にのみ利用可能です。また、サービスが予約されると、接続されているすべてのリソースが使用中、占有済みとしてマークされます。ただし、サービスを設定するときに、⊗ 使用中ボタンをクリックしてから、リソースの横にある⊗ボタンをクリックすると、そのロジックが反転します。その場合、サービスは、リソースが占有されている場合にのみ利用可能になります。そのサービスを予約しても、「使用中」とマークされたリソースには影響しません。したがって、たとえば、「使用中」リソースに加えて通常のリソースも接続するなどして、サービスが複数回予約可能になるのを防ぐ必要があります。

例えば、顧客を利用可能な営業担当者と確実にマッチングさせたい場合などに、使用中のリソースを扱うことは便利です。展示会では、営業チームに1つのリソーススケジュールに登録してもらい、それにより別のサービススケジュール上で顧客が予約できる空き枠が自動的に開くようにすることもできます。別の方法として、営業チームにSuperSaaS内で自身の空き状況を反映したリソーススケジュールを作成してもらい、顧客にそのスケジュール上で予約してもらうことも可能ですが、その場合は営業チームにより多くの手間がかかります。

プールされたリソースを単一のエンティティとして表示

同種のリソースをユーザーに選ばせるのが不便、あるいは望ましくない場合に役立ちます。例えば、候補者が面接官を選ぶのではなく、最初に空いている面接官を自動的に割り当てる設定が可能です。

複数のリソースを持つリソーススケジュールにサービスを接続すると、« Any of … »、つまり任意のリソースに接続するオプションが表示されます。また、スケジュールを超えたリソースの統合は、orボタンより設定可能です。サービススケジュールの設定 > サービスページにおいて、複数リソースが利用可能な場合:では、ユーザーがリソースを選択、またはランダムにリソースを選択、そしてスケジュールにリストされている順序で最初のリソースを利用できるようにするなどのオプション設定が可能です。

上で説明したように、1つの予約に対して複数のリソースを使用する場合に、プールされたリソースを組み合わせることも可能です。例えば、5台の自転車と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に利用可能になります。

Logical AND/OR — 「論理 AND」と「論理 OR」による可用性の結合

通知とWebhook

各スケジュールの設定 > プロセスページにおいて、サービススケジュールでは、予約が連携されたスケジュールにおいて通知やWebhooksのトリガーとなるかどうか指定できます。予約が複数のスケジュールに影響を与える場合、影響を受けるスケジュールごとに追加のメールが1通送信され、影響を受けるリソースごとにWebhookが1つ送信されます。例えば、ツアーの予約で「自転車1・2・3」を確保する場合、ツアー用スケジュールで1通、自転車スケジュールで1通＋3回のWebhookがトリガーされます。

一方、サービススケジュール上で予約が他のスケジュールに移動された場合、新しいスケジュールに対してのみ更新イベントが送信されます（削除元には通知されません）。