Turn a Working Client Setup Into a Reusable Snapshot

Before packaging, document:

What this system does: Captures a cleaning inquiry, creates or updates the intended opportunity, assigns responsibility, acknowledges the request, and follows up until a stop condition occurs.

What it does not do: Automatically price every job, guarantee appointments, connect the buyer's services, or replace the buyer's communication policies.

Required manual setup: Business details, service area, account-specific connections, staff assignment, calendar selection, messaging eligibility, and final testing.

An explicit boundary is part of a useful product.

Suggested manifest:

For each asset, record: Name, Purpose, Dependencies, Whether supported in the snapshot mechanism being used, Whether manual recreation or connection is required.

Check current supported asset types before promising inclusion.

Example:

CT | Form | Quote Request
CT | Workflow | Inquiry Entry
CT | Workflow | Follow-Up
CT | Workflow | Stop on Reply
CT | Pipeline | Cleaning Inquiries

The prefix makes related assets easier to find and reduces confusion with existing account assets.

Include a version in your release documentation. Avoid renaming every asset on every update unless the change is intentional.

Inspect:

• Page copy
• Form defaults
• Email and SMS templates
• Notification recipients
• Assigned users
• URLs
• Calendar references
• Payment references
• Custom values
• Workflow conditions
• Sample contacts
• Tracking scripts

Search for the original client's business name, domain, email address, phone number, and staff names.

Do not assume that because an asset looks generic, every setting inside it is generic.

Never package credentials or confidential client information.

The installer should inspect triggers, recipients, timing, and stop conditions before activation.

Document which workflows should remain inactive until configuration is complete. Verify the actual import behavior rather than assuming activation state will be preserved.

A snapshot should not begin sending messages to real contacts before the installer understands its behavior.

Use a controlled destination with no unrelated customer activity.

Follow your own documentation literally:

• Load the supported assets.
• Complete each configuration step.
• Connect the required services.
• Review dependencies.
• Activate only the intended test paths.

Record anything you had to remember that the documentation did not explain. Add it to the instructions.

Then consider a separate installation test in a destination with existing assets. That exposes naming conflicts, duplicate pipelines, and assumptions hidden by a clean account.

Required cases:

• Valid inquiry
• Duplicate submission
• Missing usable contact information
• Outside service area
• After-hours inquiry
• Customer reply
• Relevant booking
• Closed opportunity
• Channel opt-out
• Repeat customer making a new request

For each case, record: Input, Expected result, Actual result, Pass or fail, Required correction.

Test content and behavior. A workflow can execute successfully while sending the wrong business name or linking to the wrong calendar.

Include:

• Asset manifest
• Supported use case
• Installation sequence
• Required connections
• Business details to replace
• Workflow activation order
• Acceptance tests
• Known limitations
• Version and change notes
• Support boundaries

Use precise support language. "Installation questions covered" is different from "unlimited customization."

Document whether a release adds new assets, changes existing ones, or requires manual migration.

Test update behavior before recommending it to buyers. Do not imply that pushing an update is risk-free or that it will preserve every customization.

Give buyers a reason to trust the system: a clear description of what changed and how to validate it.