How do I check a deliverable before sending it to someone else?
Quick answer
Compare the deliverable with the original request, then review its accuracy, completeness, readability, links, file access, and requested format. Check it in the form the recipient will use, not only in your editing view. Fix or flag anything uncertain, and finish with a brief handoff that says what is included and where to find it.
The question, the details, the next step.
I’m about to send a deliverable and want a practical check, not an elaborate approval process. Where should I start?
Start with the request, not with proofreading. Put the original instructions beside the finished work and check each requested item one by one. A polished document can still miss the point if it leaves out a section, uses the wrong format, or answers a different question.
Make a small requirement list: what must be included, who will use it, how it should be delivered, and when it is due. Mark each item as done, unresolved, or not applicable. If you cannot tell whether a requirement is met, clarify it rather than quietly assuming.
How do I check accuracy without turning the review into another full research project?
Review the claims that matter to the recipient and trace them back to the material you were asked to use: approved notes, the supplied brief, or the relevant working file. Check names, dates, figures, labels, and statements that could change a decision. Make sure a conclusion follows from the information shown, rather than from an assumption you forgot to label.
For example, suppose the request is for a one-page project update. If a date is still tentative, write “target date” or flag it for confirmation; do not present it as settled. If you cannot verify an important detail, leave a clear note such as “[confirm owner]” and ask the right person before sending, or state the limitation in your handoff.
What’s a good way to review readability and completeness when the deliverable is a document or slide deck?
Read it as the recipient would: start at the beginning and ask whether each section is understandable without your private context. Check that headings describe what follows, abbreviations are explained when needed, and the main point is easy to find. Look for unfinished comments, tracked changes, placeholder text, inconsistent labels, and sections that refer to missing attachments.
Then check the whole piece. Does it contain every requested section? Is there a clear next step if one is expected? For slides, scan the deck in order and make sure each slide contributes to the requested story. For a document, check that paragraphs and lists are easy to follow.
Links and permissions are easy to miss. How can I check those without assuming the other person sees what I see?
Test each link the recipient is expected to use, especially links to supporting files. Check that it opens the intended item rather than an old draft or an unrelated folder. Review the sharing setting for the intended recipient or audience; your own signed-in access does not prove someone else can open it.
If you cannot verify access, say so and ask the recipient or file owner to confirm the right permission. Avoid sending extra sensitive material just to make access easier. In the handoff, name the attachment or link and point to the final version, not a working copy.
And what should I check about the file and format right before sending?
Compare the file with the requested format and destination. Follow any specified file type, naming pattern, or delivery location. Open the final saved or exported file and scan it as a recipient would; do not assume the editing view and sent version look identical. Check that all pages or slides are present, content is not cut off, and the filename makes the version recognizable.
A simple final handoff could read: “Attached: [deliverable name]. It includes [requested items]. I checked [links/access or format, as applicable]. [Open question or limitation, if any]. Please use [file or link] as the version for review.”
Only mention checks you actually performed. If something remains unresolved, state that clearly instead of describing the deliverable as fully checked.
A practical checklist
Compare the work with the original request and mark each requirement done, unresolved, or not applicable.
Verify important names, dates, figures, labels, and conclusions against the available material.
Review from the recipient’s point of view; remove unintended placeholders, comments, and unfinished changes.
Open the final saved file and check its format, filename, completeness, and layout.
Test links and check access for the intended audience; flag anything you could not verify.
Identify the final file in your handoff and note unresolved details or limitations.
A few more useful answers
Should I ask someone else to review it?
Ask for another review when the stakes, complexity, or uncertainty justify it, or when approval is required. Give the reviewer a focused prompt, such as checking completeness or verifying key figures, rather than asking only whether it looks good.
What if I find a problem but the deadline is close?
Fix issues you can safely resolve, and promptly flag anything important you cannot confirm. Tell the recipient what is affected and what input is needed; do not hide a known gap behind a polished handoff.
How do I know when to stop checking?
Stop when the stated requirements have been checked, the final version is usable in its intended form, and unresolved points are clearly identified. Repeating the same review without a new question or finding is unlikely to improve the handoff.