Back to app
Client go-live checklist

Client go-live checklist

A pre-launch checklist for taking a client organization live — what must be done, what should be done, and what can wait until after the team is already working.

Reviewed AdminVertiqa 1.61+

Use this to take a client live cleanly. It's the checklist companion to What a Vertiqa implementation involves — that article explains the shape of a rollout; this one is what to tick off before you hand the client the keys.

The list is grouped by urgency. The Must items make the workspace usable and safe; everything else can land in the first week while the team is already working.

Must be done before go-live

  • Organization created, named, and on its subdomain. See Sign up and create your organization.
  • Real users invited and each assigned a role — nobody over-granted "just to get started."
  • Pipelines and stages reflect how the client actually sells, not the starter defaults. See Pipelines.
  • Task statuses match how the client delivers work.
  • Existing contacts and accounts imported, with the import preview Blocked rows resolved.
  • One person can complete a real end-to-end task in the workspace — the true test that it's usable.

Should be done in the first days

  • Calendars connected for each user so Scheduling offers real availability.
  • The first workflow or automation turned on — start with one, such as routing an inbound inquiry. See Workflows.
  • Vertical pack applied if the client is in a supported trade, so the vocabulary fits. See Pipeline pack gallery.
  • Custom fields the client needs added to their records.
  • Experience Mode set sensibly per user — Full for power users, Simple for lighter or mobile-first roles.
  • Email branding configured so outbound mail and booking pages carry the client's identity.

Can wait until the team has momentum

  • Additional workflows and automations beyond the first.
  • Teams and finer visibility rules.
  • Reporting habits — which dashboard numbers the client watches.
  • Business cards, portals, and other secondary surfaces.

Before you step back

  • The client's own admin knows how to invite users and adjust permissions — so they aren't dependent on you for routine changes.
  • Someone on the client side knows where to look when something breaks, and how to reach support.
  • You've set the expectation that tailoring is configuration, not custom engineering, so later requests are framed correctly.
Was this helpful?