Customer Onboarding & Deployment

At a glance — typical 2-to-4 week timeline

Phase 1 — Signing & contracting

Three documents move in parallel:

• Master Services Agreement (MSA). Standard SaaS terms. Limitation of liability capped at fees paid in the prior 12 months. SOC-2 audit chain commitments codified. We mark up standard customer redlines within 48 hours.
• Order Form. Plan tier (Free / Pro / Enterprise), seat count, start date, billing cycle, negotiated enterprise discounts. Stripe-managed payment for Pro and Enterprise; invoice option available for annual prepay.
• Data Processing Addendum (DPA). GDPR Article 28 / California CCPA processor commitments. Sub-processor list disclosed (Neon, Netlify, Doppler, Resend). Customer-specific data residency commitments documented.

Same-day provisioning post-signature:

• Welcome packet (PDF) with full deployment checklist
• Shared Slack Connect channel opened with your IT lead, your security reviewer, and our technical contact
• Named technical contact on the AscendCore side (Jacob during pre-Series-A; dedicated SE post-Series-A)
• Calendar invite for the kickoff call (typically within 2 business days)

Phase 2 — Kickoff call

60 minutes. Video. Attendees on your side: IT lead, security reviewer (if separate), implementation champion. On our side: technical contact + our CEO for the first 20 customers.

Output: written project plan within 24 hours, including milestone dates, owner-per-task split, and a security review document for your CISO if requested.

Phase 3 — Custom request form

A structured intake that captures everything specific to your environment. Your IT lead fills this out (typically 30–45 minutes) and we respond with a feasibility assessment + implementation timeline within 48 hours.

What the form captures:

• Integration scope. Which of the 13 production runbooks to enable on day-1, which to phase in later.
• Identity provider. Okta or Entra ID as primary; mandatory IdP-mediated MFA enforcement preference.
• Approver model. Who can approve approval cards (e.g., L2 helpdesk lead, on-call IT director, specific group of senior engineers). Group-based or named-individuals.
• Custom runbook needs.Any workflows specific to your business not covered by the standard 13. We'll scope feasibility — most fit our existing primitives.
• White-label preferences. (Phase 4 roadmap) Custom Slack/Teams bot name, icon, and approval-card branding. Documented now, enabled when Phase 4 ships.
• Audit retention policy. Default 7 years for Pro/Enterprise; customer-specified retention available on Enterprise plan.
• Data residency. Default US (Neon Postgres + Netlify Blobs); EU-resident option on Enterprise plan.

Phase 4 — Deployment

The actual technical setup. Three parallel tracks; we project-manage all three with daily standups in the shared Slack channel.

End-of-phase verification: a green checkmark for each enabled runbook (e.g., "MFA reset against Okta: connection OK, scopes verified, dry-run passed"). You sign off in writing before we move to sandbox testing.

Phase 5 — Sandbox testing

A full week (or two for larger deployments) in Sandbox Mode. Your Slack/Teams approval cards post for real, your team practices the approve/deny flow for real, the audit log writes for real — but the downstream Okta/Entra/M365/Intune/Jira/Confluence calls are mocked. No real users, licenses, groups, or devices get modified.

What we do this week:

• Run every enabled runbook end-to-end with test users / fake employees
• Practice the approver workflow with your designated approvers
• Review every audit log entry; verify the chain links
• Tune approver routing if anything feels off
• Identify edge cases specific to your environment (custom group naming, B2B guest users, etc.)
• Validate the Customer API end-to-end if you're using it for runbook triggering from your own tooling

We're on-call in the shared Slack channel all week with sub-2-hour response time during business hours. End-of-week, your team signs off that they're ready for production cutover.

Phase 6 — Production cutover & staff rollout

Cutover:

• Flip your org from Sandbox → Live in Settings → Test Mode
• First 3–5 real runbooks run with both teams watching live
• Customer audit log starts capturing real production events

Staff rollout:

• Internal announcement email to your IT team. We provide a template you can customize.
• 30-minute training session for your IT staff, delivered live by us or recorded for async viewing. Covers: how to request runbooks via Slack/Teams, how the approval flow works, where to check the audit log.
• Customer-specific cheat sheet with your org's exact slash commands, approver chain, and SLA expectations.
• Daily check-ins for the first week, then weekly for the first month, then monthly thereafter for the first 90 days.

Day 30 milestone: full deployment review meeting with your IT lead. We walk through what worked, what didn't, what we'll change for the next 90 days. Renewal conversation timing is shared transparently.

Responsibility split

What you'll need on your IT side

Gathering these before Day 0 takes the deployment timeline from 4 weeks to 2 weeks:

• Admin access (or a path to admin) in each integration system you want to enable
• Authority to create new service accounts + grant OAuth scopes
• A decision on which IdP (Okta or Entra ID) will be the source-of-truth for AscendCore admin login
• A list of who can approve approval cards (group-based works fine — e.g., it-leadership@yourdomain)
• A secure credential-transfer mechanism (1Password, Bitwarden, Hashicorp Vault, or S/MIME)
• If egress filtering is in place: ability to whitelist our outbound IPs
• A point-of-contact for security review (if separate from IT lead)

Plan tier impact on onboarding

Frequently asked