Session notes, recall sheets, feedback and approvals.

A commission almost always drifts for the same reason: nobody noted the discussion, nobody wrote down which version changes referred to, and “final” was used three times in one week. Then comes “Can you return to the previous version?” and no previous version is identifiable.

The remedy is taking notes while working, not bureaucracy. This guide builds a protocol in six pieces: session notes, recall sheets, deadlines, structured feedback, revisions and approvals, linking them to the complete delivery cycle.

Session notes

Session notes are the project’s external memory. Save them in Docs/ and record what the DAW does not: microphone and position, preamp and gain, instrument and volume/tone settings, good and bad takes, decisions and outstanding work for next time.

Short, dated notes work best. One block per session containing date, work completed, changes and outstanding tasks is worth more than a perfect document nobody maintains. In a multi-person project, these notes let someone else continue without calling you.

Track notes are a useful complement: most DAWs support per-track comments, suitable for processing recipes and recording information. For recorded tracks, include specific equipment: the guitar, pickup position and controls set halfway.

Recall sheets

Recall sheets originated for external equipment: printed outlines of each device and console to mark settings at session end and reconstruct sound months later. Digital tools turned them into screenshots, spreadsheets and PDFs stored with the session.

In an in-the-box studio, the function changed but did not disappear: the DAW saves its parameters but not microphones, preamps, pedal configuration or hardware presets. Current professional practice therefore combines three things: input notes with each take’s equipment, screenshots or photos of external gear at session close, and these documents archived inside the project folder.

The naming rule applies here too: if it is not written into the session, it does not exist for the next person opening the project.

Deadlines

Deadlines are agreed, not discovered. A useful deadline looks like this: first-delivery date, feedback-return date and closing date. Three dates with one responsible person each make the project manage itself.

Establish two patterns in advance:

• Follow-up. Without a response, wait one or two weeks and make only one further follow-up; after the second attempt, silence is an answer.
• Scope. A deadline covers delivery without covering unlimited revisions. If every change restarts it, the date loses meaning.

Protect the deadline by always working on a session copy named with purpose and date, backed up before starting. If something breaks, you lose an afternoon rather than the deadline.

Two practical calendar adjustments. First, calculate backwards from the date that actually matters—the premiere, submission or client delivery—and leave room for complete revision rounds rather than just your part; three days waiting for feedback count too. Second, agree date, time and explicit zone when crossing time zones: “Friday 18:00 CET” is unambiguous; “Friday afternoon” is not.

Finally, record deadlines where people already view the project: delivery email, tracking sheet and that week’s session notes. A deadline existing in one person’s memory is an outstanding task rather than a deadline.

Structured feedback

Structured feedback turns impressions into instructions. Four rules are enough:

1. Mark the time. Give the section’s start and end: “between 0:35 and 1:05”.
2. Name the element and change. “Vocal mids in the verse”, not “the voice”.
3. Prioritise. Three important notes are worth more than forty unordered ones; the recipient starts at the top.
4. Listen on several systems before writing. If it sounds wrong only on particular headphones, the equipment is probably at fault rather than the mix.

Add a reference with a specific time: “I want the vocal space in that song’s chorus at 1:15.” Without a time marker, a reference is an open discussion; with one, it is guidance.

Separate commonly mixed note types too: intention—“I want this bigger”—and technique—“raise the snare by 2 dB”. The first states direction; the second states today’s fix. A successful revision round needs both: intention prevents changes that satisfy the request but break the idea; technique prevents another round merely to interpret a word.

Another time-saver: request the round’s feedback in one message. Separate notes create separate rounds, and a round is not one change: it is a delivery, a listen and a response.

Revisions

Revisions are rounds applying notes and returning results. They need two agreements: how many rounds the work includes and the version from which they count.

The classic mistake is counting rounds while feedback arrives across email, messaging and calls at different times. The alternative is simple: one channel, one message per round with all notes, and each delivery identified by version and date. Round three then counts from delivery two rather than the last remembered remark.

Document implemented and rejected changes with reasons. This stops rejected notes reappearing and explains decisions understood in person but forgotten in writing.

Treat one situation separately: a note satisfying the request but damaging the whole. Lowering the vocal three decibels because one moment seems loud may flatten the rest; raising bass for headphones may overwhelm the room. Apply it, document the reason and propose an alternative in the same round rather than arguing before hearing it. A requested change heard is debated much less than one merely explained.

For important rounds, listen together: ten shared minutes with the open project and the same reference close more arguments than a long email. This validates a mix and aligns the next session’s goal before anyone changes anything.

Approvals

Approvals close the cycle: someone authorised decides a given version is valid. Obvious as it sounds, this is skipped most often, causing post-close changes and disagreements about what was approved.

Three rules:

• Identify the approver. One decision-maker, or a decision order if several are involved.
• Approve by version rather than feeling. “Approved: mix_v04_2026-10-01” is unambiguous; “approved” is not.
• Every subsequent change restarts the cycle. Changes after approval enter a new round with its own date.

For label work, approval clauses also appear in writing in the contract alongside release commitments: read them before signing rather than afterwards. The full contractual context is covered in release contracts with a record label.

The delivery cycle

Everything fits into a short cycle:

1. Agree deadline, format, round count and approver.
2. Work on a copy, adding session notes after each block.
3. Deliver an identified version with technical information the recipient needs.
4. Collect that round’s feedback in one prioritised, time-marked message.
5. Revise, apply changes and document what was and was not implemented.
6. Approve by version, back up and close.

The cycle is identical for a label track or client mix. Backing up each approved delivery is compulsory: apply the same 3-2-1 rule to the approved version, the only one worth ensuring you never lose.

Next step

After closing the cycle, prepare the delivery package: files, credentials, authorship splits and the portfolio folder supporting the next commission. This is covered in deliverables, credits, split sheets and professional delivery.