Workflow App Sprint Category
Onboarding Readiness Gate
For customer success and implementation teams that need one readiness handoff before launch, go-live, or customer expansion.
Delivering client implementations? Explore the IT go-live acceptance pilot.
For IT implementation firms and MSPs
A clear go-live handoff for your next client.
Give the delivery lead one place to review readiness, surface exceptions and name the next owner before implementation becomes a support responsibility.
Make the handoff explicit.
Review commercial, security, migration, integration and training readiness. Keep customer acceptance references and the receiving support owner in the agreed handoff record.
One workflow. Five agreed cases.
Start with the Customer Onboarding Readiness Gate, browser-based metadata intake, a visible decision record and an operator-led handoff. Define your acceptance evidence before the build starts.
$2,500 total
10 business days after scope, deposit and inputs are confirmed. $1,250 at written scope acceptance and $1,250 after the five agreed acceptance cases pass. No subscription is attached to the base pilot.
In your brief, name the implementation workflow and the delivery lead. Use redacted metadata, not credentials or private customer documents.
Illustrative cases — see the five starting examples
These examples describe the existing readiness rules, not customer results. We replace them with five representative cases agreed with you before accepting a pilot.
Required checks are complete, no blockers remain and launch is seven days away.
The delivery lead confirms customer acceptance and the receiving support owner before scheduling. This result does not perform the launch.
An enterprise client has not completed its security review, even though the other checks are complete.
Return the missing review to its owner. Update the facts and run a new decision before proceeding.
One blocker remains. The implementation should not silently pass because most checks are green.
The delivery lead records the issue, reviewer and next action. A review result is not permission to deploy.
Launch is two days away and administrator training is incomplete.
Confirm training and a revised handoff plan with the customer before rerunning readiness.
The implementation-owner field is empty. A complete-looking checklist is not enough.
Name the accountable owner first. Invalid intake produces no readiness verdict.
Clear boundary: a readiness result is not a customer signature or proof of a completed launch. The app does not deploy software, change client systems, or provide team approval permissions. Production connectors, white-label delivery and managed support require separate written scope.
The workflow
Where this breaks today.
Current failure mode
Launch readiness depends on scattered implementation status, training notes, security review, integration blockers, and owner judgment.
Focused app surface
A readiness intake, review rulebook, Decision Record, and CS handoff that returns ready, blocked, or review required.
Runtime or record layer
Binding mode: decision_record_only. Customer executable rulebooks are outside the current production contract.
Example boundary
What the app decides or hands off.
Account has target launch date, integration status, training state, security review, blockers, owner, urgency, and missing inputs.
Ready, blocked, or review required before implementation moves the account to go-live.
One rushed launch with missing blockers can create churn risk, support load, customer-facing confusion, and avoidable implementation rework.
What ships
One useful workflow surface, not a broad project.
Trigger, current path, owner, failure modes, and the boundary where work should proceed, block, review, or route.
Required fields, evidence standard, missing-input states, and examples of acceptable requests.
Direct declarative Rulebook v1, trusted-adapter fact contract, or Decision Record-only path depending on the workflow.
A focused Krafthaus surface the workflow owner can run on five accepted cases, with a visible result, record, next owner, and handoff.
What gets stored, where the record travels, and who or what receives the next action.
What to automate, measure, or turn into repeat runtime usage after the first workflow proves useful.
Trust boundary
Start with metadata and handoff shape.
Runs on readiness metadata first. Private customer documents can remain in the existing implementation system.
One workflow
The sprint deliberately avoids broad AI transformation, platform rebuilds, or customer executable rulebooks.
Metadata first
The first sprint can use request metadata, policy fields, evidence status, owner, risk, and desired handoff before private-system integration.
Confirm the bottleneck, then review five cases
If the workflow is real, use 15 minutes to confirm the owner, required inputs, five acceptance cases, and delivery boundary.
Workflow App Sprint
Map your version of Onboarding Readiness Gate.
Use this category as the public pattern. The company-specific artifact comes after the workflow is real enough to review.