# AI Workflow Readiness Checklist ## Workflow Selected: Client Onboarding / Intake --- ## 1. Why This Workflow Qualifies for Governed AI Redesign Client onboarding is a recurring, multi-step process with a stable structure: brief collection, scoping, kickoff, and handoff to delivery. It repeats on a predictable cadence, follows a consistent decision sequence, and produces artifacts (intake forms, scope documents, kickoff notes) that are structured enough for AI assistance but still require human judgment at key gates. [ASSUMPTION] The workflow runs at a volume and frequency (multiple clients per month) that justifies governance overhead. If onboarding happens only a handful of times per year, the cost of building governance controls may exceed the benefit. Confirm actual frequency before committing engineering time. A workflow is suitable for governed AI redesign when it meets most of the following. Client onboarding meets 5 of 6: - [x] Recurs on a predictable schedule or trigger (new client signed) - [x] Follows a consistent sequence of steps across instances - [x] Produces structured or semi-structured inputs and outputs - [x] Involves decision points that can be codified into rules or criteria - [ ] Low variance in exception handling (onboarding varies more by client type and deal size than most back-office workflows, so this is a partial fit) - [x] Has a clear owner and a defined escalation path --- ## 2. Process Definition Readiness - [ ] The full onboarding sequence is documented step by step, from signed contract to handoff, with no undocumented tribal-knowledge steps - [ ] Each step has a named owner (human or system) - [ ] Entry and exit criteria are defined for every step (what triggers the step, what confirms it is complete) - [ ] Variants are mapped. Onboarding differs by client type, deal size, or service tier. Each variant is documented separately, not assumed to follow the default path - [ ] Current cycle time is measured, not estimated. [UNVERIFIED] average time from signed contract to kickoff is not stated in available material and must be pulled from actual records before setting an AI-assisted target - [ ] A single canonical version of the current process exists. If different team members describe onboarding differently, that inconsistency must be resolved before automation, not baked into it --- ## 3. Data and Input Readiness - [ ] Intake data fields are standardized (a fixed form or questionnaire, not free-form email threads) - [ ] Required vs. optional fields are distinguished - [ ] Source systems for client data are identified (CRM, contract system, shared drive) and access is confirmed - [ ] Data quality baseline is known. Missing fields, duplicate client records, and stale contact data are common failure points and should be measured before AI touches the data - [ ] A record of past onboarding examples exists (at minimum 15 to 20 completed cases) to validate any AI-assisted drafting or classification before it goes live - [ ] Sensitive data handling is mapped. Any personally identifiable, financial, or contractual data touched during onboarding is flagged, and its handling under redesign is reviewed against your existing data-handling policy --- ## 4. Decision Points and Judgment Calls - [ ] Every decision point in the workflow is listed (e.g., which service tier applies, which team gets assigned, whether a client requires custom terms) - [ ] Each decision point is classified as one of: - Rule-based (a fixed criterion an AI system can apply directly) - Judgment-based (requires human context, relationship history, or negotiation) - Hybrid (AI drafts a recommendation, human confirms) - [ ] No judgment-based decision is silently converted to rule-based during redesign without an explicit, documented rationale - [ ] Escalation criteria are defined for edge cases (unusual contract terms, VIP clients, compliance-flagged industries) [Blocker risk] If client-tier assignment or scope definition depends on relationship history or negotiation nuance that is not captured anywhere in writing, no AI system can reliably automate that step. This must be resolved by either documenting the missing criteria or keeping that step human-only. --- ## 5. Governance and Compliance Readiness - [ ] A designated owner is accountable for the AI-assisted version of this workflow, distinct from whoever built it - [ ] Every AI-generated output in the workflow (draft scope documents, welcome emails, task assignments) has a defined human review point before it reaches the client or becomes binding - [ ] An audit trail requirement is defined: what gets logged, for how long, and who can access it - [ ] A rollback plan exists: if the AI-assisted step fails or produces a wrong output, the fallback to the fully manual process is documented and rehearsed at least once - [ ] Client-facing AI use, if any (e.g., AI-drafted welcome communications), is disclosed per your own policy and any applicable client contract terms - [ ] No AI system in this workflow is granted authority to finalize a contract, commit to pricing, or make representations to a client without human sign-off --- ## 6. Tooling and Integration Readiness - [ ] Target AI tooling or agent framework is identified for each automatable step, not assumed to be a single tool for the whole workflow - [ ] Integration points with existing systems (CRM, project management, e-signature) are confirmed technically feasible, not just theoretically possible - [ ] Failure behavior is defined for every integration: what happens if the CRM API times out mid-workflow, if a form submission is malformed, or if an AI step returns a low-confidence result - [ ] A test environment or staging path exists, separate from live client data, to validate the redesigned workflow before production use - [ ] Version control or change tracking is in place for any prompts, rules, or automation logic driving the workflow, so changes are reviewable and reversible --- ## 7. Human-in-the-Loop Controls - [ ] At least one mandatory human checkpoint exists between AI-generated scope or pricing content and anything sent to the client - [ ] Reviewers are named, not just roles ("the account lead reviews," not "someone reviews") - [ ] A maximum acceptable AI error rate or confidence threshold is defined for any step that operates with reduced human review - [ ] A feedback loop exists so reviewers can flag bad AI output and that feedback is tracked, not lost in Slack messages or email --- ## 8. Risk and Failure Mode Assessment | Failure Mode | Likelihood | Impact | Mitigation Status | |---|---|---|---| | AI misclassifies client tier, resulting in wrong pricing or scope | [UNVERIFIED, requires historical error-rate testing] | High. Client-facing and contractual | Not yet assessed | | Onboarding data pulled from a stale or duplicate CRM record | [UNVERIFIED] | Medium. Delays or incorrect kickoff | Not yet assessed | | AI-drafted welcome or scope communication sent without human review | Depends on control design | High. Reputational and contractual exposure | Controlled by Section 7 above once implemented | | Workflow automation fails silently (no error surfaced) | [UNVERIFIED] | Medium to high depending on step | Requires explicit failure alerting, not yet confirmed present | Fill actual likelihood ratings from historical incident data or a pilot run before treating this table as final. Do not estimate likelihood without evidence. --- ## 9. Success Metrics - [ ] Baseline cycle time (signed contract to kickoff) is recorded before redesign - [ ] Baseline error or rework rate is recorded before redesign (how often onboarding has to be redone or corrected) - [ ] Target metrics are set as ranges, not single point estimates, and tied to the baseline - [ ] A review date is set (30, 60, 90 days post-launch) to compare actual performance against targets - [ ] Metrics include at least one quality measure (client satisfaction or internal review score), not cycle time alone --- ## 10. Rollout Readiness - [ ] A pilot group (a subset of new clients or deal sizes) is defined for initial rollout rather than a full cutover - [ ] A go/no-go checkpoint is scheduled after the pilot, with named decision-makers - [ ] Team members whose work changes under the redesigned workflow have been briefed and given a channel to raise concerns before launch - [ ] Documentation of the new workflow (including the human checkpoints) is written and stored where the team will actually find it, not only in this checklist --- ## Assumptions and Unverified Items - [ASSUMPTION] Onboarding volume justifies governance investment. Confirm actual monthly or quarterly client count. - [UNVERIFIED] Current average cycle time and error/rework rate. Both require pulling from existing records, not estimation. - [UNVERIFIED] Historical AI error rates for classification or drafting tasks in this workflow, since no pilot data exists yet. - [ASSUMPTION] This checklist assumes a single-organization onboarding process. If onboarding differs materially between corporate L&D client engagements and WenceStudio client engagements, run this checklist separately for each. --- ## Confidence Level Structural and governance framework: high confidence, built on standard workflow-readiness criteria. Risk likelihoods and baseline metrics: low confidence, marked [UNVERIFIED] throughout, pending real data from your own systems. Do not treat the risk table or success-metric targets as final until baseline figures are pulled. --- ### Related WenceStudio Resources Continue building your client onboarding pipeline with these companion tools from our library: 1. **The AI Lead Router Automation Blueprint** (Blueprint & Make.com JSON) An importable Make.com automation that catches inbound webhook leads, scores intent, and routes qualified prospects directly to your CRM. - [Download Setup Guide (PDF)](https://drive.google.com/file/d/1Dh_nHjbf1_2RtIPfM_pbDzL5_cPluTYr/view?usp=sharing) - [Get Make.com Blueprint (.json)](https://drive.google.com/file/d/1WVn7Kbv2cg8AbTlXRLfST6QiRCOwbLjD/view?usp=sharing) 2. **The AI Dependency Audit: Governance Kit** (Governance Kit & PDF Guide) A governance starter kit for operational leaders. Includes the 4-layer guardrail model, provider dependency map, outage protocol, and 30-day rollout. - [Download Governance Kit (PDF)](https://drive.google.com/file/d/16sjOoJlmiLYFN4cFWIyDNOsKXehwXKJ4/view?usp=sharing) - [Open Source Document](https://docs.google.com/document/d/1XCBXjn2F7dMpXTNnFUY2odzuMJADkz_Gci39VyjiJdo/edit?usp=sharing)