◎
One resident experience
Service discovery, request submission, status updates and approved guidance in one web-first experience.
Resident experience · Service orchestration · Phased delivery
DTskill City Resident Services AI Orchestrated Solution
A reusable, configurable digital front door for municipalities across the United States and Canada. It connects residents with services while departments retain their existing systems, policies and workflows.
5 releasesDiscovery through multi-service scale
$69K–$109.25KIndicative discovery + pilot
12 weeksIndicative R0 + R1 timeline
Local service channelsConnect the existing service platform
What to validate together
Confirm first resident journeys and the conditions for a safe pilot.
⇄
Connect existing systems
An orchestration and integration layer connects departmental services where approved interfaces exist.
↗
Scale with evidence
Begin with a measurable pilot across priority services, then expand when services and governance are ready.
Discussion framing: One resident experience → one orchestration layer → multiple City service domains → existing systems and workflows.
Suggested meeting flow
1 · Resident journeys
Which services matter first?
2 · System access
What interfaces can be used?
3 · Pilot & investment
What is safe, measurable and fundable?
01 · Solution vision
Keep services connected to their owners.
The DTskill solution provides a digital front door and coordination layer for resident services. Departments retain their policies, records, approvals and operational workflows.
Residents · Businesses · VisitorsWeb · mobile-ready PWA · voice/chat entry points · multilingual and accessible journeys
↓
Unified Resident Services ExperienceService catalog · requests · status tracking · notifications · payment links
↓
GenE™ AI & Service OrchestrationApproved knowledge · guided intake · workflow coordination · human escalation
↓
Secure Integration & API LayerGateway · adapters · events/webhooks · scheduled exchange · audit
↓
Existing municipal services and systems311 or equivalent service requests · GIS · permits · utilities · parking · public works · other departments
Cross-cutting: privacy · security · accessibility · identity · records governance · monitoring · analytics
Examples of configurable pilot journeys
For discovery and demonstration; each municipality selects journeys based on resident needs and service ownership.
Local issue report
Capture location and optional photo, route through the municipality’s authorized service channel and track the confirmed request.
Service request status
Let residents find and follow an existing request using an approved reference and identity check.
Find a city service
Search approved services, eligibility guidance, hours, contact options and application links.
Pilot behavior: show an official reference only after the municipality’s source system confirms acceptance. Use an authorized handoff when a production API is unavailable.
02 · Technical architecture
A modular foundation that can grow.
Start with a web-first application and a small number of integration components. Expand when City interfaces and operating needs are understood.
| Layer | Proposed capability | Responsibility / initial approach |
|---|---|---|
| Experience | Responsive web app / PWA; React or Next.js | Service discovery, intake, status and preferences; web-first |
| Identity | OIDC / OAuth 2.0; guest access as permitted | Sign-in, roles, account linking and consent; guest journey first |
| API protection | Azure API Management, Kong or equivalent | Authentication, routing, throttling and policy; use City standard |
| Orchestration | GenE workflow and agent runtime | Bounded guided conversations and tool controls with human handoff |
| AI services | LLM abstraction, retrieval, guardrails | City-approved content; confirmation and audit for actions |
| Case data | Existing 311 or equivalent case platform; limited app metadata | Authoritative request records stay in source system |
| Integration | REST, webhooks, queues, scheduled connectors | Reusable adapter for the existing request/case platform; normalize vendor schemas |
| Data & search | Managed SQL, object storage, search index | Minimize retained data; City defines retention |
| Operations | OpenTelemetry, monitoring, SIEM, CI/CD | Reliability, audit, incident response and controlled releases |
Design principles
Canonical APIs
Resident experience calls stable DTskill platform contracts; adapters translate municipal vendor data models.
Human authority
AI supports guidance and intake. Official actions and sensitive decisions follow City authorization.
Resilience
Correlation IDs, idempotency, retry/backoff, timeouts, dead-letter handling and reconciliation.
03 · Integration landscape
Connect service domains in priority order.
System names, APIs and rights require confirmation with the City and vendors. Priorities below are proposed sequencing.
| Domain | Candidate integration needs | Priority | Discovery question |
|---|---|---|---|
| 311 or equivalent service-request management | Where supported: create request, retrieve status/category, attachments, routing and closure events | P0 · critical path | Read/write API, webhook, export or UI-only? |
| City website / service directory | Approved service details, links, instructions, FAQs, updates | P0 | What source is authoritative and who approves content? |
| GIS / location | Address validation, map pin, service area, location routing | P0 | Which geocoder, boundaries and asset IDs? |
| Notifications | Email/SMS/push templates, consent and delivery status | P0 | Which municipality-approved provider and consent rules? |
| Identity provider | SSO, roles, resident account linking | P1 | Existing public-service identity standard? |
| Public Works / asset system | Work orders, asset IDs, status and crew updates | P1 | Does service-request routing connect to work orders? |
| Permits / planning | Application lookup, status, checklist and document links | P1 | Which portal supports status lookup or deep links? |
| Utility billing | Account verification, balances, bills and payment handoff | P2 | Can authenticated account data be exposed safely? |
| Parking / mobility | Permits, availability and citation links | P2 | Which functions are transactional? |
| Housing / community | Program directory, eligibility guidance and appointments | P2 | What needs human eligibility review? |
| Finance / payments | Payment intent, secure redirect, reconciliation and receipt | P3 | Approved processor and procurement path? |
| Public safety information | Approved alerts and non-emergency information | P3 | Authoritative source and escalation language? |
Critical path: confirm access to the municipality’s service-request or case platform, interface rights and test environment. If 311 is not used, integrate with its equivalent. This determines whether the pilot submits directly, uses an authorized handoff or remains a simulation.
04 · API contracts & dependencies
Agree on contracts before connecting systems.
These are proposed DTskill platform endpoints, not published municipal APIs. They hide vendor-specific schemas from the resident interface.
| Proposed endpoint | Method | Purpose | Contract detail |
|---|---|---|---|
| /v1/services | GET | List services | Owner, eligibility, approved links |
| /v1/services/{id} | GET | Service details | Requirements, hours, escalation |
| /v1/requests | POST | Create request | Idempotency, location, category, consent |
| /v1/requests/{id} | GET | Read status | External reference and normalized state |
| /v1/requests/{id}/attachments | POST | Upload attachment | Limits, malware scan, retention, access |
| /v1/assistant/messages | POST | Ask service assistant | Approved knowledge, escalation, trace ID |
| /v1/locations/validate | POST | Validate location | Address, coordinate precision, jurisdiction |
| /v1/notifications/preferences | PUT | Set preferences | Consent, channel, locale and audit |
Requirements baseline
Identity & contracts
OAuth/OIDC for users; workload identity or mTLS for services. OpenAPI 3.1, JSON Schema, normalized statuses, errors and correlation IDs.
Security & records
Least privilege, encryption, sensitive-data redaction, audit, classification, retention and records rules agreed with City.
Reliability & events
Timeouts, retries, idempotency, dead-letter queues, reconciliation and lifecycle events.
Discovery dependencies
Service-request platform and vendor access
API docs, sandbox, credentials, permission and rate limits.
Service taxonomy
Categories, routing, owners, statuses and SLAs.
Privacy, security and AI
Hosting, data classification, retention and approved AI use.
GIS and infrastructure
Cloud standards, network, geocoding and service boundaries.
Knowledge and accessibility
Approved source content, owners, WCAG target and languages.
SMEs and procurement
Sponsor, reviewers, vendor permissions, UAT and contracting path.
05 · Start small and scale
Release value in controlled steps.
Indicative durations assume timely decisions and access; procurement and security reviews may change sequencing.
R0
Discovery & architecture
Workshops · integration/vendor assessment · target and security design · prioritized backlog and refined estimate
$17.25K–$28.75K4 weeks
R1
Priority service-request pilot
Resident PWA · AI receptionist · 2–3 request journeys · adapter/handoff · confirmation/status · staff dashboard and metrics
$51.75K–$80.5K8 weeks
R2
Accounts, GIS & permits
Resident account options · GIS routing · permit status/links · expanded staff roles and audit
$63.25K–$97.75K8 weeks
R3
Utilities, parking & mobility
Utility account handoff · parking services · payment assessment · mobile experience expansion
$115K–$184K16 weeks
R4
Advanced orchestration & optimization
Additional workflows · service analytics · cross-domain orchestration · multi-service governance/support
$103.5K–$172.5K16+ weeks
Scale gate: review request success, routing quality, resident feedback, staff workload, accessibility, security and integration reliability before funding the next release.
06 · Indicative DTskill proposal
Fund the next step, then decide on expansion.
Planning estimates in USD, updated by 15%, for discussion; not a formal quotation or validated municipal budget. DTskill can provide a CAD-denominated estimate for Canadian municipalities after discovery.
OPTION 1 · DISCOVERY$17.25K–$28.75K
R0 · Feasibility and architecture
OPTION 2 · PILOT$69K–$109.25K
R0 + R1 · First resident experience
OPTION 3 · EXPANSION$132.25K–$207K
R0–R2 · Multi-service foundation
OPTION 4 · MULTI-SERVICE SCALE$350.75K–$563.5K
R0–R4 · Full phased plan for the selected municipality
Interactive estimate
Select cumulative releases and contingency allowance.
ThroughR1 · Service pilot
Contingency10%
Estimated total range · USD$75.9K–$120.18K
Base services$69K–$109.25K
Allowance$6.9K–$10.93K
Monthly operating allowance, separate from implementation
| Category | Monthly USD | Notes |
|---|---|---|
| Cloud hosting, database, storage | $575–$2,300 | Environment, resilience and retention |
| LLM / GenE AI infrastructure | $345–$1,725 | Usage volume and model selection |
| Monitoring, notifications, messaging | $230–$920 | Usage, vendor rates and channel mix |
| DTskill managed support | $2,300–$5,750 | Support scope and SLA |
| Estimated recurring total | $3,450–$10,695/month | Planning allowance |
Commercial assumptions
Cost basis
Reuse GenE capabilities, web-first delivery and reasonable access to existing systems.
Excluded until scoped
Licenses, City API charges, payment processing, taxes and significant migration.
Payment milestones
20% mobilization · 20% design · 30% integration demo · 20% UAT/security · 10% go-live.
Entry offer
$69K–$109.25K for 12-week discovery + pilot, subject to access and scope validation.
07 · Decisions & next steps
Leave with a clear discovery path.
Confirm the smallest valuable pilot and the City inputs needed to scope it responsibly.
Confirm 2–3 non-emergency services, service boundaries and what a successful resident outcome means.
Identify platform/vendor, API documentation, test environment, read/write permissions, webhooks or exports, rate limits and pilot authorization.
Confirm hosting, identity, records retention, privacy, security, approved AI services, human review and accessibility.
Name the sponsor, service-platform owner, departmental SMEs, content approvers, security/privacy reviewers and UAT participants.
Confirm contracting path, target budget, decision timeline and whether R0 can be authorized separately.
Proposed next step
Run focused discovery before committing to the pilot build.
1 · Convene
Initial service owners, IT, privacy/security, accessibility and procurement.
2 · Validate
System access, resident journeys, governance and measurable acceptance criteria.
3 · Refine
DTskill submits a scoped R0 plan and an R1 decision gate with confirmed assumptions.
Recommended entry: R0 Discovery & Architecture ($17.25K–$28.75K indicative), then authorize the R1 pilot after local access, security and scope are confirmed.
DTskill City Resident Services AI Orchestrated Solution · Discussion conceptAll proposed interfaces, costs, features and timelines are subject to discovery and City approval.