Start with the decision that needs proof
An approval receipt begins with the decision, not with the message that carried it. Name the exact choice, the options that were offered, and the action that may now proceed. A receipt for a budget increase should say the amount, the period, and the person who may spend it. Without those details, the assistant has a friendly reply rather than permission.
Write the receipt at the moment the decision is made, while the context is still visible. Copy the client wording into the record and add a plain summary beside it. Do not rewrite the client message into a stronger promise than they made. The summary should reduce ambiguity, not create a new agreement.
Decide which decisions always require a receipt before work continues. Price changes, refunds above a threshold, contract terms, access grants, and public statements belong on that list. Routine choices inside an approved scope may not need a separate receipt. The list should be short enough that the team actually follows it.
Record the approver and the scope
Store the name and role of the person who approved the work. A first name in an email thread is not enough when a later reviewer asks who had authority. Add the client, the project, and the date of the decision. If a delegate approved on someone else's behalf, record the delegation and its limit.
State the scope in observable terms. Say which documents, accounts, customers, or amounts the approval covers. Add the start and end date if the permission is temporary. An approval that says to proceed with the launch is weaker than one that names the pages, the markets, and the date.
Include the conditions that came with the approval. A client may agree to a refund only after the item is returned, or to a discount only for a fixed number of seats. Conditions are part of the decision, and an assistant who cannot see them may act too early. Put the condition beside the action rather than in a separate note.
Store the evidence with the task
Attach the source message, the signed form, or the system approval to the task record. A receipt that points to a personal inbox is not verifiable by the next person. Use a shared location with a stable link and a clear name. The link should still work when the original assistant is on leave.
Keep the evidence in a format that a reviewer can open without special access. A screenshot may be enough for a short approval, while a contract change needs the original document. Record the format and the date it was captured. If the client later edits the message, the captured copy preserves what was actually approved.
Limit who can change the receipt after it is stored. The person who recorded it should be able to add a correction, but the original values should remain visible. A history of changes is more useful than a clean record with no trail. Reviewers can then see whether the scope changed or the note was merely corrected.
Make the receipt easy to check
A useful receipt can be checked in under a minute. Put the decision, the approver, the scope, the conditions, and the evidence link at the top. Move the full message and the discussion below. A reviewer should not have to read a long thread to find the permission.
Use the same fields for every approval so the team learns where to look. A short template is easier to complete than a blank page and easier to compare across clients. Add one optional field for notes that do not fit the standard structure. Too many optional fields turn the receipt into a narrative.
Ask a second person to check a sample of receipts each month. The check should confirm that the decision matches the action taken and that the evidence opens. Record the result and fix the template when the same field is missing. The sample is a test of the process, not a search for someone to blame.
Handle a change after approval
A new message can change an old approval, and the change needs its own receipt. Link the new decision to the original and state what it replaces. Do not edit the first record into the new one. Keeping both shows how the scope moved and who agreed to the movement.
Mark the earlier approval as superseded rather than deleting it. A reviewer may need to know what was allowed before the change, especially if work already happened. Add the date the new decision took effect and the person who confirmed it. The task should point to the current receipt, not a mix of old and new notes.
Tell the people who acted on the first approval that it changed. Send a short note to the queue owner and anyone who scheduled work from the old scope. A change that stays in the receipt system but never reaches the work is only a record. The handoff is part of the control.
Set the assistant boundary
The assistant may prepare the receipt, check that the fields are complete, and link the evidence. The person with authority must make the decision and confirm the summary. An assistant should never turn a polite maybe into an approval. That boundary belongs in the role brief and in the approval template.
Define what the assistant does when the evidence is incomplete. The default should be to pause the action and ask the named owner for the missing piece. Do not let the assistant proceed on the assumption that the client probably meant yes. A pause is cheaper than reversing a payment or a public statement.
Review the approval list each quarter with the client owner. A new service, a new tool, or a new spending limit can make an old threshold unsafe. Record the review date beside the list. The receipt process should change when the work changes, not only when someone remembers.
Sources
Open the original publisher and confirm the current version, definition, and scope before using a source for a business decision.
Turn the reading into a role brief
Bring the recurring tasks, tools, schedule, access limits, and owner-only decisions. Start with one work sample and one clear review path.
Plan a Philippines-based role