Homework Is Not Progress Until a Mentor Can Return It

A mentoring assignment is not complete because it has an owner and a due date. It becomes operationally useful only when the participant deliberately presents evidence for review and the mentor makes a visible decision about it.

This distinction is easy to lose in consulting programs. A recommendation is captured in call notes. A participant replies in chat, sends an unstructured link, or says they have “looked into it.” A reminder is sent before the next session. Then the session opens with ten minutes of reconstruction: What was agreed? Was anything actually done? Is the material ready to review? What changed?

Reminders can surface an obligation. They cannot establish that work is ready for professional judgment. For program owners, mentors and cohort managers, the better unit of process is a submit-and-return loop: an agreed assignment moves through preparation, explicit submission, human review and either acceptance, revision or a documented exception.

The missing boundary is submission

Many task workflows flatten three different facts into one status: someone is working, someone has sent something, and someone qualified to assess it has accepted the result. Those facts should remain separate. Otherwise a completed checkbox can conceal an unread document, an inadequate answer or a participant who needs help removing a genuine blocker.

Educational products already make this distinction explicit. Google Classroom changes work to “Turned in” only after an explicit submission action, and supports unsubmit, edit and resubmit behaviour. Microsoft Teams for Education distinguishes viewed, turned-in and returned work; a reviewer can return an assignment specifically for revision and provide feedback. These are process precedents, not a prescription to use either platform in a mentoring program.

The same principle can be implemented in a general work-management tool. Asana Approval tasks, for example, provide approve, request changes and reject outcomes, with instructions, attachments, an approver and a due date; rules can route an item when it reaches an awaiting-approval state. The relevant availability depends on the applicable Asana plan. The design principle is more important than the product: no automatic transition should treat an unreviewed submission as accepted progress.

Design one record around the assignment, not the conversation

Start during the session, while the recommendation is still clear. The mentor and participant should explicitly agree one concrete assignment, the evidence expected, and a deadline. “Improve your positioning” is a coaching theme, not an operational assignment. “Submit a revised one-page offer with the target segment and three approved claims marked” is reviewable evidence.

Create one linked work item from that agreement. It should identify the participant, mentor, assignment, evidence requirement, due date and current state. A practical state model might include Agreed, In progress, Blocked, Submitted, Under review, Changes requested, Accepted and Cancelled. The precise labels may vary. What matters is that Submitted and Accepted cannot mean the same thing.

Chat can still be useful for notifications and short clarifications. It should not be the source of truth for whether evidence was submitted, what feedback was given, or which exception was approved. Keeping those decisions on the linked work item lets the next session begin with a stable record rather than a search through messages.

A six-step loop with a human decision at its centre

1. Agree the assignment in the session. Record the expected evidence and due date only after the participant confirms the commitment.
2. Create the linked item automatically or from a structured template. Assign the participant and mentor, but do not let automation invent a recommendation or create a commitment without that agreement.
3. Send reminders only while the item is In progress or Blocked. A blocked state should invite a concrete explanation or a request for help, not silently move the deadline.
4. Require an explicit submission action. The participant attaches or links the evidence and moves the item to Submitted; this creates the review queue.
5. Route Submitted items to the mentor. The mentor makes the substantive decision: accept, request changes or cancel, and records focused feedback or the reason for an exception.
6. Prepare the next-session brief from accepted work, items awaiting review, change requests and documented exceptions. The brief is preparation, not an automated evaluation of the participant.

Automation has a narrow but valuable role here: create records, carry agreed fields forward, send state-aware reminders, preserve evidence, route submitted work and assemble the brief. The mentor remains responsible for the recommendation, the interpretation of submitted material and the decision to accept, return or cancel the work. The participant remains responsible for deciding whether to commit and when to submit.

Measure flow quality, not imagined outcomes

This is a proposed workflow design, not an AES deployment or an achieved client result. Its first measures should test whether the loop is functioning, rather than claim that it improves learning, retention or revenue.

• Median time from session to assignment creation: does a clear commitment enter the system while the conversation is still fresh?
• Submitted-on-time rate: submitted items divided by items due in the measurement period.
• Median time from Submitted to reviewed: is the mentor’s review queue becoming a bottleneck?
• Share of next sessions beginning with reviewed evidence or a documented exception: does the process reduce status reconstruction?

Define the observation period, population, denominator and treatment of cancelled, rescheduled and blocked items before reporting a trend. If timestamps are automated in Airtable or a comparable record system, account for the fact that Airtable documents its status-timestamp automation as prospective: existing records need deliberate backfill or exclusion from a baseline. A clean-looking dashboard built from mixed timestamp logic is not a baseline.

Do not operationalise what should remain private

Use this pattern where homework produces reviewable evidence: a draft proposal, a process map, a calculation, a client-ready document or a completed operational action. Do not force private reflection, sensitive counselling notes, personal disclosures or unrestricted recordings into the homework record simply because the workflow has a field for attachments.

There are real implementation costs: workflow configuration, permissions, migration choices for existing assignments and disciplined use of statuses. A queue is also honest about capacity. If submissions accumulate in Under review, the answer may be a changed mentor workload or service design—not another reminder to participants.

The practical test is simple. Map one journey from a mentoring session to a review decision. Identify the moment work becomes deliberately submitted, the person who can return it, and the record that will explain the next conversation. If none of those is explicit, the program is tracking activity rather than reviewed progress.

Sources

• Asana Help: Giving feedback and approvals — https://help.asana.com/s/article/giving-feedback-and-approvals?language=en_US
• Microsoft Support: Assignments and grades in your class team — https://support.microsoft.com/en-us/education/assignments/assignments-and-grades-in-your-class-team
• Google Classroom Help: Turn in an assignment — https://support.google.com/edu/classroom/answer/6020285?hl=en-Link
• Airtable Support: Use automations to timestamp status updates — https://support.airtable.com/articles/9267771468-use-automations-to-timestamp-status-updates