From the State Government edition of September 21, 2026
South Carolina Bradley Resident AI Assistant reports 82.2% first-contact resolution on verified .gov answers
South Carolina Department of Administration / Tyler Technologies · State government — citizen digital services / shared information access · South Carolina, United States
- Publisher
- Tyler Technologies investor news — South Carolina Expands Access to Government Services with Tyler Technologies’ Resident AI Assistant
- Original publication
- 2026-06-30
- Source retrieved
- 2026-09-22
- Event date
- 2026-06-30
What happened
Why now: archive already covers Nebraska Navigator expansion but lacked South Carolina’s sibling Tyler Resident AI Assistant metrics. Tyler’s 2026-06-30 investor release, quoting SC CIO Nathan Hogue, states that Bradley—live since September 2025 and answering only from verified .gov sites—handled more than 38,000 questions from over 10,800 unique users, averaged 195 questions/day (peak 426), achieved an 82.2% first-contact resolution rate, ran 24/7 with 15% weekend interactions, and supported 54 languages (~6% non-English). Emerging/measured engagement signal for statewide citizen information bots, not an independent outcome evaluation.
Why it matters
Gives peer states concrete engagement and FCR-style metrics for a Tyler Resident AI Assistant deployment spanning DMV, courts, and tax information discovery—useful when comparing AskCA/Nebraska-style statewide navigators.
Evidence and measured results
Tyler IR/Business Wire 06/30/2026: >38,000 questions; >10,800 unique users since Sep 2025; avg 195/day peak 426; 82.2% first-contact resolution; 15% weekend; 54 languages / ~6% non-English; answers sourced from verified SC .gov websites; SC CIO Hogue quote on single trusted starting point; analytics on vehicle, legal/court, and tax intents.
Limitations and uncertainty
Vendor-published metrics; FCR definition and sampling method not disclosed; commercial interest; June date older than prefer-window—included because URL/metrics were not in archive and parallel Nebraska story should not monopolize Tyler chatbot evidence.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-09-21; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- States want statewide resident chatbots but lack peer FCR/engagement metrics beyond a few announcements.
- Stakeholders
- State CIO / digital services
- DMV and revenue content owners
- Court/public-information leads
- Procurement for citizen-experience platforms
- Discovery questions
- What is your definition of first-contact resolution for an information bot?
- Which .gov domains are allowlisted as ground truth?
- What share of interactions occur after hours or in non-English languages?
- Who owns fixing pages the bot surfaces as weak?
- Value hypothesis
- A 4–6 week content-and-telemetry readiness review can establish FCR baselines before statewide navigator expansion.
- Potential engagement
- Bounded discovery: map allowlisted corpora, define FCR/containment KPIs, and pilot analytics with two high-volume agencies.
- Unsupported claims
- Guaranteed 82.2% FCR replication
- Independent audit of Tyler’s published counts
- That information bots reduce in-person visits in every program
Pre-sales engineering
Role takeaway
- Fit
- Public multilingual RAG assistant over verified state websites with intent analytics—not case-management automation.
- Architecture and integration
- Crawl/allowlist .gov sources; serve widget on enterprise portal; log intents; escalate unresolved queries to human channels.
- Prerequisites
- Authoritative domain allowlist
- Content owners for DMV/tax/courts
- Telemetry for FCR and language mix
- Constraints
- Vendor-hosted Tyler stack
- Public-information scope only
- Opaque FCR methodology in the release
- Security
- Minimize PII in prompts/logs; review vendor data-retention and subprocessors for conversation transcripts.
- Proof of value
- Agreed FCR definition with sample audits
- Language coverage test pack
- Intent analytics driving content fixes
Delivery
Role takeaway
- Work
- Stand up allowlisted corpus, launch portal widget, train content owners, and run multilingual QA with KPI dashboards.
- Dependencies
- Portal/CMS teams
- Agency content stewards
- Tyler (or equivalent) implementation
- Privacy/legal review of logs
- Ownership
- CIO/DoA for platform; agencies for source accuracy; vendor for model/runtime SLAs.
- Skills and adoption
- Content stewards need bot-intent literacy; service desks need escalation playbooks when FCR fails.
- Governance checkpoints
- Allowlist change control
- Monthly FCR/language KPI review
- Privacy review of transcript retention
- Acceptance criteria
- Documented FCR definition and audit sample
- Published allowlist of source domains
- After-hours and multilingual test evidence
- Risks
- Stale or conflicting .gov pages
- Metric inflation without definition
- Scope creep into authenticated transactions
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Central conversational gateway retrieving exclusively from verified state web content, with multilingual front door and analytics on unmet intents—architecture favors RAG-over-.gov rather than transactional case systems.
Governance
Who approves, reviews and stays accountable for outcomes?
Statewide CIO sponsorship and verified-.gov grounding reduce hallucination surface versus open-web bots; still depends on content owners keeping agency pages accurate and on vendor transparency claims.
Security and privacy
What data, permissions and controls need testing?
Public-information scope lowers PII exposure versus authenticated case bots, but logging of resident questions and analytics retention still need privacy review; vendor-hosted assistant implies third-party data-processing terms.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
54-language support and after-hours/weekend availability can improve access for non-English and off-shift residents; does not by itself prove WCAG/accessibility conformance of the widget.
Procurement
What should contracts, pricing and exit terms secure?
Illustrates turnkey Resident AI Assistant procurement with statewide expansion after agency pilot patterns (parallel to Nebraska); buyers should require FCR definitions, allowlist controls, and analytics deliverables in contracts.
Operating model
Which teams own the service once it runs?
Centralizes resident information discovery while leaving program transactions with agencies—shifts some Tier-0 load but creates ongoing content-stewardship operating costs.
Publication history
- 2026-09-21State Government · Issue 164 resources
Stable resource ID: south-carolina-bradley-resident-ai-assistant-20260630