Sub-Account Provisioning Workflow

The first client workspace an agency builds takes two weeks and is a work of craft. The fifth takes three days because someone remembers most of it. The twelfth takes three days again, but a calendar is pointing at the wrong timezone, the missed-call text still carries the previous client's name, two pipeline stages are named differently from every other account, and nobody notices until the client does. Provisioning by memory produces an estate where no two workspaces are the same, which means no process, no training material and no reporting can be written once and reused.

The cost shows up at three distinct moments. At handover, because the account manager inherits a workspace they did not build and cannot reason about. At the first incident, because fixing a broken automation means reading it from scratch to work out what it was supposed to do. And at scale, because a fix discovered on one account has to be hand-applied to every other one, and in practice is applied to about half. An agency with twenty inconsistent workspaces is carrying twenty separate codebases with no version control.

There is also a revenue-timing problem that rarely gets named. Every day between contract signature and a working workspace is a day the client is paying for nothing visible, and the honeymoon period where goodwill is highest is being spent on setup rather than on results. Slow provisioning front-loads doubt into the relationship. The leak is not only labor cost; it is the compounding effect of starting every engagement a week behind and never getting that week back.

Provisioning pipeline and stages

A pipeline named Workspace Provisioning in the agency workspace. One opportunity per new client workspace. Stage movement is the state machine, so anyone can see where every build has stalled.

• Signed - Awaiting Intake - contract executed, intake form sent, nothing built.
• Intake Received - all required intake fields present and validated.
• Workspace Created - empty workspace exists, named to convention, template not yet applied.
• Template Applied - the blueprint has been deployed; everything still carries placeholder values.
• Branding Applied - logo, colors, sending identity and domain in place.
• Numbers and Domains Pending - number provisioning and registration submitted, waiting on carrier or DNS.
• Integrations Connected - calendar, payment, ad and analytics connections authorized by the client.
• Placeholders Replaced - every token swept and verified; zero placeholder strings remain.
• QA In Progress - the verification checklist is being run against a live test lead.
• QA Failed - a check failed; the failing item and owner are on the record.
• Ready for Handover - passed QA, awaiting the walkthrough call.
• Live - handed over, client has credentials, monitoring active.

Calendars

• Provisioning Kickoff - 45 minutes, booked straight from the signature confirmation. Used to collect anything the intake form could not, and to set the handover date on the call rather than by email.
• Integration Authorization Session - 30 minutes, screen-share slot where the client authorizes calendar and payment connections live. Offered as a fallback when self-service authorization stalls, which it reliably does.
• Workspace Handover Walkthrough - 60 minutes, the only route to Live. Recorded, with the recording filed to the client record.
• Internal Build Block - a recurring internal calendar the build engineer uses, so provisioning has protected time instead of being squeezed between client calls.

Custom fields

Every one of these is an input to templating. A field left empty is a provisioning blocker by design, not a thing to fill in later.

• client_legal_name, client_trading_name, workspace_name_convention.
• client_industry_template - which blueprint version to deploy: Clinic, Home Services, Professional Services, Fitness, or Generic.
• template_version_applied - the exact blueprint version string, written at deploy time. This is the field that makes fleet-wide patching possible.
• client_timezone, client_business_hours_open, client_business_hours_close, client_days_open.
• brand_primary_color, brand_secondary_color, brand_logo_url, brand_tone_notes.
• client_reply_to_email, client_sending_domain, client_sms_number, client_tracking_number, client_forward_to_number.
• a2p_brand_status, a2p_campaign_status, domain_auth_status - each Not Started, Submitted, Approved or Rejected.
• integration_calendar_status, integration_payments_status, integration_ads_status, integration_analytics_status.
• primary_admin_name, primary_admin_email, secondary_users, user_seats_requested.
• services_offered - drives which calendars and pipeline stages survive the template prune.
• placeholder_sweep_passed, qa_checklist_passed, qa_failed_item, qa_owner.
• provisioning_started_date, provisioning_live_date, provisioning_days_elapsed.
• handover_recording_url, build_engineer, account_manager_assigned.

Tags

• Template: template-clinic, template-home-services, template-professional, template-fitness, template-generic.
• Progress: intake-complete, workspace-created, template-applied, branding-applied, placeholders-clean, qa-passed, handover-booked, workspace-live.
• Blockers: blocked-intake, blocked-a2p, blocked-domain, blocked-integrations, blocked-client-asset, qa-failed.
• Fleet: template-outdated - applied to any live workspace whose template_version_applied is behind current, which turns patching into a filterable queue.

Forms and surveys

• Workspace Intake - the client-facing form that does the real work. Sections: business identity, hours and timezone, services offered, brand assets with file upload, named users and emails, numbers to forward to, and the integrations they will authorize. Every field maps one-to-one onto a custom field. Conditional logic shows only the sections relevant to the selected industry. Partial saves are enabled, because this form takes more than one sitting.
• Integration Authorization Checklist - client-facing, one checkbox per connection, each with its own short instruction and a status write-back, so the client can see what remains.
• Internal QA Checklist - the gate. Roughly thirty binary checks across calendars, pipelines, messaging, forms, tracking and branding. Any single No writes to qa_failed_item and blocks progression. There is no override.
• Handover Confirmation - signed by the client at the end of the walkthrough, recording that credentials were received and the walkthrough happened.

BO's role and guardrails

• BO chases missing intake fields by name, in the client's own channel, referencing the specific field rather than asking them to review the whole form.
• BO answers process questions during provisioning: what happens next, what is still outstanding, when the handover is.
• BO never fills an intake field on the client's behalf, and never infers one. No guessing a timezone from an area code, no inferring business hours from an industry. A missing field stays missing and stays visible.
• BO does not touch numbers, domain records, registration submissions or integration credentials. Those are human actions with audit consequences.
• BO cannot move an opportunity past QA In Progress. Human-only, every time.
• BO never discusses pricing, scope or contract terms, and hands any such message to the account manager unanswered.

Numbers and channels

• One tracking number and one messaging number per client workspace, provisioned at the Numbers and Domains Pending stage, with forwarding set to client_forward_to_number and tested with a live call before QA can pass.
• A2P 10DLC brand and campaign registration submitted per client under the client's own legal entity, not the agency's, so consent and liability sit where they belong.
• A client-specific sending subdomain, authenticated, warmed before the first bulk send.
• Provisioning status notifications to an internal Slack channel; client-facing chasing by email with SMS only to the primary admin who opted in at intake.

Template library

• Versioned blueprints per industry, each carrying its pipelines, calendars, custom fields, tags, forms, funnel pages and workflows with placeholder tokens throughout.
• A token convention that is mechanically searchable, for example double braces around an uppercase name, so the sweep can prove zero remain rather than relying on someone reading carefully.
• A changelog per blueprint version, and a rule that improvements are made to the blueprint first and deployed outward, never patched into one live workspace and forgotten.

One new client, from signature to live. The client here is a three-location dental practice on the Clinic blueprint.

1. The signed agreement is countersigned. That event creates an opportunity in Workspace Provisioning at Signed - Awaiting Intake, stamps provisioning_started_date, assigns a build_engineer and account_manager_assigned by round-robin, and sends the welcome email carrying two links: the Workspace Intake form and the Provisioning Kickoff calendar.
2. The client books kickoff for two days out and starts the intake form. They complete identity, hours and services, then stop at the brand assets section because the logo file is on someone else's laptop. The partial save holds everything already entered.
3. Twenty-four hours later the intake chase fires. BO messages the primary admin naming the two outstanding items specifically - logo file and secondary user emails - rather than asking them to go back and finish the form.
4. On the kickoff call the build engineer collects the logo by screen-share, confirms the timezone out loud, and agrees a handover date. The remaining fields are entered live. The form validator passes, intake-complete is applied, and the opportunity moves to Intake Received.
5. Workspace creation fires. The workspace is created and named to workspace_name_convention, the build_engineer and account_manager_assigned are added as users, and workspace-created is applied.
6. The Clinic blueprint at its current version is deployed. Everything arrives - pipelines, calendars, forms, funnel pages, workflows - with tokens still in place. template_version_applied is written. The opportunity moves to Template Applied.
7. The prune step runs against services_offered. This client does not offer orthodontics, so the orthodontics calendar and its two pipeline stages are removed rather than left dormant. A dormant asset is a future support ticket.
8. Branding is applied: logo, the two brand colors, sending identity set to client_reply_to_email, and the subdomain submitted for authentication. domain_auth_status moves to Submitted and the opportunity moves to Branding Applied.
9. Numbers are provisioned. A tracking number and a messaging number are allocated, forwarding is set to client_forward_to_number, and A2P brand and campaign registration is submitted under the practice's own legal entity. a2p_brand_status and a2p_campaign_status move to Submitted. The opportunity moves to Numbers and Domains Pending, which is the one stage the agency cannot speed up, and the build continues in parallel rather than stopping.
10. The integration authorization checklist goes to the client. Google Calendar is authorized the same day; Stripe takes four days and three chases. When all four integration status fields read Connected, the opportunity moves to Integrations Connected.
11. The placeholder sweep runs. It scans every workflow step, message body, form field, calendar description and funnel page for the token pattern and reports eleven remaining hits, nine of which are legitimately filled from fields and two of which are a message body nobody had wired up. The two are fixed. The sweep re-runs clean, placeholder_sweep_passed is set and placeholders-clean is applied.
12. QA starts. The build engineer submits a live test lead through the real form, takes the booking confirmation, answers the tracking number, and walks the thirty-item checklist. Check 18 fails: the missed-call text arrives outside the configured business hours because the workflow was reading agency timezone rather than client_timezone. The opportunity moves to QA Failed, qa_failed_item records the check, and - importantly - the fix is made in the Clinic blueprint first, version-bumped, then applied here.
13. QA re-runs and passes. qa_checklist_passed is set, qa-passed applied, the opportunity moves to Ready for Handover, and the handover booking link goes to the client.
14. The walkthrough runs and is recorded. handover_recording_url is written to the record, the client signs the Handover Confirmation, credentials are issued to primary_admin_email, and the opportunity moves to Live.
15. Going live stamps provisioning_live_date, computes provisioning_days_elapsed, applies workspace-live, removes every progress tag, enrolls the client in the reporting cycle and the churn-risk monitor, and schedules the thirty-day post-launch check. Because the blueprint was version-bumped during QA, every other live workspace still on the previous version is tagged template-outdated, which is now a patch queue rather than a forgotten defect.

1. Signature to Intake Dispatch

Trigger: countersigned agreement received, or the deal record moving to Closed Won in the agency sales pipeline. Pick one and only one, or you will provision twice.

Conditions: exits if an opportunity already exists in Workspace Provisioning for this client. Duplicate provisioning is the most expensive failure in this build, so the guard is first.

Actions:

1. Create the opportunity at Signed - Awaiting Intake. Stamp provisioning_started_date.
2. Assign build_engineer and account_manager_assigned by round-robin across available staff.
3. Copy client_legal_name and client_industry_template from the signed agreement, and apply the matching template tag.
4. Wait 15 minutes, so the welcome does not arrive in the same breath as the countersignature.
5. Send the welcome email from account_manager_assigned. Copy: Welcome aboard. Two things to get us moving. First, the setup form - it takes about fifteen minutes and you can save and come back: [intake link]. Second, grab a kickoff slot so we can fill any gaps together: [kickoff link]. Once both are done we will have your workspace live and walked through by [target date].
6. Apply blocked-intake, so the opportunity is visibly waiting on the client rather than looking idle.
7. Create an internal task for build_engineer: provision this workspace when intake clears.

Stop or exit: ends on creation. All further movement is driven by the stage machine.

2. Intake Chase and Field-Level Validation

Trigger: opportunity enters Signed - Awaiting Intake.

Conditions: every step re-checks the required field set: client_legal_name, client_timezone, business hours, services_offered, brand_logo_url, primary_admin_email, client_forward_to_number. Chasing names only the fields still empty.

Actions:

1. Wait 24 hours. If any required field is empty, BO sends a field-specific chase. Copy: Hi [first name] - your setup form is saved and nearly there. Still needed: [list of empty field labels]. Pick up where you left off: [intake link].
2. Wait 48 hours. Second chase, this time by SMS to primary_admin_email holder if they consented, plus email. Copy: Two items left on your setup form and we can start building: [list]. [link] Reply STOP to opt out.
3. Wait 72 hours. Create a task for account_manager_assigned to call the client, and post to Slack: [client] intake outstanding 5 days. Missing: [list]. Handover date at risk.
4. Wait 5 days. Escalate to the principal and recalculate the promised handover date, notifying the client of the new date rather than letting it slip silently.

Branch: when every required field is populated and the logo file passes a type and size check, remove blocked-intake, apply intake-complete, move to Intake Received, and hand off to workflow 3. A logo that fails the check applies blocked-client-asset and chases that one item only.

Stop or exit: cancels on validation passing, or on the kickoff call being marked attended with fields completed live.

3. Workspace Creation and Template Deployment

Trigger: tag intake-complete applied.

Conditions: runs only if client_industry_template is one of the five valid values. Anything else halts and notifies, rather than silently deploying Generic.

Actions:

1. Create the workspace, named per workspace_name_convention.
2. Add build_engineer and account_manager_assigned as users. Add no one else.
3. Apply workspace-created, move to Workspace Created.
4. Deploy the current version of the blueprint matching client_industry_template. Write the version string to template_version_applied.
5. Wait 10 minutes for deployment to settle.
6. Run the prune step against services_offered: remove calendars, pipeline stages, forms and workflows belonging to services this client does not offer. Removal, not deactivation.
7. Apply template-applied, move to Template Applied, notify Slack with the version deployed.

Stop or exit: if deployment reports any failure, halt at Workspace Created, notify the build engineer and principal, and do not proceed to branding. A half-deployed workspace must never progress.

4. Branding, Domain and Number Provisioning

Trigger: tag template-applied applied.

Actions:

1. Apply brand_logo_url, brand_primary_color and brand_secondary_color across funnel pages, forms, calendars and email templates.
2. Set the sending identity to client_reply_to_email and submit client_sending_domain for authentication. Set domain_auth_status to Submitted and apply blocked-domain.
3. Apply branding-applied, move to Branding Applied.
4. Provision the tracking number and messaging number. Write to client_tracking_number and client_sms_number. Set forwarding to client_forward_to_number.
5. Submit A2P brand and campaign registration under client_legal_name. Set a2p_brand_status and a2p_campaign_status to Submitted. Apply blocked-a2p. Move to Numbers and Domains Pending.
6. Create a task for the build engineer to place a live test call to client_tracking_number and confirm it reaches client_forward_to_number.
7. Poll every 24 hours. On domain authentication confirmed, set domain_auth_status to Approved and remove blocked-domain. On campaign approval, set Approved and remove blocked-a2p.
8. Branch on rejection: a rejected registration sets the status to Rejected, posts the rejection reason to Slack, and creates a remediation task against the documented path for that reason. It does not silently retry.
9. Day 7 still Submitted: notify the build engineer. Day 14: notify the principal and warn the client that the messaging portion of launch may lag.

Stop or exit: all SMS-sending workflows in the new workspace stay disabled until a2p_campaign_status reads Approved, enforced as a condition inside each workflow rather than as a note to the engineer.

5. Integration Authorization and Chase

Trigger: tag branding-applied applied.

Actions:

1. Send the Integration Authorization Checklist to primary_admin_email, with one line and one link per connection. Copy: Four quick authorizations and your workspace is wired up. Each one takes under a minute and you stay in control of your own accounts: [checklist link].
2. Apply blocked-integrations.
3. Wait 48 hours. Chase naming only the outstanding connections by status field.
4. Wait 48 hours. Offer the Integration Authorization Session booking link. Copy: Easier if we do this together - 30 minutes, screen share, we will get all of them done: [link].
5. Wait 5 days. Create a task for the account manager to phone, and post to Slack.
6. When all four status fields read Connected, remove blocked-integrations and move to Integrations Connected.

Branch: where a client declines a connection in scope, record the declined status, notify the account manager, and prune the dependent template assets rather than leaving a calendar that cannot write to anything.

Stop or exit: cancels when all in-scope integrations are Connected or explicitly Declined.

6. Placeholder Sweep and Verification

Trigger: opportunity enters Integrations Connected. Also runnable on demand against any live workspace.

Actions:

1. Scan every workflow step, message body, email template, form field label, calendar name and description, funnel page and pipeline stage name for the placeholder token pattern.
2. Produce a report listing each hit with its exact location.
3. Branch: zero hits sets placeholder_sweep_passed to true, applies placeholders-clean, and moves to Placeholders Replaced.
4. One or more hits creates a task per hit for the build engineer, each naming the asset and the token, and holds the opportunity at Integrations Connected.
5. Re-run automatically 2 hours after the last remediation task is closed.
6. Second consecutive failing sweep notifies the principal and raises the question of whether the blueprint itself is at fault rather than the build.

Stop or exit: no progression on a non-zero sweep, with no override. This single gate prevents the previous client's name appearing in a live message.

7. QA Gate and Failure Routing

Trigger: tag placeholders-clean applied.

Actions:

1. Move to QA In Progress. Assign the Internal QA Checklist to a reviewer who is not build_engineer. Write that name to qa_owner.
2. The reviewer submits a live test lead through the real form, takes a real booking, places a real inbound call, and triggers the missed-call path, then walks all thirty checks.
3. Branch on submission. All Yes sets qa_checklist_passed to true, applies qa-passed, moves to Ready for Handover, and triggers workflow 8.
4. Any No writes the first failing check to qa_failed_item, applies qa-failed, moves to QA Failed, and creates a task for build_engineer naming the check.
5. Every QA Failed event also creates a blueprint task: decide whether this defect belongs in the blueprint. Copy on the task: Check [n] failed on [client]. Is this a build error or a blueprint error? If blueprint, fix there, bump the version, and tag outdated workspaces.
6. Wait 48 hours in QA Failed. If unresolved, notify the principal.
7. Third QA failure on the same build escalates to a joint review of build and blueprint before any further remediation.

Stop or exit: only a fully passing checklist exits to Ready for Handover. No partial pass, no override, no exceptions for a client in a hurry.

8. Handover, Credentials and Go-Live

Trigger: tag qa-passed applied.

Actions:

1. Send the Workspace Handover Walkthrough booking link to primary_admin_email, copying secondary users. Copy: Your workspace is built and tested. Book your walkthrough and we will hand over the keys: [link]. Allow an hour; it is recorded so you can share it with your team.
2. Apply handover-booked on booking. Reminders at 24 hours and 2 hours before.
3. Wait until 30 minutes after the slot. Branch on attendance. No-show sends a rebooking link and holds at Ready for Handover.
4. On attendance, issue named credentials to primary_admin_email and each entry in secondary_users. Never a shared login.
5. Collect the signed Handover Confirmation. Write handover_recording_url to the record.
6. Move to Live. Apply workspace-live. Stamp provisioning_live_date and compute provisioning_days_elapsed.
7. Remove every progress and blocker tag. Enroll the client in the reporting cycle and the churn-risk monitor.
8. Schedule the 30-day post-launch check as a task for account_manager_assigned, and post the completion summary to Slack with days elapsed and first-pass QA outcome.

Stop or exit: cannot reach Live without an attended walkthrough and a signed confirmation. Credentials are never emailed ahead of the call.

9. Fleet Version Drift Monitor

Trigger: a blueprint version is published, plus a weekly scheduled run on Mondays at 07:00.

Conditions: evaluates every client record tagged workspace-live, comparing template_version_applied against the current version for its client_industry_template.

Actions:

1. Apply template-outdated to every live workspace behind current. Remove it from any that are current.
2. Post a weekly Slack digest: count outdated per template, the oldest version still in the field, and the changelog entries those workspaces are missing.
3. Branch on severity recorded in the changelog. A version marked as a defect fix creates a patch task per affected workspace, due within 5 working days. A version marked as an enhancement is batched into the next scheduled maintenance window.
4. Any workspace more than three versions behind escalates to the principal by name, with the account manager copied.
5. On patch completion, update template_version_applied and re-run the placeholder sweep against that workspace, because patching is how placeholders get reintroduced.

Stop or exit: runs indefinitely. The tag is removed only by a successful patch that updates the version field, never by hand.

What is different afterwards

• Provisioning becomes a deployment rather than a craft project. The build engineer's hands-on time collapses to template deployment, branding, numbers and QA - the parts that genuinely require a person.
• Every workspace is identical except where it is deliberately different, and the differences are recorded in fields rather than in someone's recollection. Training material, runbooks and reporting can finally be written once.
• Fixes propagate. A defect found on one account is corrected in the blueprint, version-bumped, and the fleet of outdated workspaces becomes a filterable list instead of a vague worry.
• The things that genuinely take external time - A2P registration, domain authentication, client integration authorization - start on day one and run in parallel, instead of being discovered in week two.
• QA is a gate with no override, so the client never becomes the test suite. The thirty-item checklist is also the first honest document a new hire can learn the estate from.
• Handover is an event with a recording and a signature, not an email saying it is all set up now.
• The agency gains a real answer to how long onboarding takes, with a number behind it, which makes the sales promise accurate.

Metrics to watch

• Signature to live, in days - from provisioning_days_elapsed. Track the median and the worst case separately; the worst case is what prospects hear about.
• Intake completion time - hours from send to a validated form. This is usually the single largest delay and the cheapest to improve.
• First-pass QA rate - share of builds passing the checklist without a QA Failed stage. Rising means the blueprint is improving; falling means someone is deploying from an old version.
• Most frequently failed QA checks - the ranked list of qa_failed_item values is your blueprint backlog, in priority order, for free.
• Blocker days by type - total days lost to blocked-a2p, blocked-domain, blocked-integrations and blocked-client-asset. Separates what the agency controls from what it does not.
• Placeholder sweep hits per build - should trend to near zero as the blueprint matures. A persistent count means a template asset is not reading from fields.
• Fleet version drift - count of live workspaces tagged template-outdated, and how long the oldest has been outstanding.
• Builds per engineer per month - the capacity number, and the one that tells you whether the agency can take on the next ten clients without hiring.

Prerequisites

• At least one workspace you are genuinely happy with, to harvest the first blueprint from. Do not design a template in the abstract; extract it from something that has worked for a real client for a few months.
• A naming convention decided and written down before the first deployment: workspaces, pipelines, stages, calendars, tags, custom fields and workflows. Renaming later is expensive because reporting and automations reference the names.
• A placeholder token convention that is mechanically searchable and could never occur in real copy. The whole sweep step depends on this.
• Version control for blueprints: a numbered version string, a changelog per version, and a hard rule that improvements go into the blueprint first. Without this rule the estate diverges again within a quarter.
• Named roles: build engineer, QA reviewer and account manager, with QA never performed by the person who built it.
• A written, agreed scope of what provisioning includes and excludes, so the intake form is not quietly used to expand the engagement.

Integrations

• Google Calendar or Outlook, authorized by the client, before calendars can be considered configured.
• Stripe or the client's chosen payment processor, authorized by the client under their own account. Never collect processor credentials; have the client authorize a connection.
• Ad platform and analytics connections where in scope, authorized by the client to their own properties.
• Slack for internal provisioning notifications and blocker escalations.
• Zapier or Make only where a required connection has no native path, each one documented against the client record so a future engineer knows it exists.
• A DNS registrar the client can act in, or delegated access. Domain authentication stalls more often on registrar access than on anything technical.

Number provisioning and messaging compliance

• Submit A2P 10DLC brand and campaign registration under the client_legal_name, with their own EIN and business details, at the Numbers and Domains Pending stage. Do not send SMS from the workspace until a2p_campaign_status reads Approved. Build the hold into the workflow rather than trusting discipline.
• Expect rejections. Keep a documented remediation path for each common rejection reason, and treat blocked-a2p as a normal stage, not an incident.
• Test forwarding with a real inbound call to client_tracking_number before QA can pass. A forwarding misconfiguration is invisible until a real patient calls.
• Every messaging workflow in the blueprint must ship with opt-out handling - STOP, UNSTOP and HELP honoured on the number - and with quiet hours bound to client_timezone and client_business_hours_open and client_business_hours_close, never to agency time. This was the failed QA check in the walkthrough for a reason; it is the most common defect in templated builds.
• Consent language belongs on the client's own forms and landing pages, in the client's name, captured at the point of collection and stored with a timestamp.

Compliance and data protection

• Decide and document who has access to each client workspace, and remove agency users who no longer need it. Templated provisioning makes it easy to leave a standing user on twenty accounts.
• Credentials issued at handover should be the client's own named accounts, never shared logins. Shared logins defeat any audit trail the agency might later need.
• Where a client workspace will hold health, financial or other regulated data, the blueprint for that industry needs its own handling rules - retention, access, and what may appear in messaging - settled before the first deployment, not per build.
• The agency is normally processing personal data on the client's behalf, which usually requires a written processing agreement, a named retention period and a defined deletion process for when the engagement ends. Build the offboarding deletion step now, while you are writing the provisioning one.
• None of this is legal advice. Have the client's own counsel confirm processing terms, consent wording and retention obligations for their jurisdiction and sector, and have the agency's counsel review the standard provisioning scope.

Scope and build effort depend on how many industry blueprints are in play and how much of the existing estate needs reconciling. To scope it for a specific agency, book a call at bookings.appbo.io.