Writing a SMART task: an example after a call

SMART clarifies the result, but feasibility still needs checking

SMART is a way to check a goal or task. The common version looks for specificity, measurability, achievability, relevance, and a time limit. Answer the practical questions: what should change, how will you see it, and under what conditions can the work be done?

Verbal instructions often leave expectations unstated. “Fix the report by Friday” does not tell the assignee what to check or who will accept it. A transcript recovers the wording, but it cannot fill in the scope on the requester’s behalf.

Five checks before handing off a task

1. S — specify the deliverable

   Describe the document, action, or change needed. “Work on inquiries” is an activity. “List recurring questions and their sources” specifies a deliverable.

2. M — define how to check it

   A large growth percentage is only one kind of measure. For a document, check required fields, coverage of selected sources, and completion of all mandatory items.

3. A — verify the conditions for delivery

   Do you have access to sources, the necessary skills and time, and a way to resolve disputed points? State unmet dependencies explicitly before calling a task achievable.

4. R — explain why it matters

   Connect the output to a real need. If the questions will update a help page, the assignee will understand why clear wording and verified answers matter.

5. T — set a deadline and approval point

   Specify the date and, if necessary, the time and time zone. Give the draft and final acceptance separate deadlines if someone else needs to review it.

From a verbal instruction to a task card

Fictional example. The instruction leaves the scope, date, and requirements for answers open. Ask which conversations to use, who approves the answers, and what document support needs before treating those details as agreed.

Final task card: “Prepare a table of questions from the ten agreed recordings by Thursday at 16:00 Moscow time. Include context and source for each question. Flag draft answers as unverified until the support lead approves them. The aim is to lay the groundwork for the help page.”

The example does not promise 30% fewer inquiries because that effect has not been measured. Ten is an illustrative scope. If access is late, the assignee raises the dependency and the deadline is explicitly revised.

Distinguish the deliverable from the business outcome

A table of answers is a deliverable the assignee can show. A lighter support workload is a broader outcome affected by answer quality, page placement, and user behavior. If it matters, test it after launch. Avoid promising it in the task.

“Do it 100% well” says nothing about the criteria. List observable checks: links open, disputed answers are marked, and selected material is covered. For creative or research work, define a reviewable output and scope without assuming the conclusion.

Ask the assignee to explain the task in their own words. If they describe a different deliverable, fix the card before work starts. The call can show where the mismatch arose, but the people involved still need to agree on the clarification.

Task card after the conversation

Deliverable:
For whom and why:
Sources to use:
In scope:
Out of scope:
Acceptance criteria:
Assignee:
Approver:
Access and dependencies:
Draft deadline:
Approval deadline:
What to do if blocked:
Source and timecode:
Clarifications confirmed after the conversation:

• The deliverable can be shown or checked.
• The task does not promise an outcome beyond the assignee’s control.
• Scope and dependencies are explicit.
• The deadline does not replace quality criteria.