How do I get a checkable record of work done with Microsoft Copilot?
Keep the deliverable's job on the Zambo connection while Copilot assists inside your documents and data: the job's steps, the drafts and files produced, and the checks run are saved as one record with a receipt per step. The client receives the handover link and checks the work without entering your Microsoft 365 environment at all.
Copilot's assistance happens inside the tools where the work lives: documents, spreadsheets, mail, and meetings. That placement is its strength for doing the work and its weakness for proving it, because the trail of what was drafted, summarised, or computed sits inside a tenant your client cannot and should not enter. Work that must be shown to someone outside the tenant needs its record outside the tenant too.
The pattern is the same one this cluster applies to every supported surface, Claude, ChatGPT, Gemini, Cursor, Grok, Windsurf, and VS Code included: the job is the unit of record. As the Copilot-assisted work proceeds, its meaningful steps are saved to the job through the connection at https://zambo.dev/mcp : the brief, the source documents consulted (as references, with their states), the drafts produced, the checks run, and the final deliverable. Each step's receipt commits to its saved result at run time under AER-1 (IETF Internet-draft-zambo-aer1-21).
For enterprise readers, the access discipline from the customer-data page applies unchanged: references rather than bulk copies, the inventory of what agents can reach, and the client's view scoped to their jobs. The result is a Copilot workflow whose outputs can be handed to a client, an auditor, or a successor with the same link-based confidence as work done anywhere else.
Checklist: recording Copilot-assisted work
1. Open the job on the connection before the Copilot work starts. 2. Save the brief as step zero, with the deliverable and its deadline. 3. Reference sources as steps: documents and data consulted, by name and state, not by bulk copy. 4. Save drafts and outputs as steps as they are produced, versions in order. 5. Save the checks: the reviews, tie-outs, and approvals run before delivery. 6. Deliver as a handover; the client's acceptance closes the record. Rule: if a step would matter in a dispute about the deliverable, it belongs in the job.
Worked example
The deliverable end of the pattern is the public shape: https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297 , a job whose steps a client opened and accepted from outside the producing environment entirely. Copilot-assisted jobs delivered this way carry the same property: the proof lives where the checker lives, not where the work happened to be done.
Frequently asked questions
Does this require our Copilot licence to change?
No. Copilot keeps doing the assisting inside your existing environment. The connection adds the record layer around the job; nothing about the licence, the tenant, or the documents' home changes.
Can the steps be saved automatically?
The job's steps are saved as the work runs through the connection. Work done entirely inside a document with no job step saved is, like all unrecorded work, provable only as a summary after the fact, so the habit is to open the job first, every time.
What should a client see, and what stays internal?
The client sees their jobs: steps, deliverables, and the decision view. Internal steps from other work never enter their jobs, because the job is the scoping unit; the access inventory governs the rest.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai