Bookingsの各画面について、確認してみました。
【予定表】
Office365利用者が確認する画面です。
日、稼働日、週、月という表示方法を選択して誰にどれだけ予定が割り振られているのかを確認します。
担当者を指定しない予約も考慮されており、そのケースは一番左側に表示されます。
【予約ページ】
予約ページでは利用者が利用する予約画面を作成します。保存して公開したのちに、URLが表示されます。
公開用のURLはOWA配下の深い階層のため、そのままの利用はちょっと厳しい印象があります。
上部の埋め込みボタンを押すことで、iFrameの記載方法が表示されるので、AzureなどでWebサイトを開設したうえでつなげる使い方をイメージしているのかと思います。
ちょっと複雑な感があるので、Azureの取得から一貫してくれないか、期待したいところです。
ちなみにアドレス体系は以下の形。ちょっと長めです。
https://outlook.office365.com/owa/calendar/XXX@XXX.onmicrosoft.com/bookings/
アクセスすると、サンプルと同じように以下の画面になります。
【顧客】
認知した顧客がいる場合、ここに追加することができるようです。
予約を入れてくれた顧客の情報は自動的にここで管理されます。
【スタッフ】
Bookingsの中で予約を処理する人。となります。
ライセンスが付与されたユーザーは自動的に入ってくるようです。（＝今のところ、１テナント１Bookingsなのでしょう。複数店舗を持つ美容院などは適用が難しいのかもしれません。）
スタッフの手動追加も可能で、手動追加の際はライセンスがなくても追加できます。（ゲスト扱い）
その場合は割り当てのみできて予約を開くことができないようです。
【サービスの管理】
この画面では、提供するサービスを決めていくことができます。
今のところACLの概念は無いようで、すべてのサービスをすべてのユーザーに公開するつくりになるようです。
サービスを追加する場合は、どのスタッフが捌くのかなど、入力していきます。
最後に、Bookingsアプリ自体は無料昨日ですが、Bookingsを利用するためにはExchange Online P2のライセンスが必要とのこと。
本当はこの手の仕組みはF1で使えるようになってほしい感じがしますね。
全般的にOffice365を使っていくユーザーのすそ野を増やしたい感がよくわかる機能構成でした。
後はやっぱりライセンスの緩和と複数Bookingsの利用でしょうか。このあたりが整備されてくると使い勝手がよくなりそうなので、今後に期待していきたいところです。
音楽：地の淵の原理
