Solarly Sites customer launch and handoff pack — reusable template

Solarly Sites — Customer Launch & Handoff Pack

Reusable blank template. Version 1.0. Directed by Nicholas Lee; produced with ChatGPT. Completed customer copies and their evidence are private. This is an operational template, not evidence of a real customer launch, payment or accepted delivery.

01 — Project brief and preview approval

Project record

Customer/project: [Business name / project reference]

Approved scope and exact version: [Existing scope reference / release or content version]

Customer approver and delivery operator: [Named approver / named operator]

Review destination: [Authenticated review location; share access separately]

Intended public destination: [Agreed production domain and key pages]

Included and excluded work: [Agreed pages, functions, integrations / explicit exclusions]

Review deadline and launch window: [Agreed dates and timezone; not a delivery promise]

Customer review

Review the exact version above: business details, copy, images, page structure, mobile presentation and agreed visitor actions. Record APPROVED, CHANGE REQUESTED or NOT REVIEWED and an evidence reference for each item:

• Business details and content rights: [NOT REVIEWED / evidence].
• Pages, images and mobile presentation: [NOT REVIEWED / evidence].
• Agreed visitor actions and contact destinations: [NOT REVIEWED / evidence].
• Included deliverables and explicit exclusions: [NOT REVIEWED / evidence].

Preview decision: [APPROVED FOR RELEASE REVIEW / CHANGES REQUESTED / HOLD]

Approver: [Name]. Exact version: [Version]. Time: [Timestamp and timezone]. Changes or permitted minor exceptions: [References; write NONE only after review].

Approval applies only to the named version. Scope or material content changes require new review. Silence, elapsed time and payment are not approval. Preview approval permits release review; it does not certify a live website. Keep completed copies and private evidence outside the public work archive.

02 — Pre-release acceptance checks

Operator checklist: execute only in an authorized test or release window. Record actual observations; do not copy historical pilot results into a customer record.

Each gate needs PASS, FAIL, NOT RUN or N/A, plus reviewer, time, environment, exact version and a private evidence reference. N/A requires an explicit scope reason and approval; it cannot waive an applicable safety requirement. Unknown or missing evidence is not PASS.

R1 — Version and scope. Customer approval identifies this exact version. Every included deliverable has an owner and acceptance criterion. Result: [NOT RUN].

R2 — Release authority. A named release owner has authorized this candidate and window; there is no competing change, active hold or unresolved release blocker. Result: [NOT RUN].

R3 — Private content. Unauthorized requests disclose no preview, owner data or private attachments. Check actual page and data responses; a hidden menu or search exclusion is not access control. Result: [NOT RUN].

R4 — Public content. No secrets, private records, internal-only links or placeholders. Agreed factual copy, image permissions, page titles and destinations reviewed. Result: [NOT RUN].

R5 — Functional journey. Required navigation and visitor actions work on desktop and narrow mobile. Use approved test identities and destinations, not real customer submissions. Result: [NOT RUN].

R6 — Build and test evidence. Applicable typecheck, build, automated and browser checks completed for this candidate. Failed, skipped or unfinished checks are explicitly assessed, not described as green. Result: [NOT RUN].

R7 — Recovery and ownership. Prior known-good version, recovery owner and recovery procedure recorded. First launch has a safe unavailable or holding-page plan. Result: [NOT RUN].

R8 — Commercial prerequisites. An authorized owner supplies an evidence reference that contractual prerequisites are satisfied, or a documented non-sale exception. Do not infer payment, retrieve accounts or create a charge using this pack. Result: [NOT RUN].

Evidence record: [Gate] | [Result] | [Version] | [Environment] | [Reviewer] | [Time] | [Private reference] | [N/A reason or exception].

Release decision: [READY FOR AUTHORIZED RELEASE / HOLD]. Release owner: [Name]. Authorization reference: [Reference]. Open blockers and next responsible person: [List or verified NONE].

READY is not DEPLOYED. All applicable gates must pass for the same version and no blocking issue may remain. Document-only inspection or disconnected checks cannot substitute for required runtime evidence. This checklist authorizes no deployment by itself.

03 — Live verification and delivery receipt

Complete only after the authorized operator releases the candidate. A preview URL, accepted build request or successful local build is not live-delivery evidence.

L1 — Correct public destination and version. Record production domain, HTTPS, approved content/version and observation time. Result: [NOT RUN / private evidence].

L2 — Public visitor journey. Required pages, navigation and actions work without an operator session, including narrow mobile. Result: [NOT RUN / private evidence].

L3 — Required integrations. An approved end-to-end test reaches its intended isolated test destination. Record N/A with a scope reason where absent. Result: [NOT RUN / private evidence].

L4 — Public/private separation. Public pages are reachable as intended; private responses remain authorized and private. Check rendered response and data paths. Result: [NOT RUN / private evidence].

L5 — Handoff readiness. A named operator accepts ownership; scoped deliverables, access and support instructions are usable; no blocking exception remains. Result: [NOT RUN / private evidence].

If a required destination is unverified, an integration is unavailable or an applicable live check fails, record HOLD or DEPLOYED — NOT ACCEPTED. Do not send the delivered message or count fulfillment.

Customer delivery receipt

Exact delivered version and public URL: [Version / verified public URL].

Live verified by and at: [Operator / timestamp and timezone].

Delivered scope and evidence bundle: [Deliverables / private evidence reference].

Exceptions and accepted limitations: [References, owner and due date; or verified NONE].

Handoff sent and delivery evidence: [Timestamp / private reference].

Customer acknowledgment or agreed acceptance evidence: [Name, timestamp, reference, or PENDING].

Operator acceptance: [Named operator, timestamp and reference, or PENDING].

DELIVERY COMPLETE requires verified live delivery of every contracted item, usable handoff, acceptance evidence under the existing scope and no blocking issue. A waived minor exception needs a named owner and agreed disposition. A missing agreed item means incomplete delivery.

PAID + FULFILLED additionally requires authorized evidence of genuine customer payment to the intended existing account, matched to this delivery. Test or complimentary work, open checkouts, unknown payment and payment without delivery do not qualify. A delivered complimentary project may be complete but is not a paid sale. This pack stores references only and performs no financial operation.

Receipt state: [PENDING]. Paid-and-fulfilled classification: [UNVERIFIED]. No customer, payment, launch or acceptance is established by this blank template.

04 — Operator handoff and follow-through

Use the existing agreed service scope. This document does not invent support commitments, transfer ownership, grant access or purchase services.

Responsibilities

Customer content approval: [Approver] owns business facts, licensed assets, included content and requested changes.

Release and rollback: [Release owner] owns candidate authorization, live checks, recovery and incident decisions.

Website operation: [Operator] owns agreed maintenance, issue triage and change tracking.

Domain and hosting administration: [Account owner/operator] records existing responsibility and approved delegation. Do not include passwords.

Support and commercial evidence: [Support contact / authorized commercial owner] records scope, escalation and evidence references only.

Handoff record

Access method: [Existing authorized route; no secret or bearer link].

Access delivery proof: [Private reference]. Recipient confirmed access: [PENDING].

Support channel and hours: [Existing agreement]. Response commitment: [Existing agreement].

Included maintenance and exclusions: [Scope reference].

Next agreed review: [Date, owner and objective].

Known-good version and recovery reference: [Version / private reference].

Recovery owner and escalation contact: [Names and existing approved channels].

Exceptions

For every exception record [Issue] | [Impact: blocking or minor] | [Owner] | [Due date or next action] | [Approver and evidence]. Write NONE only after checking.

A blocking defect cannot be relabeled minor to complete delivery. Private-data exposure, unavailable contracted functionality, missing authorization or unverified destination means HOLD. Escalate to the release owner and use only the existing authorized recovery process. After correction or rollback, verify the resulting version and update the receipt instead of reusing a previous PASS.

For each subsequent change record the request, affected scope/version, owner, approval, checks, release evidence and customer-facing impact. Store filled packs and evidence privately under the same project record. Publish only a sanitized, separately permitted summary; never contact details, access links, internal references or customer materials.

Handoff acceptance: [Operator name / time / reference or PENDING]. Existing service terms and release permissions remain unchanged.

05 — Ready-to-adapt customer messages

Do not send until the named state is true. These drafts initiate no outreach and assert no actual delivery.

A — Preview ready for review

Subject: [Business] website preview — review [version]

Hi [Name],

Your website preview is ready for review through the private access method we agreed. Please review the business details, content, mobile layout and agreed visitor actions by [date].

Reply with “Approved for release review: [version]” or your requested changes. This is a preview, not a live launch. We will confirm release readiness and the public destination separately.

[Operator name]

B — Live handoff, only after live checks pass

Subject: [Business] website handoff — [version]

Hi [Name],

We have verified [version] at [public URL] against the agreed scope. Your handoff contains [deliverables], the agreed support instructions and [any expressly accepted minor limitations]. Private access instructions were shared separately.

Please confirm receipt and review under [existing acceptance arrangement]. [Named operator] owns ongoing support through [agreed channel].

[Operator name]

C — Delivery on hold

Subject: [Business] website release update

Hi [Name],

The release is on hold while we resolve [plain-language issue]. [State the verified effect on the existing live site or preview; do not assume it is unaffected.] [Owner] is responsible for [next action]. We will provide the next update at [agreed time]. We have not marked the new delivery complete.

[Operator name]

Template verification — not product-runtime evidence

Sixteen fictional disconnected decision-model checks passed. The cases covered a complete authorized delivery; an entirely blank record; approval for an old version; missing release authority; an unverified prerequisite; a required gate not run; an unresolved blocker; preview approval without deployment; a wrong deployed version; a failed live integration; a missing scoped item; unusable handoff; pending acceptance evidence; complimentary delivery; test payment; and unknown payment.

The rules fail closed: release readiness requires version-matched approval, authorization, prerequisite and gate evidence, and no blocker. Live verification additionally requires deployment of that version and applicable live checks. Delivery completion additionally requires the entire agreed scope, usable handoff and acceptance evidence. Paid-and-fulfilled status additionally requires verified genuine-payment evidence.

These checks validate the template decision rules only. They are not Solarly application tests, a security certification, a deployment, a payment verification or customer acceptance. The five-page editable document and Markdown edition were produced without application-code changes or financial operations. All customer/result fields remain blank or explicitly unverified.