To confirm verbal instructions by email, summarize the requested outcome, the next action, its owner, and the timing. Mark assumptions and pending decisions explicitly, and ask the appropriate person to correct or approve the relevant details. A summary records your understanding; it does not automatically prove agreement.
A conversation can be useful and still leave people with different expectations. One person hears an idea, another hears an instruction, and a third assumes a deadline has already been approved. A short confirmation can expose those differences before work moves further.
A confirmation email template
Use this original template for an ordinary internal task. Remove fields that add no value.
Subject: Confirming next steps for [task]
Following our conversation on [date], my understanding is that the intended outcome is [result].
- Next action: [specific action]
- Owner: [person or team]
- Timing: [agreed date, or proposed date clearly labeled]
- Required input: [dependency and who supplies it]
- Completion check: [how the result will be verified]
- Still to confirm: [open question or approval]
Please correct anything I have misunderstood. For [decision requiring authorization], please confirm before [dependent action]. I will [next action already within my authority] and update [approved record].
Do not write “as agreed” when you are presenting a new proposal. Do not turn silence into approval by adding “I will assume you agree if you do not reply.” Follow the actual approval process for the work.
What should you include?
| Field | Useful wording | Avoid |
|---|---|---|
| Outcome | “Prepare the approved product images for the sales team” | “Handle the images” |
| Action | “Add the final file links to the shared index” | “Make sure everyone is aligned” |
| Owner | “The designated designer prepares the files” | Assigning someone who was not consulted |
| Date | “Proposed completion: Thursday, subject to the brief arriving Tuesday” | Inventing a date and presenting it as agreed |
| Status | “Approval pending” | “Confirmed” when only receipt is known |
| Verification | “The requester checks the file set against the brief” | “Done” without a defined output |
The aim is enough detail to move the task forward. A routine request should not become a long legalistic memo.
Receipt, understanding, and approval are different
“Received” tells you a message arrived. “I understand the request” indicates comprehension. “Approved” should come from someone authorized to make that decision through the appropriate process.
Keep those states separate, especially when a change affects cost, access, a client commitment, or a production environment. An email from a helpful colleague may clarify the task without authorizing the change.
For consequential choices, use the project decision log. The email communicates the next step; the decision log preserves the choice and its context. Neither should quietly grant authority the sender does not have.
A first-hand example: moving image requests beyond chat history
In a team of roughly ten people, our boss wanted completed product images posted in a group chat so colleagues could retrieve them. Based on my previous project experience, I expected requests, file locations, and versions to become difficult to trace.
I proposed one shared online document as the lookup entry point and a common server for the actual files. Requests and completion notices still appeared in the designated group. The designer recorded who requested the work, when it was completed, how many images were produced, and where the files were stored. The method continued to be used.
I am not claiming that I sent the sample email above in that situation, or that the workflow produced a measured productivity increase. The lesson from my experience is that a verbal idea needs a clear handoff: what happens, who does it, where the result lives, and how others learn it is ready.
See the single source of truth guide for the ongoing shared-information structure. A confirmation message should point to that structure, not create a rival version in a private inbox.
How to keep the tone cooperative
State the practical purpose: “I want to make sure the team starts with the same brief.” That is usually more useful than opening with “for the record” or a warning about future blame.
You can be direct without being accusatory:
“I have the requested output and owner, but the delivery date is still open. Could you confirm the priority against the release review?”
If you disagree with a detail, mark the difference rather than disguising it as confirmation:
“I understood that the first step was a draft review. Your message suggests final publication. Could we confirm which one is authorized before proceeding?”
These are illustrative scripts, not quotations from an actual conversation. Tone cannot guarantee that every recipient will welcome clarification. Keep the audience appropriate and do not copy senior people merely to pressure someone into replying.
What if your manager does not reply?
First separate a nonessential correction from a decision that blocks safe progress. You may be able to continue a task already authorized while keeping an unresolved assumption visible. If required approval is missing, do not invent it.
Send a short follow-up identifying the exact decision and its impact. If the blocker exceeds your authority, follow the issue escalation process. Urgent safety or security concerns belong in the designated incident channel, not an ordinary email queue.
For routine progress, the project status update template can show what is complete, what remains pending, and who owns the next step.
If the instructions change later
Record the new requirement and confirm which earlier instruction it replaces. Explain the effect on timing, scope, or dependencies. A useful update says “the revised brief replaces version A,” not simply “the plan changed.”
Do not describe every change as proof that someone is unreliable. New information may justify a different decision. The record should help people carry out the current instruction while retaining the reason for a meaningful change.
Common mistakes
- Writing a proposal as though it were an agreement.
- Treating a read receipt or silence as authorization.
- Copying confidential details to people who do not need them.
- Assigning work to an absent colleague without checking responsibility.
- Keeping a private email record inconsistent with the shared project record.
- Recording every minor exchange instead of the commitments that affect work.
Frequently asked questions
Do I need to confirm every verbal request?
No. Use judgment based on ambiguity, risk, handoffs, and the cost of misunderstanding. Simple low-risk tasks may need only a brief acknowledgment.
Can a chat message replace email?
Yes, if it is an approved, findable channel for that task. The important points are clarity, ownership, and confirmation, not the label of the tool.
Is a confirmation email legally binding?
This guide makes no legal claim. Legal effects depend on the facts, jurisdiction, and relevant agreements. Follow the formal process for contracts, employment changes, payments, and other consequential commitments.
What if the original instruction itself is unclear?
Ask a direct question before describing it as confirmed. A short list of what is known and what remains open is more accurate than filling the gaps yourself.
Sources and editorial limits
Atlassian’s action-item guide provides further reading on specific next steps and ownership. The British Council’s email instruction lesson is a language resource, not a workplace approval standard.
The template and scripts above are this site’s practical synthesis informed by the author’s project experience. They are not legal advice or a guarantee that a workplace dispute will be resolved.