CodexでFacebook向けの障害告知を作成

Facebook向けのCodex

予約や決済のサービスに障害が発生すると、顧客は企業のFacebookページで情報を探し、コメントを残すことがあります。技術チームが調査中でも、告知は迅速かつ具体的で、確認済みの事実に基づく必要があります。Codexはインシデントの記録と影響を受けたコードを読み、伝わりやすい文章を準備できます。Tarenoはページ向けの下書きを保存します。ここではチケット販売会社の例を通じ、確認済みの事実と仮説を分け、公開前に担当者が内容を検証する流れを説明します。

例：チケット販売会社が決済障害を知らせる

チケット購入時のカード決済が失敗し、ほかの決済方法は使える状況を考えます。当番の担当者はインシデントの記録をCodexに渡し、決済モジュールを指定します。Codexは記録と該当するコードの経路を読み、影響範囲の整理を支援します。実際の影響は技術チームが確認します。その後、影響を受ける決済方法、利用可能な代替手段、続報を伝える約60語の告知を作成し、復旧時刻は推測しません。create_draftsで告知を保存し、復旧後の投稿も予約せずに下書きします。担当者は両方をインシデントの連絡内容と照合し、最初の投稿をTarenoで依頼します。

手順

1. 01

   インシデントの記録を渡す

   Codexに現時点の記録を渡し、確認済みの事実と未確認の仮説を分けます。告知に必要な情報だけを含め、仮説が公の事実として書かれないようにしてください。

2. 02

   影響を受けたコードを指定する

   該当するモジュールを指定します。Codexはカード決済など、同じコード経路を使う処理を調べられます。実際の障害範囲は公表する前に技術チームが確認してください。

3. 03

   告知と続報を準備する

   確認済みの影響、利用可能な代替手段、次の更新について短い告知を依頼します。復旧後の下書きには未確認の事実を入れず、日時も予約しないままにします。

4. 04

   未確認の原因や時刻を取り除く

   技術チームが確認していない原因や復旧時刻が下書きにないか確認し、あれば削除します。根拠のない復旧時刻を約束せず、後ほど更新すると伝えてください。

5. 05

   両方をページの下書きに保存する

   Codexはlist_accountsでFacebookページを確認し、create_draftsで両方の文章を保存します。投稿は企業のページ名で公開されるため、承認前に両方を読んでください。

6. 06

   最初の告知を依頼して承認する

   許可される最も早い日時を依頼します。Metaのドキュメントによると、API経由の予約投稿には最低10分の余裕が必要です。依頼はTarenoのダッシュボードで本人が承認するまで保留されます。

コピーして使えるプロンプト

以下のインシデント記録とモジュール[payments/card]を読んでください。確認済みの事実、仮説、影響を受けたコード経路を使う顧客の処理を分けて一覧にし、技術チームによる確認が必要な項目を示してください。私が一覧を確認するまでは告知を書かないでください：[記録]。

確認済みの事実だけを使い、Facebookページ向けに約60語の障害告知を書いてください。影響を受ける決済方法、確認済みの代替手段、後ほど更新することを伝えます。原因や復旧時刻は作り出さず、技術的な専門用語を避けてください。

問題が解決した後に使う短い投稿をもう一つ作成し、確認済みの時刻を入れるためのプレースホルダーを残してください。私が提示するまで原因は書かないでください。Tarenoを使い、Facebookページ[名前]向けの下書きとして両方を保存し、IDを返してください。

Tarenoに下書き[告知のID]を許可される最も早い日時で予約するよう依頼し、依頼した時刻を知らせてください。承認待ちアクションのIDを返し、私がTarenoのダッシュボードで承認するまで投稿されないことを明記してください。

避けるべき間違い

• 原因を早まって公表すること。確認されていない仮説が誤りだった場合、新たな苦情につながる可能性があります。
• 復旧時刻を約束すること。代わりに次の更新を約束し、顧客に対してその約束を守ってください。
• 予約に必要な余裕時間を忘れること。プラットフォームが許可する日時より早く依頼できないため、速やかに確認して承認します。
• 復旧後の下書きを未完成のままにすること。未確認の内容が誤って予約されないよう、プレースホルダーを目立たせてください。