# 怎么用英文约一场会议：一轮谈定时间，而不是来回拉锯

从提出两三个具体时段、标清时区，到发确认信，把会议时间一次敲定

> 商务邮件 · 会议安排 · 时区表达 · 约 7 分钟 · 09 月 19 日

## 本篇要点

1. 约会议效率的关键不是礼貌程度，而是有没有替对方把选择题做完：给出两三个具体时段，对方只需挑一个，而不是自己想一个。
2. “你什么时候有空”看起来客气，实际把找时间的工作全推给对方，通常要多花一到两封邮件；给两三个选项同时留一句 “If neither works, let me know what does and I'll find a match” 才是安全阀。
3. 一个能用的时段必须同时说清日期、钟点、时区、时长和方式；日期用月份单词（Tuesday, May 12）避免 3/4 的歧义，正式邮件写 2:00 p.m. 而不是 2pm。
4. 时区缩写不可靠：CST 在美国是 UTC−6、在中国是 UTC+8，IST 同时指印度、爱尔兰和以色列时间。双方都在北美可用 PT/ET，跨大洲用 UTC 换算或写城市名。
5. 用 PT/ET 而不写 PST/EST，可以让夏令时自行处理；但换算 UTC 时必须查当天的偏移，太平洋时间夏令时是 UTC−7、冬天是 UTC−8，凭记忆算容易让对方早到或晚到一小时。
6. 对方选定后要发确认信，重述目的、时间（含时区）、时长、方式和参与人，主题行改成带时间的 Confirmed: …，而不是只回一句 Great, see you then。
7. 日历邀请按自己的时区发并写明时区，现代日历会按接收人本地时间显示，因此不必替每个人手动换算。
8. 改期时越早说越好，道歉一句即可，同时给出两三个新时段，避免只问 “Can we reschedule?” 又回到来回拉锯。

---

上一篇把一封英文邮件拆成七个零件，说的是整封邮件的骨架。这一篇挑一个最常见的具体场景来讲：**约一场会议**。这是“请求句”和“收尾句”被用得最狠的地方，也是新手最容易在第一封就写坏、结果来回几封还定不下来的地方。

约会议最常见的失败长这样：你写 “Can we meet sometime next week?”（下周找个时间见一下？），对方回 “Sure, when are you free?”（好啊，你哪天方便？），你又写 “Any day works for me, you pick.”，两天过去，两个人都没打开日历。几封邮件过去，会议还没定。

问题不在于英语不够好，而在于邮件没有替对方把选择题做完。这篇按四个动作讲清楚：怎么给出时段、怎么标时间、怎么补全细节、怎么发确认信。

## 一轮谈定，靠四个动作

```mermaid
flowchart LR
  A["提出两三个具体时段"] --> B["对方选一个"]
  B --> C["发确认信重述全部细节"]
  C --> D["发日历邀请"]
```

四个动作里，真正决定成败的是第一个：你给的时段够不够具体。

## 第一步：给两三个具体时段，而不是“你什么时候有空”

“你什么时候有空”看起来客气，实际上是把找时间的工作整个推给了对方：他要打开日历，避开自己的会，想出一个时间，再写一封回来。一来一回，半天到两天就没了。

换成**两三个具体时段**，收件人只需要看一眼日历，回一句 “Tuesday works”，一封就结束。常用句式：

- Does Tuesday, May 12, at 2:00 p.m. work for you?
- Would either of these work for you?
- I'm available at the following times: …

为什么是两三个，而不是一个？只给一个，对方不行就只能拒绝，你又得再来一轮；给两三个，绝大多数情况他直接挑一个。但选项也不是越多越好，列五六个反而让人无从下手。

还要留一个安全阀，兜住“都不行”的情况：

- If neither of these works, let me know what does and I'll find a match.

这句话的关键在于：**主动开口要替代方案的是你，而不是把问题扔给对方**。

## 第二步：让这个时间在任何地方都能被读对

写出 “2:00 p.m.” 只完成了一半。“具体时段”必须能回答三件事：哪一天、几点、哪个时区。

**日期用月份单词，别写数字。** 3/4 在美国是 3 月 4 日，在英国是 4 月 3 日。写成 Tuesday, May 12 就没有第二种读法。

**钟点写全。** 正式邮件里写 2:00 p.m.，不要写 2pm。中午写 noon，半夜写 midnight，避开 12:00 p.m. 这类容易争起来的写法。

**时区是最容易出事的一环。** 如果只写 “3 p.m.”，对一个在别的时区的人来说，这个信息等于零。而用缩写也不总是安全，因为同一个缩写在不同地方含义不同：

- CST 在美国是中部时间（UTC−6），在中国是北京时间（UTC+8）；
- IST 同时是印度时间（UTC+5:30）、爱尔兰时间（UTC+1）和以色列时间（UTC+2）；
- EST 严格来说只指标准时，但很多人全年都拿它当东部时间用。

两个人分处两个大洲、各自用 CST 指自己那边，就是一场灾难。所以按场合选写法：

| 场合 | 写法 | 例子 |
| --- | --- | --- |
| 双方都在北美 | 用 PT / ET / CT / MT | Thursday at 10:00 a.m. ET |
| 跨大洲 | UTC 换算 | Tuesday at 2:00 p.m. PT (21:00 UTC) |
| 一方是重心 | 城市名，让日历换算 | Wednesday at 9:00 a.m. in New York |

北美那组缩写可以用，是因为含义固定。而且注意一个实用细节：写 **PT / ET** 而不写 PST / EST，反而省事——PT 会随夏令时自动变成 UTC−7 或 UTC−8，你不用去纠结当天是哪个。

但反过来，算 UTC 的时候必须查。太平洋时间在夏令时是 UTC−7，冬天是 UTC−8；上表里 “2:00 p.m. PT (21:00 UTC)” 成立，是因为五月属于夏令时。如果你凭记忆把五月的会议算成 UTC−8，对方就会早到一小时。

## 第三步：第一次就把时长、方式、目的说全

只给对方时间还不够——他不知道该往日历里切多长、在哪儿见、值不值得为它空出半小时。以下四项尽量在第一封里齐：

1. **为什么**：I'd like to walk through the Q2 proposal before it goes to the client.（别写 to catch up 或 touch base，那等于没说。）
2. **多长**：a 30-minute call / a quick 15 minutes。
3. **哪天几点、哪个时区**。
4. **怎么开**：video call、phone 还是 in person；如果不止你们两个人，顺便点名还有谁。

把这些拼起来，第一封大概长这样：

> Subject: 30 min on the Q2 proposal — Tue or Thu?
>
> Hi Sarah,
>
> I'd like to set up a 30-minute call to walk through the Q2 proposal before it goes to the client.
>
> Would either of these work for you?
>
> - Tuesday, May 12, 2:00–2:30 p.m. PT (21:00 UTC)
> - Thursday, May 14, 10:00–10:30 a.m. PT (17:00 UTC)
>
> If neither works, let me know what does and I'll find a match.
>
> Best regards,

主题行带上了时长和两个候选日，收件人在收件箱里就知道这是件要挑时间的事；正文里目的、时长、时区、选项、兜底方案全齐，对方只要回一个词。

## 第四步：确认信，把共识变成书面依据

对方回 “Tuesday works”。这时候**不要**只回一句 “Great, see you then.”。一句话确认没有任何记录，而你的“周二”、他的“周二”、你们各自脑子里的那个时区，很可能不是同一个。

正确做法是发一封确认信，把全部关键项重述一遍，让对方一眼核对：

> Subject: Confirmed: Q2 proposal call, Tue May 12, 2:00 p.m. PT
>
> Hi Sarah,
>
> Great — Tuesday, May 12 works on my side too. Quick recap:
>
> - Purpose: review the Q2 proposal
> - Time: Tuesday, May 12, 2:00–2:30 p.m. PT (21:00 UTC)
> - Where: video call, link below
> - Who: you, me, and Daniel from finance
>
> I'll send the draft proposal tomorrow so you can skim it beforehand.
>
> Best regards,

三点值得注意。主题行改成了带时间的 “Confirmed: …”，以后搜索得到。正文用项目符号把目的、时间、方式、参与人列齐，五到八行就够。有要提前看的材料，就在这封里附上——确认信是给你最后一次机会把话说全的。

还有一个能省掉大量麻烦的做法：**日历邀请按你自己的时区发，并把时区写清**。现代日历工具会把会议记在组织者所在时区，显示时再转成收件人的本地时间。所以你在邮件里标一次时区就够了，不必替每个人手动算一遍。

## 万一还是得改期

改期的做法和第一次约几乎一样，只是开头多一句道歉：

- 越早说越好，别拖到会议前一小时。
- 道歉一句就够，不用长篇解释理由。
- 直接给两三个新时段。只写 “Can we reschedule?” 就又回到了来回拉锯。
- 收尾谢一句：Thanks for your flexibility.

> I'm sorry for the short notice, but an unexpected review has come up on Tuesday. Could we move our call to Thursday at 10:00 a.m. or Friday at 2:00 p.m. PT instead? Thanks for your flexibility.

## 自己试一次

把下面这句改写成能一轮谈定的请求句：*Can we have a meeting to discuss the new pricing next week?*

<details><summary>参考答案</summary>

I'd like to set up a 30-minute call to discuss the new pricing. Would either of these work for you?

- Tuesday, May 12, 3:00–3:30 p.m. PT (22:00 UTC)
- Wednesday, May 13, 9:00–9:30 a.m. PT (16:00 UTC)

If neither works, let me know what does and I'll find a match.

改动有四处：补上了时长（30-minute）、目的（the new pricing）、两个带日期和时区的具体时段，以及都不行时的兜底方案。原来的 “next week” 被换成了具体日期。这两个 UTC 换算同样按夏令时（UTC−7）算。

</details>

## 记住这一条

约会议考的不是礼貌用语的堆叠，而是**把对方的选择题做完**：两三个具体时段，每个都带日期、钟点、时区和时长，再留一句兜底；对方挑定之后，用一封确认信把所有细节写成白纸黑字。做到这四点，会议通常一轮就定下来，你们也省下好几封来回的邮件。

## 术语表

- 具体时段（specific time slots）：写出日期、钟点、时区的完整时间，而不是“下周找一天”这类模糊说法。
- 兜底句（fallback line）：在给出两三个时段后补一句“都不行请告诉我你能行的”，避免对方只能说“不行”而多出一轮邮件。
- 时区缩写歧义：CST、IST、EST 这类字母在不同地区指不同时间，跨地区使用时不可靠。
- UTC 偏移：用 UTC 加或减若干小时表示时间，例如东亚是 UTC+8，作用是在跨大洲时给所有人一个共同的参照。
- 夏令时（DST）：部分地区夏天把钟拨快一小时，同一个城市因此会有两个不同的 UTC 偏移，换算前要确认会议当天属于哪一种。
- 确认信（confirmation email）：对方选定时间后发出的短信，把目的、时间、时长、方式和参与人重述一遍，作为双方共同的书面依据。

## 来源

1. [How to Schedule a Meeting by Email — 约会议邮件要一次答清 Why／Who／How long／When／How，以及具体时段模板](https://www.usecarly.com/blog/how-to-schedule-meeting-by-email/)
2. [Appointment Request Emails in English — 预约请求的必备部分、给两三个时段比开放式提问更快得到回复](https://5minuteenglish.com/writing-appointment-requests-and-confirmations-in-english/)
3. [Smart Scheduling Emails: Propose, Confirm, Reschedule — 提出、确认、改期三类邮件的示例与常用句式](https://www.broadlearners.com/t/smart-scheduling-emails-propose-confirm-reschedule/3712)
4. [Time zone abbreviations are ambiguous — CST、EST、IST 等缩写的实际歧义，以及城市名与 UTC 锚点写法](https://timezonemeet.app/blog/time-zone-abbreviations-are-ambiguous.html)
5. [Scheduling meetings across time zones — 跨时区排会的三种可靠写法、夏令时与换算核查](https://timezonemeet.app/blog/scheduling-meetings-across-time-zones.html)
6. [The Editor's Manual: Time Zones — 时区缩写与写法规范，UTC 偏移在国际场合的优先地位](https://editorsmanual.com/articles/time-zones/)
7. [Google developer documentation style guide: Dates and times — 日期时间写法与是否需要标时区的判断标准](https://developers.google.com/style/dates-times)

---

原文：https://pangzhengboyin.com/articles/scheduling-a-meeting-in-english-email-c4fcbec9

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com