Answer in brief
A finished presentation is not the same as a usable project. This guide gives buyers an acceptance sheet for four connected workstreams and a way to record what remains open.
What acceptance means when four teams share one brief
A project handover checklist is a record of what a buyer can actually operate after the supplier leaves. For a combined brand, website, AI workflow and marketing project, it should identify each promised asset, its working location, the person who can approve it, and a test that a new team member can repeat. This is a method for buyers, not a report of a VITON13 client result. Imagine a small apparel company launching a new identity and online enquiry flow: the examples below are deliberately hypothetical, with no claimed revenue or conversion lift. The useful question is not whether the launch deck looks complete, but whether the company can open, change, measure and support what it has paid for.
Begin with the signed brief and the latest written scope. Give the four workstreams distinct acceptance lines even if one studio coordinated them. A logo export cannot prove that the website works; a live page cannot prove that the marketing account is controlled by the client; an impressive AI answer cannot prove safe handling of an ambiguous request. Put a single decision owner on the client side and a delivery owner beside every line. Record the version reviewed, evidence link, reviewer, date and status: accepted, defect, dependency, or proposed change. VITON13 Studio describes written scope and price, human review, revision rounds, delivery and support as separate stages; the sheet makes those boundaries inspectable rather than implied.
Brand handover: editable identity, not just a polished PDF
The brand line should list the master logo, approved variants, colour values, type choices, image direction, usage rules and representative applications named in the brief. For each item, distinguish a viewable presentation from editable source material. A PDF can show the approved identity, while a packaged design file and licensed font information let the next designer make a new sign or social template without rebuilding the work. If the contract promises only exports, do not silently add source files to the acceptance test; instead, flag the operational gap before approval and agree whether an editable package is a change in scope. Record where each file lives and whether the client can open it using its own account.
Test the identity in the situations it was designed for. In the hypothetical apparel launch, place the logo on a light mobile header, a dark shipping label, a narrow social avatar and an email footer. Check that the smallest required use remains legible and that colours and type names match the documented system. Compare all versions to the signed brief, not to a last-minute preference that nobody priced. The rights line should identify which assets are original, which fonts or images need separate licences, who holds those licences, and any territory or channel limits that were actually agreed. This is a contract question, not legal advice: avoid assuming that receiving a file automatically grants every future use.
Website handover: source, production access and real tasks
For the website, ask for the agreed source repository, deployment instructions, hosting and domain ownership, environment inventory, content editing route and rollback contact. Never put passwords in the handover spreadsheet; record who grants access and how it will be rotated after delivery. GitHub's repository-transfer documentation says a transfer changes who administers the repository; existing webhooks, secrets and deploy keys remain attached, while some plan-dependent features may change. A buyer should separately verify the actual repository owner, administrator list, external deployment connection and backup after the chosen transfer or client-owned setup. A ZIP of code may satisfy a narrow contract but is not equivalent to an operating deployment process.
Run tasks on the delivered site, not only in a designer's preview. From a phone and a keyboard, find a product or service, submit an enquiry with valid information, trigger a missing-field error and locate the privacy and return information relevant to the business. Record URL, device, date, expected result and observed result for each test. Check links and forms against the final content, including one translated route if languages are in scope. W3C's Web Accessibility Initiative advises evaluating accessibility early and repeatedly and notes that no automated tool alone can establish accessibility. Treat a scanner report as one input and document manual observations. A defect with an owner and a retest date remains open; a beautiful launch screenshot does not close it.
AI workflow handover: failure cases and a person in control
An AI workflow needs its own acceptance evidence because its output can vary even when the interface looks unchanged. Define the task it may perform, the data it may read, the action it may take, and the point at which a person must approve or override it. For the hypothetical apparel company, an assistant could draft a stock enquiry response but should not invent availability or commit to a delivery date that the inventory system has not confirmed. Test ordinary input, missing product data, contradictory notes, a request outside the task and a prompt that asks for restricted information. Record what the workflow did, what the reviewer expected and whether the escalation path worked. Do not publish real customer data in the test pack.
NIST's AI Risk Management Framework describes govern, map, measure and manage as functions for ongoing risk work, not a one-time compliance sticker. Translate that into a compact operating record: named owner, allowed sources, version of the prompt or model configuration, sample test cases, reviewer action, incident contact and a pause switch. Agree who pays for the model or automation service, who can change the configuration, and what happens if a provider changes terms. A successful demo establishes neither accuracy across future requests nor a guaranteed return on investment. Acceptance should mean the agreed test set passed and unresolved limits are visible, with a human able to stop the system when the input is uncertain.
Marketing handover: accounts, assets and measurement definitions
The marketing line should connect strategy to the accounts in which work will continue. List the approved audience and message, campaign assets, publishing calendar, tracking plan, reporting definitions and the accounts that hold them. For each channel, record whether the client owns the account, which agency users have access, what permissions they need and who can remove them. Google Analytics Help explains that users can be added at account or property level and that the level affects their access. That makes a practical acceptance test possible: an authorised client administrator signs in, sees the right property, can inspect the agreed events and confirms the agency role is no broader than required. An emailed dashboard screenshot cannot substitute for that test.
Keep paid media budgets, creative production, software subscriptions and the studio's fee on separate lines. Do not report a campaign as successful because the analytics interface shows a number without a defined event, date range and attribution rule. In the hypothetical launch, the company might call a completed enquiry its primary event; that is a proposed measurement choice, not proof that enquiries increased. Capture the starting measurement state before launch, the tagging or consent assumptions, and the person who checks data quality after release. Provide editable creative files only where contracted, plus final approved copies and a schedule that a replacement team could follow. Remove supplier access only after the client has confirmed control and the agreed support work is finished.
Ownership, third-party cost and revision boundaries
A clean handover names the asset owner and the account owner separately. The client may own a brand file while a font licence belongs to a different account; it may own a domain while the old agency still controls the DNS login. Write down the holder, renewal date, recurring charge, cancellation route and export method for hosting, domains, fonts, stock images, AI APIs, analytics tools and paid channels that the project actually uses. Mark unknown charges as unknown until verified, not as included. For repositories, decide whether transfer, shared access or a fresh client-owned organization is the agreed model; GitHub's transfer guidance is a factual reference, not a default instruction to transfer every project.
Separate a defect from a new request. A defect is a delivered item that fails the written acceptance rule; a change adds or alters an approved requirement. The review log should include the evidence, priority, owner and proposed resolution for each. Put the contracted revision rounds and response windows on the same sheet, along with the date when support starts and ends and the work it covers. If a missing source file, licence or account prevents a test, mark the item blocked rather than accepted. Avoid a single 'project complete' checkbox while individual lines remain open. The aim is a fair record that protects both buyer and supplier from guessing later what a verbal approval meant.
A sample acceptance sheet you can adapt
Use one row per deliverable with these columns: workstream; agreed outcome; asset and version; client owner; supplier owner; evidence link; test and expected result; observed result; status; external cost or licence; next action and deadline. This is a hypothetical template, not an account of work VITON13 has performed for a named client. Example row A: Brand, approved identity package, version 1, client creative lead, editable file opens under the client's own account, accepted after the agreed use tests. Example row B: Website, enquiry form, version 2, client operations lead, valid and invalid submissions logged on mobile, defect because the error message is unclear. The status reflects an observable test, not a general impression.
Example row C: AI, draft reply assistant, version 1, operations reviewer, conflicting inventory inputs must be escalated, blocked until the human queue is demonstrated. Example row D: Marketing, Analytics property and campaign calendar, client administrator, access verified but one event definition unresolved, dependency rather than accepted. Add a separate final row for recurring charges and licence renewal owners. This simple sheet lets a new person inspect the same evidence without attending the original presentation. If a supplier offers a different format, preserve the fields rather than the layout. The value is the decision trail: what was promised, what was tested, what failed, and who decides the next step.
Close the project without closing open questions
At the final review, read the sheet line by line. Accept the items that meet their written tests; give defects a retest date; give changes a separate estimate; assign unresolved third-party permissions to a named owner. Ask the client administrator to confirm access personally rather than forwarding a password. Store the final manifest, licence references, instructions and approval record in a place the client controls. Record a support contact and the precise end of the agreed support period, including what counts as maintenance versus new work. If a service renews automatically, somebody should know before the next charge appears. A handover is complete when the recipient can operate the result, not merely when the supplier has sent files.
The method also keeps editorial claims honest. Neither a checklist nor a cited standard guarantees a high-performing site, a safe AI system or profitable marketing. GitHub, Google Analytics, NIST and W3C document specific platform or evaluation practices; the project team still has to apply them to its own contract and risk. VITON13's public process says the scope, exclusions and revision rounds are written before work starts, followed by review, delivery and support. This guide turns that sequence into a buyer's evidence record. Take the sheet into the next review, ask for the missing proof, and leave every unresolved line visible until a responsible person closes it.
Practical checklist
- Name one client decision owner and one delivery owner for each workstream.
- Match every promised asset to a location, version, format and acceptance test.
- Verify client-controlled access to code, hosting, domains and measurement accounts.
- Run one normal and one failure-path test for the website and AI workflow.
- Record external subscriptions, licence holders, renewal dates and cancellation owners.
- Sign off accepted items, open defects and paid change requests separately.
Questions and answers
What belongs in a project handover checklist?
List the agreed outcome, each deliverable and its version, where it is stored, who controls access, a repeatable acceptance test, open defects, third-party charges, rights or licence conditions, and the support boundary. A screenshot alone does not establish that the client can use or maintain the result.
Should the client own the GitHub repository?
The answer depends on the contract and hosting model. If the repository is to pass to the client, decide whether to transfer ownership or create it in the client organization from the start. GitHub documents transfer prerequisites and consequences; verify administrators and integrations after any transfer.
Is an AI demo enough to accept an automation?
No. Use representative inputs, missing-data and contradictory-input cases, a named human approval point, and an escalation route. Log the expected and observed outcomes. A polished demonstration shows a possibility; it does not establish that the workflow is safe or useful under the client's ordinary operating conditions.