Adoption Playbook
A phased plan for rolling Obelisk out across one pilot organization, real automation, and platform governance
Ask AI about this page
Get answers grounded in the live Obelisk docs set, with source links, selected-text explainers, and prompts for the next document to read.
Migration answers what to move. Adoption answers how the team changes once the product is available.
Use this page when you need a rollout plan, not just a tooling map.
The Core Adoption Principle
Do not try to make everyone use everything at once.
The strongest rollouts happen in this order:
- one real organization
- one real workflow
- one real automation path
- one real governance loop
Phase 1: Establish One Trustworthy Workspace
In the first phase, success is simple:
- one organization is set up correctly
- members and admins are assigned intentionally
- the team trusts the workspace home, settings, and activity surfaces
Use these pages:
- Backend Getting Started: Sign-in, Organizations, and Navigation
- Organization Workspace: Daily Navigation and Core Product Surfaces
- Organization Settings: General, Members, Roles
Phase 2: Make One Workflow Official
Pick the workflow that causes the most coordination cost today.
Common first choices:
- lead and support coordination
- contract deployment review and queueing
- indexer lifecycle control
- channel lifecycle control
The goal is to make Obelisk the source of truth for one workflow before expanding to five.
Phase 3: Put Real Automation Through The Product
This is where adoption becomes sticky.
Create:
- environment-specific API keys
- one production-like caller against the public deployment API
- one outbound webhook receiver
- one operator client that consumes the notification SSE stream if needed
At this point the product stops being "another dashboard" and starts becoming part of the execution path.
Phase 4: Move Governance Into The Platform Layer
A rollout is incomplete if governance still lives outside the product.
At this phase, teams should:
- restrict platform
admin - use platform alerts instead of chat-first escalation
- review audit and delivery records in the product
- know who owns alert acknowledgement and who owns incident follow-through
Role-Based Adoption Targets
Founders should be able to answer which tools can now be retired, whether spend, delivery, and risk are finally visible in one place, and whether the team now has one operating model instead of several.
Operators should be able to say that daily work happens in the organization workspace, notifications and support no longer require a parallel system, and tenant context is easier to understand before taking action.
Developers should be able to say that runtime actions are traceable, automation is credentialed and scoped properly, and deployment retries and incident review are no longer hidden in scripts.
Admins should be able to say that alert delivery is real, platform intervention has one canonical place, and cross-tenant governance is visible without entering every workspace manually.
Signals That Adoption Is Working
- links to Obelisk routes replace screenshots from side tools
- incident review uses platform alerts, audit logs, and delivery state
- API keys are named by integration or environment
- members know which work belongs in the organization workspace and which belongs in admin
Signals That Adoption Is Failing
- teams still treat the product like a demo surface
- runtime actions keep happening through old personal scripts
- billing ownership and operator ownership are still disconnected
- no one owns webhook reliability, alert routing, or role hygiene