サービスパッケージのドラフトを慎重に作成する

実際に提供する仕事から始める

サービス、通常の期間、成果物、チームの要件、クライアントの成果について自分の言葉で説明してください。アシスタントは構造を提案することはできますが、実際のコストを計算したり、クライアントが必要とする許可を決定したりすることはできません。

同意は、リクエストで使用されるコンテキストに対して明示的に行われます。下書きをより豊かなものにするためだけに、クライアントのプライベートな資料や無関係な個人情報を含めないでください。

• 実際のクラフトと結果に名前を付けます。
• 期間、成果物、チームのニーズをリストします。
• このドラフトに必要なコンテキストのみに同意してください。

商業的な詳細を検証する

提案された価格、通貨、経費、交通費、時間外労働、改訂、ライセンス、および除外を確認してください。果たせない約束はすべて削除してください。パッケージは質問の出発点です。可用性と最終的な範囲については、依然として両方の参加者の同意が必要です。提案を適用すると、レビュー用の下書きが保存され、リクエストは受け入れられません。

TFP または別の取引所については、各人が何に貢献しているのか、どの使用決定が未解決なのかを説明してください。

真実のバージョンのみを適用する

公開プロフィールで下書きを確認し、範囲が理解しやすいまで編集します。提案を適用しても、プロジェクトが受け入れられたり、契約が作成されたりするわけではありません。実際の条件は、プライベートブリーフ、リクエスト、および正確な契約バージョンに属します。

アシスタントがサポートできない主張を提示した場合は、それを破棄して、より単純な主張を作成してください。出版の最終段階では人間の判断が残ります。