サポートケースの提出方法

何を含めるべきですか？

• 明確な要約。 問題またはリクエストを1文で述べてください。
• 影響を受けたワークフローまたはエリア。 Booking Ninjasのどこで問題が発生するのかを説明してください。
• 期待される結果と実際の結果。 期待していたことと、実際に何が起こったのかを述べてください。
• ステップまたは例。 問題を再現できる場合は、その問題に至るまでのアクションを含めてください。
• 影響を受けたユーザーまたはレコード。 プライベートな資格情報を公開せずに、有用な例を特定するための十分なコンテキストを提供してください。
• スクリーンショットまたはサポート証拠。 問題を理解しやすくするために、それらを追加してください。
• ビジネスへの影響。 どの作業がブロックされているのか、誰が影響を受けているのか、回避策が存在するかどうかを説明してください。

影響と緊急性をどのように説明すべきですか？

問題が運用にどのように影響しているのかを説明し、「緊急」とだけ書かないでください。例えば：ユーザーが予約を完了できない、1つのチームがブロックされている、1つの顧客レコードが影響を受けている、または問題が一時的に回避できる場合などです。

サービス管理のガイダンスは、影響と緊急性を分けることが一般的です。影響はビジネスがどれだけ影響を受けているかを説明し、緊急性はその影響がどれだけ早く重要であるかを説明します。両方のコンテキストを提供することで、サポートチームはあいまいな優先度ラベルに頼ることなく状況を理解できます。

何を避けるべきですか？

• パスワードやプライベートな資格情報。 ケースの説明やスクリーンショットにそれらを記載しないでください。
• 1つのケースに複数の無関係な問題。 別々のトピックは、別々に追跡する方が簡単です。
• 説明なしのスクリーンショットのみ。 期待される結果と問題に至るアクションを追加してください。
• 単に「緊急」とだけ。 実際のビジネスへの影響と回避策が存在するかどうかを説明してください。

すでにダイレクトメッセージを送信した場合はどうなりますか？

WhatsAppやメールを通じてBooking Ninjasに連絡し、問題が調査または正式なフォローアップを必要とする場合は、サポートケースを開き、重要なコンテキストをそこに記載してください。

調整のためにダイレクトメッセージを使用することはできますが、ケースは追跡される問題の主要な記録となるべきです。すでにケースが存在する場合は、別のメッセージ履歴を作成するのではなく、それを参照してください。

提出後はどうなりますか？

チームはケースをレビューし、理解またはテストするために追加情報を求める場合があります。次のプロセスについては、サポートケースを提出した後に何が起こるかをお読みください。

情報源とさらなる読み物

• 変更がどのようにテストされるか — 変更がテストされる必要があるときに、明確なシナリオと期待される結果が重要である理由を説明します。
• Salesforceヘルプ：ケース管理のベストプラクティスガイド — 関連するケースの詳細をキャプチャし、構造化されたケースプロセスを維持することの価値を説明します。
• Atlassian：影響と緊急性が優先度を計算するためにどのように使用されるか — ビジネスへの影響、緊急性、優先度の一般的な区別を説明します。

外部の情報源は一般的なサービス管理の実践をサポートします。Booking Ninjasは、サポートケースのために異なる内部フィールドやワークフローを使用する場合があります。