Colay / ガイド

変更の制御を失わずにナレッジ ベースをバッチで更新します

製品の変更が多くの記事やサポート スクリプトに影響を与える場合、主な仕事は更新を調整することです。 Colay は、書き換えアプローチの比較と、選択したテキスト ブロックの下書きに役立ちます。変更登録、共有ファクトシート、レビューキューにより、これらのドラフトをバッチ全体で使用できるようになります。これは管理された編集ワークフローであり、バックグラウンドでナレッジ ベースを更新する自動接続ではありません。

テキストを生成する前に影響を受けるコンテンツをインベントリする

製品の変更から始めて、既存のコンテンツで古い用語、ルール、または手順を検索します。記事の識別子、サポート マクロ、オンボーディング メッセージ、およびそれについて言及している可能性のある内部指示を記録します。類似したタイトルが同一の内容を意味すると考えたり、モデルが古い文言が出現するすべての場所を知っていると考えたりしないでください。

古い動作、新しい動作、発効日、例外、正確な用語を記載した承認済み変更シートを 1 つ作成します。未解決の事実に対して所有者を割り当てます。事実の更新とオプションのスタイルのクリーンアップを分離することで、見栄えの良い文章によってポリシーの変更が隠蔽されることがなくなります。手順に関するテキストについては、Google のガイダンスでは、明確なアクション ステップと明示的なコンテキストが推奨されています。バッチ全体に同じ基準を適用します。

各項目を公開まで追跡する管理表を使う

架空のサービスで、エクスポート操作の場所が変わるとします。承認された新しい経路は Reports → Export で、権限と出力形式は変わりません。更新対象には操作ガイド、導入チェックリスト、サポート回答があります。これは Colay の画面を説明する例ではありません。

項目にはさまざまな編集が必要です。完全な手順には新しいスクリーンショットが必要な場合があり、チェックリストにはラベルを 1 つ変更する必要があり、サポート スクリプトには修正されたパスのみが必要な場合があります。すべての項目に対して 8 回の完全な書き換えを生成すると、必ずしも更新を改善することなくレビュー作業が発生することになります。

架空のインターフェース変更のバッチ登録の例
アイテム必要な変更証拠を確認する状態
KB-12 エクスポート ガイドパスとスクリーンショットを更新します指定されたロールを使用してエクスポートを実行するレビュー待ちのドラフト
ON-4 オンボーディング チェックリスト古いコントロールの場所を置き換えますリンクされたガイドと表示されるラベルを確認してくださいオーナーレビューの準備が完了しました
SUP-7 保存された応答指示を 1 つ修正しますサンプルの質問に対して回答をテストする開始されていません

代表的な小さなサンプルでキャリブレーションする

キャリブレーション中に役立つ 8 つの書き換え方法: 簡潔な手順、初心者向けの説明、トラブルシューティング、FAQ、サポートへの返信、内部チェックリスト、アクセシビリティに重点を置いたわかりやすい言葉、短い概要。更新対象に実際に必要な形式を選択します。有用な出力は、各ページの 8 つの競合するバージョンではなく、一貫した編集ルールです。

  1. 単純な記事を 1 つ、例外を含む記事を 1 つ、サポート スクリプトを 1 つ選択します。残りの対象一覧を処理する前に、これらの下書きを作成してください。
  2. 対応可能な Colay エージェントに同じ変更シートを渡し、別の編集方法を依頼します。変更されていないルールがすべて保持されているかどうかを比較します。
  3. 編集パターンと用語リストを承認します。受け入れられた変更と拒否された変更の例をバッチの概要の横に保管してください。
  4. 各アイテム識別子とそのソース バージョンを保持しながら、管理可能なコンテンツ グループを手動で処理します。新しい矛盾が現れたらバッチを停止します。

追跡可能なバッチアイテムのプロンプト

この使用が許可されているマテリアルのみを提供し、不必要な顧客の詳細は省略してください。権限のある登録簿を既存のドキュメントまたはコンテンツ システムに保存します。 Colay が生成した回答自体は、アイテムの公開状態を更新しません。

この承認された変更シートを使用して、コンテンツ アイテム [ID とソース バージョン] を更新します: [古い動作、新しい動作、発効日、例外]。既存のテキスト: [テキスト]。承認された用語と編集パターン: [ルール]。改訂されたテキスト、理由を含む変更された文章のリスト、保存した変更されていないルール、および公開をブロックする質問を返します。影響を受けるコンテンツのみを変更します。概要で明示的に変更しない限り、リンクと識別子は保持してください。新しい UI ラベル、権限、日付、製品の動作を考え出さないでください。この項目が変更シートと競合する場合は、推測で解決するのではなく、競合にフラグを立ててください。

確認済みの単位で公開し、元に戻せるようにする

公開する前に、変更された各指示、例外、リンクを、承認されたソースおよび実際の製品と照らし合わせて確認してください。編集箇所を中心に完全な文書を確認してください。修正された段落は、変更されていない導入部分と依然として競合する可能性があります。承認者を記録し、以前のコンテンツ バージョンを保持します。

既存のツールを使用して公開し、ライブ記事とそれにリンクする保存された応答を確認します。このチェックを行った後でのみ項目に完了のマークを付けます。プロセスを評価したい場合は、編集の経過時間と公開後に見つかった修正を追跡します。バッチ ワークフローにより、繰り返しのブリーフィングを減らすことができますが、結果は内容とレビューの取り組みによって異なります。 作業時間が必ず 1 週間短くなることを約束するものではありません。

質問と回答

ナレッジベース全体をアップロードして自動的に更新できますか?

この記事は Colay を使う手動の管理された下書き作成を説明しています。ナレッジベースへの自動接続、一括公開、バックグラウンド同期を提供するという主張ではありません。

バッチの大きさはどれくらいにすればよいですか?

レビュー担当者が影響を受けるすべての項目を変更シートと比較できる程度に小さいグループを使用します。ルールまたはコンテンツ形式が異なる場合は、サイズを小さくします。

2 つのソース記事が互いに矛盾している場合はどうなりますか?

該当項目の更新を止め、どの規則が正しいかをコンテンツや製品の責任者に確認します。滑らかな文章で矛盾が隠れないよう、管理表に残します。

出典と方法

  1. Google: writing procedures

    アクションのステップとコンテキストに関する主要な書き方のガイダンス。バッチ登録とリリースのワークフローは編集者独自の推奨事項です。

次の質問を Colay に送ってください。

モデルを選択するか、Autoを使用するか、Consensusを使用して複数の視点を組み合わせます。

アップデートを計画する