公开道歉声明提示词

何时使用

当你需要撰写面向客户的道歉声明，并且希望获得一个具体的起步方案而非泛泛的建议时，请使用此提示词。在实际场景中使用输出结果之前，请务必将虚构细节替换为你自己核实确认的事实。

提示词内容

## 角色
担任一名具有问责意识的公共沟通编辑。运用专业判断，同时确保你的推理逻辑能让非专业人士轻松理解。

## 背景
Elm Table 是一家虚构的餐饮外送公司，由于内部路线规划错误，导致 74 笔订单延误了一天送达。客户在承诺的送达时间窗口过后才收到通知。目前未收到任何食品安全事故报告。配送费的退款申请已获批准，但具体的退款到账时间尚未确定。

## 目标
起草一份道歉声明，明确承担失误责任并说明已批准的补救措施，同时不夸大目前已知的事实。

## 受众
主要使用者为服务型企业主。请确保输出成果可直接应用于他们的日常工作，提供足以支持决策的必要解释，但避免冗余的背景说教。

## 需求
提供一封 250–350 词的客户邮件、一份 70 词的公开声明，以及一份内部事实核对清单。同时承认配送延误和沟通不及时的失误。明确说明退款时间表将在确认后另行通知。将即时补救措施与需要审批的流程改进方案区分开来。列出发送前需要签核的操作事实，并在不虚构具体姓名的情况下，为下一次客户跟进指定具体的负责岗位。

## 约束条件
切勿推卸责任给供应商，不得宣称“未造成任何不良影响”，不得泄露客户信息，也不得承诺“此类事件绝不会再次发生”。切勿自行添加未经批准的补偿额度或退款日期。仅基于给定场景和明确提供的材料开展工作。注明所有前提假设，并将拟采取的行动与已确认的事实明确区分。

## 语气与风格
直接、周全且具体。倾向于使用通俗易懂的语言、具体的例子和简短的段落。根据目标读者调整用词，避免使用行话或空洞的说教式辞令。

## 输出格式
优先呈现所需的成果内容，仅在有助于提升可用性时使用描述性标题和表格。将辅助说明与用于发布或直接使用的文案严格分开。最后附上一份简短的待决事项或核实步骤清单。

## 避免事项
避免空话套话、毫无根据的断言，以及为了让结果看似完整而凭空捏造的细节。切勿让华丽的措辞掩盖信息的缺失或需求的冲突。

## 成功标准
客户能够清楚理解发生了什么、公司承担哪些责任，以及哪些信息仍在跟进中。在呈现结果之前，先对照上述约束条件进行检查，并纠正发现的任何不一致之处。

## 澄清问题
仅在缺失信息会实质性改变输出结果时，最多提出三个针对性问题。否则，请直接基于虚构场景继续推进，简要陈述任何必要的前提假设，并指明真实用户在采用该结果前应核实的事项。

为什么有效

• 具体的场景为模型提供了确凿的事实和边界，无需由模型凭空编造简报。
• 需求部分明确指出了具体的交付成果以及此项任务的关键边缘情况。
• 约束条件有效防止了未经证实的说法和未获批准的承诺混入结果中。
• 成功标准将审核过程转变为切实的核查：客户能否明白发生了什么、公司承担了什么责任，以及哪些信息尚待跟进。

定制为你自己的版本

使用 PromptDeck 构建专属定制版本，只需将虚构场景替换为你自己的背景、受众和约束条件即可。请保留核实步骤，以确保最终成果真实反映你所掌握的实际情况。