すべてのレビューとすべてのリストを、たった一つの場所で。

サービスが実際に提供された際に送信されたリクエストは回答されるが、週次バッチで送信されたものは回答されないためです。Reputation は予約、注文、およびジョブを読み取り、それがいつ行われたかを把握します。

接続するすべてのプラットフォームからのレビューを 1 つの受信トレイに集約し、4 つのダッシュボードに 4 つのパスワードを入力して返信する必要がなくなります。

彼らは、誰もあなたをレビュー対象として見つけるかどうかを決定します。リストとレビューを一元管理することは、評判管理とレビューの優先順位付けの違いです。

プラットフォームが公開する場合は、はい。価値は主に将来を見据えたものであり、ポイントは今後適切なタイミングで問い合わせることにあります。

いいえ。ドラフトとして作成された返信は公開前に承認キューを経由するため、不満に満ちた返信が顧客が読む前に、アカウント所有者によって検知されます。

はい。Brand Guard は、Purview で宣言された基準に対して、入力するたびに各ドラフトをスコアリングし、公開前にトリガーするルールをリストアップします。ブロックするのではなくフラグを立てるため、判断は返信する者に委ねられます。

リクエストのハッピー・スレッショルド（目標値）に達している回答者は公開プラットフォームへ送られ、それ未満の者は私的フィードバックへ誘導されるため、公開レビューになる前に懸念を把握できます。

はい。各ロケーションは独自のレビュープロフィール、プラットフォーム接続、評価、レスポンスレートを維持し、チェーンの平均値内ではなく独自の行としてスコアボードに表示されます。

はい。プラットフォームごとに競合をトラッキングし、Google、TripAdvisor、Yelp および接続した他のプラットフォーム上で、自社の評価とレビューボリュームとの差分（デルタ）を並べて確認できます。

はい。受信トレイ、コンポーザー、キャンペーン、分析、リスト、およびロケーションページはすべて独立して動作します。プラットフォームの残りの部分は文脈を追加します：レビューの背後にある訪問者、レビュアーの背後にある顧客、そして修正を送信する場所です。

レビューと訪問は、統合で結合された 2 つのシステムではなく、同じデータベース内の行です。予約、注文、シフト、検査は、レビューが到着する同じコンタクトと同じロケーションに対して既に登録されています。

はい。所有者とステータスが付与されたアクションアイテムとなり、そこから Desk でのサポートチケット、Dispatch でのフィールドジョブ、または Assure での再検査へと進みます。その作業が完了した時点でカードは閉じられ、誰かが返信を入力した時点ではありません。