Opening: what we'll map together

• To start, which citizen transaction should we focus on for this discovery? Options: Benefits application, Renewal or recertification, Claim status lookup, Appointment scheduling, Other (describe in next question)
• Estimate the monthly volume of that transaction for your program Options: Under 1,000, 1,000 to 10,000, 10,000 to 50,000, 50,000 to 200,000, Over 200,000
• Which channels do constituents currently use to start or complete this transaction? Options: In person or counter, Phone call to call center, Paper form mailed in, Existing web portal, Mobile web or app, Assisted by caseworker
• State whether you can commit a named SME and approximately 4 hours per week for a focused 3-week discovery sprint Options: Yes, we can name an SME immediately, Yes, but only after X weeks (explain in next question), No, we cannot commit that level of time
• Share a recent example of a citizen who abandoned this transaction, and what the immediate cause looked like

Where citizens actually drop off

• Point to the single step in your citizen flow that, if fixed, would lift completion rates the most Options: Initial intake or eligibility screening, Identity verification step, Form fields that require documents, Payment or fee processing, Post-submission acknowledgement or next steps
• Estimate the percentage of users who abandon before completion today Options: Under 10%, 10% to 25%, 25% to 50%, 50% to 75%, Over 75%
• Which artifacts in the flow create the most errors or rework—structured forms, uploaded PDFs, paper attachments, or manual data entry points? Options: Structured online form fields, Uploaded PDFs or scanned documents, Paper attachments submitted separately, Manual data entry by staff, Automated data imports
• Walk me through a recent case where a user abandoned mid-process, starting from how they arrived at the flow to the moment they left
• Would a sustained completion rate below 50% for the pilot be a deal blocker for your team? Options: Yes, No, Depends on the cause (explain)

Legacy constraints that decide what is possible

• Point out the legacy component—system, data store, or policy—that most limits your ability to modernize the citizen experience Options: Mainframe transaction system, Proprietary database without APIs, Manual paper workflow governed by policy, Third-party vendor system with restricted access, Other (describe)
• Describe the interfaces your legacy systems expose today, for example REST, batch files, screen scraping, or none Options: REST APIs, SOAP or RPC services, Scheduled batch exports, Direct database access only, Screen scraping or UI-only interfaces, No programmatic interfaces
• List the backend owners and the office that controls system access or change requests for those systems
• Who holds the authority in your organization to approve changes that touch those legacy systems? Options: Technical operations or platform team, Program manager or product owner, Security or information assurance office, Procurement or vendor management, Other
• State whether lack of API access within 6 weeks would pause a pilot Options: Yes, we would pause, No, we would continue with a workaround, Maybe, depending on the workaround and risk

Who signs off when things go wrong

• Name the three offices or roles whose approval is required to move a pilot into production
• Identify typical approval timelines for security, legal, and procurement reviews in your environment Options: Under 2 weeks, 2 to 4 weeks, 4 to 8 weeks, 8 to 12 weeks, Longer than 12 weeks
• When a security or privacy issue is identified during a pilot, who is the escalation point and what is the target response time?
• Select the statements that describe how change control is enforced for production-impacting work Options: Formal CAB approval required, Rolling change windows with testing, Ad hoc approvals per change, Emergency change process exists
• Could a required change control window longer than 30 days block your go-live decision? Options: Yes, No, Only if it impacts a critical path

Real measures of success oversight will ask about

• Direct us to the single measurable outcome your oversight bodies will use to judge success or failure Options: Application completion rate, Average time to decision, Constituent satisfaction score, Processing backlogs reduced, Accessibility compliance score
• Report your current baseline for application completion rate and any recent trend data
• Select which oversight metrics you are already required to report Options: Completion rate, Time to decision, Error or rework rate, Customer satisfaction (CSAT) or similar, Accessibility metrics, Not currently required
• How quickly do you need to demonstrate improvement to satisfy oversight: 3 months, 6 months, 12 months, or longer? Options: 3 months, 6 months, 12 months, Longer than 12 months
• Would you proceed if you cannot commit to a measurable improvement within your target window? Options: Yes, with mitigations, No, we would pause, We would re-scope the pilot

Where this can fail fast

• What specific failure mode in a pilot would make you stop the program immediately
• Rate your confidence in the quality and completeness of the data that will feed the transaction Options: Very confident, Somewhat confident, Unsure, Not confident
• Choose the statements that describe your identity verification posture for this service Options: Existing federal identity provider integration available, Third-party identity vendor in use, Identity currently manual or paper-based, No identity process defined
• Share an example of a past rollout that required rollback and what that cost your program in time or budget
• Are there any non-negotiable regulatory or policy gates that would terminate the project if not cleared? Options: Yes (describe in next question), No, Unsure

The alternatives you are weighing

• Who or what are you actively considering instead of engaging an outside modernization partner? Options: Incumbent contractor, Internal build by agency staff, Another vendor on schedule, No alternative identified yet
• Pick from the following options you have evaluated or are still considering Options: Keep current paper/phone process, Internal modernization using existing staff, Procure a different external vendor, Extend incumbent contract, Other
• Describe what would have to be true about your current approach for you to remain with it rather than change
• Has anyone inside your agency proposed solving this without an outside vendor or partner? Options: Yes, a formal proposal exists, Yes, informal proposal or advocacy, No one has proposed internal-only
• If your incumbent could deliver a six-month pilot with a clear ATO pathway, would you stay with them? Options: Yes, No, Depends on cost and performance guarantees

Readiness facts that gate configuration and deployment

• Identify the readiness gap that would prevent configuration work from starting on schedule Options: No API access, No named data owner, Environments not provisioned, Security or legal holds, Staffing gaps
• List the external systems that must integrate before you can run an end-to-end test
• Choose which environments are available today: development, staging, performance test, and production Options: Development, Staging, Performance test, Production
• Confirm whether APIs exist for each required integration and name the owner who can grant access
• Could configuration proceed if only representative test data is available and not production data? Options: Yes, with data masking, Yes, but risk to validation, No, production data required

Next steps and decision drivers

• Assuming the pilot delivers the target improvement you seek, what would need to happen for you to authorize work the same week?
• Pick which acceptance criteria must be met before you will greenlight a phased rollout Options: Functioning end-to-end flow for target cohort, Accessibility and multilingual compliance passed, Identity integration validated, Security assessment passed or plan in place, Performance targets met
• Point out the commercial or compliance approvals that typically add the most calendar time before work can begin
• How soon could you name project owners and commit a cutover window: immediately, within 4 weeks, within 8 weeks, or later? Options: Immediately, Within 4 weeks, Within 8 weeks, Longer than 8 weeks
• Name the risks that, if unresolved, would cause you to revisit budget or timeline immediately

• Solution Experience Session

• Confirm the current state and its cost to your team
• You confirm that the demonstrated flow eliminates the manual reconciliation and reduces abandonment for the representative scenario.
• Provide a mapping report that ties the validated walkthrough to proposed acceptance criteria, including completion-rate targets and accessibility thresholds.
• You agree on measurable acceptance criteria, including target completion rate, identity success thresholds, and accessibility pass criteria, for the phased rollout.
• Walk an end-to-end citizen scenario
• Provide a list of required data endpoints and sample payloads needed to build the integration.
• You identify remaining technical or compliance risks that must be resolved before work begins.
• Demonstrate how manual handoffs are removed
• Identify the 2-3 representative citizen scenarios to use in the MVP test.
• Confirm identity, accessibility, and hosting acceptance criteria
• Schedule a technical working session to finalize identity and hosting integration options within seven days.
• Validate this maps to your needs

• Solution Experience Session
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• Build Responsive Citizen Web Application
• Develop Mobile Application (iOS and Android)
• Implement End-to-End Transaction Workflows
• Integrate Legacy Backend Systems via APIs
• Integrate Identity Verification and Login.gov
• Implement Section 508 Accessibility Compliance
• Enable Multilingual Content and Localization
• Provision FedRAMP-Authorized Cloud Hosting
• Deploy Secure CI/CD and Release Pipeline
• Migrate Citizen Records and Form Data
• Build Operational Dashboards and Real-Time Metrics
• Implement Secure API Gateway and Data Exchange

Build Responsive Citizen Web Application

• Identify the existing public-facing forms (by form name or document ID) that must be replicated in the responsive web application (for example paper form, PDF form ID).
• Specify the minimum browser and mobile OS versions you must support for the public web interface (for example iOS 13, Android 9). Options: Desktop browsers only, Mobile-first: smartphones, Responsive for desktop and mobile, Other
• Estimate peak concurrent user sessions expected for benefit intake or filing windows (for example 5,000 concurrent users). Options: Less than 100, 100-1,000, 1,000-10,000, More than 10,000
• Which authentication flows used by your agency must the web app support (for example SAML assertions, OpenID Connect tokens, Personal Identity Verification / Common Access Card). Options: SAML 2.0, OpenID Connect (OIDC), PIV/CAC (Personal Identity Verification / Common Access Card), Anonymous/public access
• Who on your team will be the content owner responsible for approving public form content and notices (name and role)?
• When do you require the first production-ready public form to be published (month/year)?

Develop Mobile Application (iOS and Android)

• Where will you distribute the mobile app for citizens: public app stores, agency enterprise store/MDM, or private distribution? Options: Public app stores, Enterprise app store / MDM, Private distribution, Undecided
• Confirm whether push notifications are required for status updates and which platform push services you will accept (Apple and Android platform push services). Options: Yes, platform push services, No, Only in-app polling
• Provide the list of device accessibility features that must be supported in the mobile app (for example VoiceOver, large text, high contrast).
• List required background capabilities such as offline form caching or background uploads of attachments (camera photo uploads). Options: Offline form caching, Background uploads, No background processing, Other
• Select required app entitlements and device integrations (for example camera, location, microphone) that the mobile app will request. Options: Camera, Location, Microphone, Contacts, None
• Assign the owner who will manage mobile build submissions and app store approval tasks (name and role).

Implement End-to-End Transaction Workflows

• Outline the citizen transaction you want digitized end-to-end (for example apply for benefit X, renew credential Y) and include the public form or workflow name.
• Describe the business rules or conditional branching tied to specific form fields (for example require document upload when claim type = A).
• State the target service level for transaction processing after submission to your backend (for example decision within 48 hours). Options: Same day, 48 hours, 5 business days, Custom
• Enter the sequence of citizen notifications required during the transaction (acknowledgment, receipt number, status change messages).
• Indicate which uploaded attachments require content validation or virus scanning (for example PDF supporting documents, photos of ID). Options: PDF documents, Photos of ID, No attachments, Other
• Choose the rollback or remediation behavior if a backend action fails mid-transaction (for example automatic retry, queue for manual review, user-facing error). Options: Automatic retry, Queue for manual review, Show error and ask user to retry, Other

Integrate Legacy Backend Systems via APIs

• Are there existing API endpoints for core services (for example claim lookup, case status) or will you require batch adapters or screen-scraping adapters? Options: Existing REST/SOAP APIs, Batch exports only, Need custom adapter, Unknown
• Will your legacy APIs impose rate limits or require specific authentication tokens (for example client credentials)? Options: Yes - rate limits, Yes - token authentication, No limits, Unknown
• Is there a published data dictionary or canonical schema for the legacy records (table and field names that define claims, applicants, attachments)? Options: Yes - available, Partially documented, No documentation, Unknown
• Name the primary backend system types to integrate (for example mainframe batch jobs, commercial case management system, relational database). Options: Mainframe batch, Commercial off-the-shelf case system, Relational database, Other
• Detail the field mapping and transformation rules required from your legacy schema to the new platform schema (for example legacy field 'ADDR1' -> applicant.address.line1).
• Explain the expected coexistence or cutover window for backend integrations (for example parallel run of X weeks). Options: No coexistence - big bang, 1-4 weeks, 5-12 weeks, >12 weeks

Integrate Identity Verification and Login.gov

• Quantify the required Identity Assurance Level for citizen authentication (Identity Assurance Level 1 (IAL1), Identity Assurance Level 2 (IAL2), IAL2+ with PIV integration). Options: Identity Assurance Level 1 (IAL1), Identity Assurance Level 2 (IAL2), IAL2+ / PIV integration, Undecided
• Rank acceptable identity proofing methods for eligibility decisions (for example document upload with verification, knowledge-based verification, PIV/CAC). Options: Document upload with verification, Knowledge-based verification, PIV/CAC (Personal Identity Verification / Common Access Card), Federally approved identity broker
• Record any existing agency policies or Memoranda that mandate PIV/CAC or use of a federated identity broker (provide policy document name or reference).
• Submit the list of identity data elements you can share with an identity provider for verification (for example Social Security Number partial, date of birth, full name).
• Attach the consent language or privacy notice currently used for identity proofing so it can be reviewed for platform integration (file reference or description).
• Reference the SAML or OpenID Connect (OIDC) assertion endpoint paths or the integration endpoint names currently used by your identity stack.

Implement Section 508 Accessibility Compliance

• Prioritize which Section 508 techniques must be mandatory for your program (for example keyboard navigation, screen reader compatibility, color contrast ratios). Options: Keyboard navigation, Screen reader compatibility, Color contrast >=4.5:1, All of the above
• Calculate the acceptance threshold for automated accessibility checks on public forms (for example 95% automated pass rate before manual testing). Options: 90%, 95%, 100%, Custom
• Set the scope for manual accessibility testing including target assistive technologies and devices to be used for validation (for example NVDA, JAWS, VoiceOver versions, and specific mobile OS versions).
• Approve which conformance artifact will serve as final acceptance evidence: Voluntary Product Accessibility Template (VPAT), a third-party accessibility audit report, manual test logs, or a combination. Options: Voluntary Product Accessibility Template (VPAT), Third-party audit report, Manual test logs, Combination
• Coordinate who in your office will sign the accessibility acceptance package required for the ATO artifacts (name and role).
• Validate whether automated test results and manual test transcripts must be included in the final acceptance package (Yes or No). Options: Yes, No

Enable Multilingual Content and Localization

• Identify the target languages and dialects required for your constituent base (please list languages).
• Specify whether localization is required for UI strings only, help content, and/or form guidance (select all that apply). Options: UI strings, Help content, Form guidance, All of the above
• Estimate the monthly volume of multilingual submissions by language (for example 500 Spanish submissions per month). Options: Less than 100, 100-1,000, 1,000-5,000, More than 5,000
• Which translation workflow will you accept for approved strings: machine translation with human post-edit, translation memory with glossary, or human translation only? Options: Machine translation with human post-edit, Translation memory + glossary, Human translation only, Other
• Who will maintain the program-specific glossary for translation and terminology reviews (name and role)?
• When should language fallbacks be applied if a translation is missing: immediate fallback, on next release, or present user the original language? Options: Immediate fallback, Wait for next release, Notify user to switch language

Provision FedRAMP-Authorized Cloud Hosting

• Where will you target hosting with regard to FedRAMP (Federal Risk and Authorization Management Program) authorization level: FedRAMP Moderate, FedRAMP High, or agency-managed boundary? Options: FedRAMP Moderate, FedRAMP High, Agency-managed boundary, Undecided
• Confirm the ATO artifacts required by your agency for hosting authorization (for example System Security Plan, Plan of Action and Milestones, Security Assessment Report). Options: System Security Plan (SSP), Plan of Action and Milestones (POA&M), Security Assessment Report (SAR), All of the above
• Provide any data residency or regional constraints for citizen PII that will affect hosting (for example must remain within a specific region or boundary).
• List the network connectivity requirements to the agency boundary needed for the hosting solution (for example VPN, direct connect, secure web gateway). Options: VPN, Direct connect, Secure Web Gateway, Other
• Select the operational split of hosting responsibilities you expect: we handle platform operations, you manage data, or a shared responsibilities model. Options: We manage the platform, You manage the data, Shared responsibilities
• Assign the agency Authorizing Official or ATO point of contact for hosting discussions (name and role).

Deploy Secure CI/CD and Release Pipeline

• Outline the source code repositories and branch strategy you will use for CI/CD (include repository names and branch protection rules if known).
• Describe the required security scans in the CI pipeline such as static application security testing (SAST), dependency scanning, and container image scanning. Options: SAST, Dependency scanning, Container image scanning, All of the above
• State your expected production release cadence (for example weekly, biweekly, monthly). Options: Weekly, Biweekly, Monthly, Quarterly
• Enter the approval gates required before production release (for example security sign-off, ATO checklist completion).
• Indicate build artifact provenance requirements such as signed images or a Software Bill of Materials (SBOM). Options: Signed images, SBOM required, No special requirements
• Choose the rollback strategy to be implemented in the pipeline (for example blue-green, canary, immediate rollback). Options: Blue-green, Canary, Immediate rollback, Other

Migrate Citizen Records and Form Data

• Are there stable unique identifiers in your legacy records we can use for reconciliation such as Social Security Number (SSN), agency ID, or GUID? Options: Social Security Number (SSN) available, Agency ID only, No stable identifiers, Other
• Will records require PII redaction, masking, or tokenization during transit and at rest according to agency policy? Options: Yes - redact/mask, No, Partial
• Is a pilot slice of records available for migration validation (for example 1,000 records extract)? Options: Yes - pilot set available, No, Need to extract
• Name the canonical source for each record type to be migrated (for example claims table name, benefits table name).
• Detail your data accuracy acceptance criteria for migration such as percent of fields matching, deduplication targets, and acceptable error thresholds. Options: 95% field accuracy, 99% field accuracy, 100% field accuracy, Custom
• Explain retention and archival requirements for legacy documents after migration (for example retain original PDFs for X years).

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Subscription Agreement and Order Form
• Acceptance Criteria and Authorization to Proceed
• Delivery Milestones and Payment Schedule
• Change Order Agreement
• Service Level Agreement (SLA)
• Data Processing Agreement (DPA)
• Federal Security and Procurement Addendum
• Intellectual Property and Licensing Schedule
• Termination and Transition Plan
• Audit and Compliance Rights

• Go-live Health Check
• First Measurement Review
• Acceptance Gate — Outcome Decision
• Monthly Operational Check-in
• Quarterly Review — Outcomes and Satisfaction

• Triage enhancement requests so the near-term backlog is prioritized and specific.
• Restate acceptance criteria and targets
• Produce a documented acceptance decision for each Solution Scope acceptance criterion, recording pass, conditional pass, or fail.
• Confirm the incumbent system decommissioning or retention plan and evidence that data migration or archiving is complete.
• Agree remediation tasks and a timeline to resolve any conditional items, with a clear re-evaluation date if required.
• Publish the formal acceptance record stating pass/conditional/fail per Solution Scope criterion with the named signatory statement.
• Deliver an incumbent wind-down checklist that documents contract termination or retention terms, data archive verification, and user cutover closure steps.
• Create a remediation plan for any conditional or failed acceptance items with target remediation dates and evidence requirements for re-evaluation.
• Operational metrics snapshot
• Ensure application completion rate and identity verification success rate remain within acceptable variance of Solution Scope targets or have active remediation in place.
• Reduce the number of P0-P1 open incidents through agreed remediation tasks and timelines.
• Re-confirm success criteria and owners
• Publish the monthly operational dashboard with annotated changes and the list of items closed since the last meeting.
• Provide a ticket burn-down plan for all P0-P1 items with estimated resolution dates.
• Record prioritized enhancement requests with acceptance criteria and proposed delivery windows for backlog planning.
• Trend analysis against Solution Scope targets
• Confirm whether the solution is meeting longer-term targets for application completion rate and constituent satisfaction score recorded in Solution Scope.
• Identify and schedule remediation for any systemic bottlenecks that prevent meeting Solution Scope targets.
• Agree the prioritized enhancement list and monitoring adjustments for the next quarter.
• Deliver a quarterly outcomes report that maps each Solution Scope target to observed performance and recommended actions.
• Produce a prioritized implementation plan for systemic bottlenecks with proposed release windows.
• Update dashboards and alerting thresholds to reflect any monitoring cadence changes agreed in the meeting.
• Confirm the deployed configuration matches the Configuration Details entries and environments listed in Pre-Deployment Readiness.
• Identify and schedule remediation for all P0-P1 issues before the first measurement window closes.
• Agree the date and data sources for the First Measurement Review.
• Produce a short remediation plan listing each P0-P1 issue, resolution steps, and target completion dates.
• Confirm and publish the canonical data sources and dashboard queries that will feed the First Measurement Review.
• Validate that identity verification endpoints and Login.gov integration are reachable from production environments and document any intermittent errors.
• Present first measurement data
• Determine whether application completion rate and constituent satisfaction score trends are improving toward Solution Scope targets or require remediation.
• Identify the top 2 root causes for KPI gaps and agree specific corrective actions with target dates.
• Confirm readiness criteria and timeline for the Acceptance Gate meeting at day 90.
• Publish the diagnostic report showing funnel drop-off points, identity verification failure rates, and time-to-complete metrics.
• Create a remediation task list for the top 2 root causes with implementation steps and completion dates.
• Prepare the Acceptance Gate data pack that maps each Solution Scope criterion to the observed metric values and evidence sources.
• Deployment and migration validation
• High-severity incidents and ticket burn-down
• Present outcome data against each criterion
• Diagnose gaps and root causes
• Constituent feedback and qualitative insights
• Enhancement request triage
• Review identity verification success rate and time-to-complete
• Document pass, conditional pass, or fail per criterion
• Processing bottlenecks and backend integration review
• Early adoption signals and usage patterns
• Agree corrective actions and deadlines
• Formal acceptance decision and signatory capture
• Backlog health and enhancement prioritization
• Integration and backend health check
• Blockers and open issues triage
• Immediate remediation plan and timeline
• Define next steps and short-term ownership
• Quarterly commitments and monitoring cadence
• Incumbent system wind-down confirmation
• Confirm path to Acceptance Gate
• Agree remediation items and resolution timeline