New client onboarding
Turn accepted scope, access, owners, first-value work, and kickoff readiness into a visible route.
How It Works
From OS review to operating handoff.
Valdris starts with live workflow reality, narrows the install to three P1 delivery workflows, builds the operating spine, and hands it to a named OS Owner.
Client path
The path is narrow on purpose.
Valdris does not start by rebuilding the company. The path moves from fit, to scope, to handoff, to a 90-day install, then to a next decision.
01
Deploy
Discovery / Qualification
Confirm fit, workflow pain, buyer authority, budget, OS Owner readiness, and whether the work belongs in Deploy, Build, Labs, or no-fit.
02
Deploy
Recommendation / Scope
Name the three P1 workflows, the expected operating artifacts, client responsibilities, and excluded work.
03
RevOps + CEO Boundary
Commercial Gate
Confirm signed scope, payment status, buyer sponsor, kickoff target, and the public-claim boundary.
04
OS Owner / AI Ops Lead
Sales-to-Delivery Handoff
Build the handoff packet, validate exclusions, confirm owners, and prepare the client execution shell.
05
Deploy
90-Day Delivery OS Install
Install the workflow spine, owners, SOPs, AI assists, review gates, operating cadence, snapshots, and founder pulse.
06
Deploy + Build
Next-90 Decision
Decide what stays operating support, what routes to Build, what enters the next backlog, and what becomes a Labs signal.
Install motion
Map, design, implement, harden, then plan the next operating cycle.
The install works against live delivery work, named owners, review gates, and the existing system of record.
01
Weeks 1-2
Diagnose and Map
Map current delivery flows, founder routing, source-of-truth gaps, proof gaps, and the baseline operating state.
Output: Current-state maps, founder bottleneck map, source map, and baseline snapshot.
02
Weeks 3-4
Design the Delivery OS
Design the target workflow routes, board states, ownership rules, handoffs, SOPs, AI assists, and review gates.
Output: Workflow schema, owner map, RACI, SOP drafts, AI assist map, and founder pulse design.
03
Weeks 5-8
Implement on Live Work
Move real client work through the new operating spine inside the current work system.
Output: Live P1 workflow use, AI-assisted specs and updates, triage rhythm, training, and board adoption.
04
Weeks 9-10
Harden and Handoff
Add QA gates, escalation rules, incident path, OS Owner handoff, and proof-capture routine.
Output: QA gate, incident path, OS Owner blueprint, updated SOPs, and handoff instructions.
05
Weeks 11-12
Stabilize and Plan Next 90
Run operating reviews, clean up SOPs, score the install, and define the next improvement backlog.
Output: Founder pulse, Day 90 scorecard, next-90 backlog, and retained optimization recommendation.
P1 workflow scope
Three workflows carry the first install.
New build / automation
Move requests through spec, owner assignment, Build handoff, QA review, client update, and release check.
Change request / incident
Separate intake, triage, severity, owner assignment, communication, closure, and learning loop.
Kickoff readiness
Kickoff starts when the operating shell is real.
Signed scope or explicit commercial gate status
Payment status
Buyer or executive sponsor
Client-side OS Owner
Valdris delivery owner
Three P1 workflows
Out-of-scope list
Access list
Data and privacy boundary
Client execution shell
First kickoff agenda
Public proof boundary
Client responsibilities
The client has to operate the system with Valdris.
Name an executive sponsor
Name an internal OS Owner
Provide access to current workflow tools and source artifacts
Attend the weekly install rhythm
Move real P1 work into the system of record
Make timely decisions on ownership, scope, and escalation rules
Review client-visible AI-assisted outputs before they go out
Operating outputs
What the install creates.
Current-state and target-state workflow maps
Source-of-truth map
Board or workflow schema
Owner map and lightweight RACI
SOP kit tied to live workflow use
AI assist map with human review gates
QA gate map
Baseline snapshot, weekly snapshots, and Day 90 scorecard
Founder pulse
OS Owner handoff path
Next-90 backlog
Three workflows first
The install goes deep on onboarding, build / automation, and change / incident work before expanding.
Existing tools first
The client work system stays in place unless tool failure becomes a separately approved scope.
Build is scoped separately
Software, agents, dashboards, integrations, and automations route to Build after the operating requirement is concrete.
Proof remains gated
Public outcome language only ships after each claim, source, and surface clears approval.
Proof boundary
The process page explains work. It does not publish proof claims.
Public outcome proof only ships after written claim approval. The page can describe the install path, outputs, owners, gates, and responsibilities while public claims stay inside the approval path.
Operating path only.
The operating path moves from scope to handoff to live install to next-90 decision. Build and Labs only enter after the operating requirement or repeated pattern is concrete.
Start an OS review