Constituent services that intake, route, and resolve themselves.

The setup that makes constituent services run smoothly: the case model for government services, the citizen intake forms on your public-facing portal, program and benefit routing, eligibility and document checks, applicant notifications, and caseworker guidance.

The applications and cases themselves stay in your team's hands. Phyllis configures the engine that intakes, routes and resolves them; she doesn't manufacture the submissions.

Yes — it's grounded in how your instance is set up today. Phyllis works within your existing case process, adjusting and labelling stages where that's safely supported.

Where a change would need a developer's involvement, she flags it for you rather than quietly attempting something that could leave a dead, unreachable step.

With care by default. Government cases carry personal details that shouldn't be visible to everyone, so Phyllis reads how access is scoped today, proposes who should see what, and sets up restrictions so sensitive information reaches only the teams that need it.

She never surfaces that data casually in her own findings.

Correct. Phyllis explores, proposes a plan, and only builds once you approve. Every change is staged for review and is reversible, and she never finalises or promotes anything on her own.

Any fixes she spots afterward are held for your sign-off before they run.

Every claim is cited to your own live instance — the active case types, the intake forms on your citizen portal, the routing behind benefit applications — rather than assumed from out-of-box defaults.

That matters on migrated instances, where case models and routing drift from the shipped baseline. You see the evidence, not a guess.