Worked case: bad to better email

Nadia manages a website migration. On Monday, she asked the analytics team to validate tracking by Thursday. It is now Wednesday afternoon. The migration review is Friday at 10 a.m., and the review packet must be complete by Thursday at 3 p.m. Nadia has not received validation results.

The analytics lead, Leon, previously said that one test depends on access from the infrastructure team. Nadia does not know whether access arrived. She needs Leon to send completed results by Thursday at noon or identify the blocked tests and expected resolution. Nadia has authority to move the packet deadline, but not the Friday review. She writes this rushed draft:

Subject: URGENT!!!

Leon,

I still haven’t gotten anything from your team and this is putting the whole launch at risk. As I said before, analytics was supposed to be done already. Please send the final report ASAP. If you can’t get it together, I’ll have to tell leadership that analytics caused us to miss the deadline.

Thanks in advance.

The message is short, but it is not effective.

Ask AI to diagnose the draft without changing it:

Analyze this email for goal clarity, audience context, factual support, tone, actionability, and unsupported claims. Quote each problematic phrase. Do not rewrite. Separate issues visible in the text from questions that require sender input.

A good diagnosis should surface several problems.

The goal is incomplete. “Send the final report ASAP” gives neither an exact deadline nor an alternative if some tests remain blocked.

The opening assigns blame. “I still haven’t gotten anything” and “your team” frame the issue as failure before Nadia knows whether infrastructure access is the blocker.

The impact is overstated. Nadia knows the review packet is at risk; she does not know that the “whole launch” is at risk.

The status is misrepresented. “Was supposed to be done already” conflicts with the stated Thursday validation date. Wednesday is not already late.

The threat is unsupported and counterproductive. Nadia has neither evidence nor a need to declare that analytics caused a missed deadline.

The tone is inconsistent. “Thanks in advance” does not repair an accusatory message, and “URGENT!!!” supplies emotion instead of usable timing.

Diagnosis prevents a cosmetic rewrite that preserves the same faulty assumptions in smoother language.

Nadia writes a factual brief:

• Goal: obtain enough status to complete the review packet.
• Audience: Leon, a peer who knows the migration and owns analytics validation.
• Known facts: validation was requested by Thursday; packet is due Thursday at 3 p.m.; Friday review is fixed at 10 a.m.; one test may depend on infrastructure access.
• Requested action: send completed results by Thursday at noon, or list blocked tests, blocker owners, and expected resolution.
• Tone: direct, neutral, collaborative; no blame.
• Boundary: do not state that analytics is late, caused a delay, or can guarantee completion.
• Format: specific subject, under 140 words, request visible in the opening.

This brief reveals an important correction: the original email accused Leon of missing a deadline that had not passed.

Nadia prompts:

Rewrite using only the brief below. Put the request and deadline in the first paragraph. Explain why noon is needed. Mention the possible infrastructure dependency as a question, not a fact. Keep the message under 140 words. Do not assign blame, claim the launch is at risk, or promise that the packet deadline can move. After the draft, list any assumptions.

The proposed result:

Subject: Analytics validation status needed by Thursday noon

Hi Leon,

Could you send the completed analytics validation results by Thursday at noon? I need to add them to the migration review packet before its 3 p.m. deadline.

If any tests will still be open, please list the blocked tests, the current blocker owner, and the expected resolution time. Is infrastructure access still affecting one of the tests?

The review remains scheduled for Friday at 10 a.m. Let me know this afternoon if the noon handoff is not workable so we can agree on what the packet should show.

Thanks, Nadia

This is better because the request, reason, fallback, and timing are explicit. It treats the dependency as uncertain and gives Leon a path to report partial completion.

Nadia compares each claim with the brief:

• Thursday noon: chosen by Nadia and within her planning authority.
• Packet due at 3 p.m.: confirmed.
• Friday review at 10 a.m.: confirmed and within the known schedule.
• Infrastructure access: presented as a question.
• “This afternoon”: vague. Nadia should replace it with an exact time if it matters.
• “Agree on what the packet should show”: collaborative, but Nadia must ensure Leon shares that decision authority.

She changes “this afternoon” to “by 4 p.m. today” and decides the collaborative wording is accurate because both teams contribute to the packet.

Verification catches a common issue: the draft can be substantially improved and still contain one avoidable ambiguity.

If Nadia’s relationship with Leon is informal and the issue is not yet escalating, she may prefer:

Subject: Thursday noon: analytics results or blocker status

Hi Leon,

For the migration packet, could you send completed analytics results by noon Thursday? If any tests are still open, a list of the tests, blocker owners, and expected resolution times will work for the packet.

Is the infrastructure access dependency still open? The packet is due at 3 p.m. Thursday, ahead of Friday’s 10 a.m. review. Please flag by 4 p.m. today if the noon handoff looks unlikely.

Thanks, Nadia

This variant is shorter and avoids “so we can agree,” but it preserves every operational fact. Neither variant is universally better. The right choice depends on relationship and process.

AI helped diagnose tone, organize the request, generate a variant, and expose assumptions. Nadia supplied the truth, authority, deadline, and judgment. She also corrected the original premise before generation.

If she had simply prompted “make this professional,” the output might have retained the false claim that analytics was late. It might also have softened the threat without removing it. The worked method is:

1. separate known facts from conclusions;
2. state goal, audience, and action;
3. identify unsupported claims;
4. define preservation and prohibition rules;
5. generate a bounded draft;
6. verify every operational statement;
7. choose the version that fits the real relationship.