Why an open source helpdesk for the public sector needs a different design
A public body replacing a citizen service desk, or launching one for the first time, usually asks one question early: can we host this on our own infrastructure? The answer is often yes, but a helpdesk for citizens is not a commercial support desk with a different logo. Intake is multi-channel by necessity, with email, web forms, phone transcripts and sometimes postal correspondence arriving for the same matter. Records must be kept under a retention schedule that the body sets, not the vendor. The customer portal must meet accessibility obligations, and tickets must move between departments without losing the citizen's history. Finally, data location and administrative control are often written into the mandate itself. Each of these changes the design before any software is chosen.
On platforms, Zammad is the default candidate for multi-department intake, because it has role-based groups, configurable workflows and a dedicated application license under AGPL-3.0 that a public body can review in full. Zammad's GitHub repository is the natural starting point for that review. FreeScout and osTicket are lighter options for a single department with a shared inbox and a small number of agents, but they need closer checks on routing depth, audit output and retention controls before a multi-department rollout. The choice depends on confirmed requirements: the number of departments, the channels that legally must be supported, the retention periods that apply to each record type, and whether the body must show a specific accessibility conformance level. Confirm those first, then select the platform.
Compliance is where expectations need to be set carefully. Frameworks such as the ADA Title II web accessibility rule, NIST SP 800-53 control baselines and the FBI CJIS Security Policy each describe controls a public body may need to show, but meeting them is a property of the whole system, including hosting, identity, logging and operating procedures. DeployOpen plans, implements and hardens the helpdesk and prepares the evidence an assessor will ask for, such as configuration records, access reviews and test results. DeployOpen does not issue audit reports, attestations or certifications. Independent assessors and the relevant authorities make those determinations, so the body should agree its assessment path before the design is frozen.
Which public sector requirements shape the helpdesk build
This table maps each public sector requirement to the part of the helpdesk build it affects and the items to confirm with your legal, records and security owners. Read each row as a question to answer before design starts, not as a finished compliance position. The main takeaway is that accessibility, encryption and records retention apply to the helpdesk itself, so they belong in the scope agreed before implementation.
| Requirement | What it means for the build | What to confirm with your legal or records office |
|---|---|---|
| ADA Title II web accessibility (28 CFR 35.200) | Citizen portals, forms and any mobile apps provided through contracts must meet WCAG 2.1 Level A and AA. Plan conformance testing of the portal and ticket forms, and include the vendor theme and any custom widgets in that test. | Whether your entity serves 50,000 or more people, which sets the 26 April 2027 date, or falls under the 26 April 2028 date for smaller entities and special districts. Who signs off on conformance evidence. |
| CJIS Security Policy v6.1 (encryption and scanning) | If criminal justice information appears in tickets or attachments, encryption in transit and at rest outside physically secure locations is expected. Version 6.1 calls for FIPS 140-3 validated modules or AES with 256-bit keys, and vulnerability scanning at least monthly. Consider whether CJI should be kept out of ticket bodies entirely. | Whether any queue will carry CJI, and whether your agency or state CJIS Systems Officer applies the policy to this system. Which FIPS-validated modules your hosting and TLS stack use. |
| NIST SP 800-53 baselines (low 149, moderate 287, high 370) | For federal or federally aligned systems, the baseline sets the control set the helpdesk must meet. Map the helpdesk to the chosen baseline in the system security plan, covering access control, audit logging, and boundary protection for the hosting network. | Which baseline (low, moderate or high) the authorizing official has assigned, and whether the helpdesk is in the authorization boundary or inherits controls from a larger system. |
| NIS2 scope for public administration (EU) | Central government entities fall in scope regardless of size, and Member States may extend the scope to local public administration. Incident reporting and supply chain security then apply to the helpdesk and its hosting, so plan logging and incident handling accordingly. | Whether your entity is covered by national NIS2 transposition, and whether a security or law enforcement exemption applies to any queue. Which national authority receives incident notifications. |
| Records retention and audit expectations | Citizen correspondence may be a public record with a defined retention period. Set retention and deletion rules per queue, keep audit logs of agent access to sensitive tickets, and store log retention outside the helpdesk where records policy requires it. | Retention schedule for each ticket type, legal hold procedures, and whether deletion of personal data must be reconciled with records rules. Which audit log fields the records office and internal audit require. |
| Sovereign hosting and network placement | Public sector deployments often need hosting inside national or agency-controlled infrastructure. Decide where the Zammad application, PostgreSQL, Redis, Elasticsearch and attachment storage run, and how the portal is published to the internet. | Which data residency rules apply, whether an approved hosting provider list exists, and whether the portal must sit behind a specific gateway or reverse proxy under agency policy. |
What citizen data flows through the desk and where it must stay
A citizen service desk holds more than the request itself. Each ticket carries identity details such as name, address, date of birth and contact points, plus case narratives written by agents, attachments such as permits, benefit forms and identity documents, and the metadata that shows who handled what and when. Some desks also receive criminal justice or health information by mistake, when a resident emails a court letter or a medical certificate to a general inbox. Plan for that data from day one, because the desk will store it whether or not the intake form asked for it. Web forms, email, phone transcripts and chat all feed one ticket store in Zammad, so the hosting decision applies to every channel, not only the portal. The database is PostgreSQL 15 or newer, Redis 7 or newer handles realtime websocket traffic, and Elasticsearch is optional but strongly recommended for search, reporting and searching the content of email attachments. Each of these components holds a copy of citizen data in some form. Attachment storage, the search index and backups each need a written location decision, and the search index in particular is easy to overlook because it duplicates text that was supposed to stay in the database.
Confirm the location of each component with the agency's data protection or records team before the build starts: the application server, PostgreSQL, Redis, any Elasticsearch cluster, the file store for attachments, and the backup target including off-site copies. Ask whether the operating team, support vendor or a managed host can reach those systems from outside the jurisdiction, and whether logs contain ticket bodies. Zammad's own software requirements list these dependencies and should be used as the baseline for the diagram. If a sensitive category of data arrives through an intake channel, decide in advance whether the desk will redact, quarantine or route it to a restricted queue. The right answer depends on the legal basis for holding that data, which the agency must confirm with its own counsel. Document the decision, because it determines which queues, attachment stores and search indexes may contain that content.
Which open-source helpdesk platforms fit public service desks and why
Public service desks differ in how many departments share intake, how strictly queues must be separated, and how much public-facing accessibility work sits on the portal. The cards below match each platform to a desk shape and name the checks to run before choosing one.
Zammad for multi-department routing
Zammad is the default candidate when one intake point must route citizen requests to several departments with separate SLAs and agent roles. It is licensed under AGPL-3.0, and security release 7.2.2 was published on 8 October 2026, so confirm the patch cadence you will follow in your own change process. Ask the implementer to demonstrate group-based routing, role separation and SAML or OpenID Connect login against your identity provider. Confirm how far department routing rules can be nested before you rely on them.
Zammad migration and import paths
Public bodies often move off a legacy case tool rather than starting empty, so import coverage matters. Zammad ships migrators for Freshdesk, Kayako, OTRS and Zendesk, and other systems can be brought in through its API or custom development. Ask for a field-level mapping of closed cases, attachments and retention metadata before committing. Treat any migrator as a starting point to validate against sample records, not a complete transfer.
FreeScout for single-department desks
FreeScout is a lighter AGPL-3.0 helpdesk suited to one department, such as a licensing office or a permits inbox, that needs a shared mailbox with ticket tracking. Its latest listed release, 1.8.248, was published on 17 October 2026. Check whether its routing, reporting and role model cover your required separation of duties, because a single desk with several sensitive queues may outgrow it. Confirm which accessibility fixes you will need to make on any customer-facing form yourself.
osTicket for small public offices
osTicket is licensed under GPL-2.0, and v1.18.4 was published on 17 June 2026. It fits a small office that needs web and email intake with basic ticket handling and little configuration. Its department and workflow depth is narrower than Zammad's, so test escalation rules and audit reporting against your records policy. Ask whether your implementer will support osTicket under a fixed scope, since vendor support options differ from Zammad's paid subscription tiers.
Customer portal accessibility conformance
Public service portals fall under the ADA Title II web rule, which requires state and local government web content to meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts. None of the helpdesk platforms should be assumed compliant by default. Your team must test the portal, forms and ticket notifications with assistive technology and record the results. Do not accept a vendor conformance statement without your own test evidence.
Vendor support scope and patch ownership
Self-hosted Zammad carries no license fee, but Zammad sells paid self-hosted support subscriptions with stated annual prices. Ask each candidate what its support plan covers, including the application, the database and cache layers, and the Kubernetes or container platform underneath. Confirm who applies security releases, how quickly, and who tests them in your environment. Write the answer into the scope before the platform is built.
How sovereign hosting changes the deployment pattern
Hosting Zammad in the public body's own data center gives the most direct control over where citizen data lives. The body's IT team, or a partner working inside its network, operates the application servers, PostgreSQL 15 or newer, Redis 7 or newer and the reverse proxy, and the body holds the keys to storage and backups. Attachments, ticket history and application logs stay on storage the body controls, which simplifies answers to questions about residency and access.
- Operations ownership: The body staffs patching, backup restores and on-call duties, or contracts them to a partner with access limited to its environment.
- Attachments and logs: Attachments, database content and logs remain on local storage, so retention and deletion follow the body's own records schedule.
- Security releases: Releases such as 7.2.1 and 7.2.2 are staged in a test copy first, then applied in a change window on the production servers.
- Compliance boundary: Because the body runs the service itself, its own control framework and audit scope apply directly, with no cloud provider in the chain.
- Federal-adjacent bodies: If the desk handles federal information on behalf of an agency, confirm whether the service is a cloud offering in FedRAMP scope before assuming the on-premises route avoids it.
Confirm with your legal team which records schedule and residency rules apply to citizen tickets before choosing this pattern.
A sovereign cloud keeps the platform in a provider environment located within the national or EU jurisdiction, with operational access restricted to approved personnel in that jurisdiction. The body or its partner still configures Zammad, but the provider supplies compute, storage and network. Responsibility for patching the underlying infrastructure is shared, so the contract must state exactly who applies operating system and database updates.
- Operations ownership: The body or partner runs the Zammad application, while the provider runs the infrastructure under a contract that names the operating roles.
- Attachments and logs: Storage, snapshots and backups must be placed in the approved region, and log shipping to any monitoring service must follow the same boundary.
- Security releases: The partner applies application updates such as 7.2.2 through the same staged process, and the provider confirms when it patches hosts beneath it.
- Compliance boundary: Ask the provider which certifications and assessments cover its service, and confirm they match the controls the body must evidence.
- Federal-adjacent bodies: A cloud service offered to agencies, or one that processes federal information on their behalf, can fall within FedRAMP scope. A single agency's own operations on cloud infrastructure may fall outside it. Confirm this with the agency and the provider in writing.
Ask the provider for its data location commitments, its support staffing model and the exact list of locations where administrators can access the environment.
Sensitive case types, such as child protection, law enforcement referrals or classified-adjacent services, may need a helpdesk on a network with no route to the internet. In this pattern, every container image, package, documentation set and security release must be brought in through a controlled transfer process, and the desk must run without calls to external services. Elasticsearch and Memcached, which Zammad uses in multi-instance setups, must be deployed from the same internal sources.
- Operations ownership: A cleared or approved team inside the restricted zone runs the platform, with a partner working on site or through an accredited transfer path.
- Attachments and logs: All data stays inside the enclave, and log export to a central security tool requires an approved one-way channel.
- Security releases: Each release, including 6.5.5 for the 6.5 line and 7.2.2 for the 7.x line, is verified, scanned and imported through a documented media or diode process, with the import recorded.
- Compliance boundary: The enclave becomes its own assessment scope, so access control, audit records and change logs must be designed for that boundary.
- Federal-adjacent bodies: Controlled unclassified information on non-federal systems points to NIST SP 800-171 requirements, and criminal justice information points to the CJIS Security Policy, which now requires FIPS 140-3 modules for CJI at rest and in transit outside physically secure locations.
Confirm with your security authority which sensitive case types need the enclave and how long an emergency patch may take to reach it.
How a public sector helpdesk rollout moves from requirements to go-live
This sequence turns a citizen service desk idea into a documented, tested Zammad deployment that records, routes and answers public requests under the organization's own legal, accessibility and hosting controls. Each phase ends with a signed artifact so the next phase starts from agreed ground.
Confirm legal scope and data categories
Records officers, privacy officers and the business owner of each service agree which request types, channels and data categories the desk will hold, including special categories and attachments. DeployOpen documents these in a written scope with a records retention schedule that names how long each case type is kept and who approves disposal. The step closes when the signed scope and retention schedule are filed with the project and the open questions list is empty or assigned to an owner.
Baseline accessibility and map portal flows
The team inventories every public-facing form, status page and login step the citizen portal will expose, then tests the current or prototype flows against WCAG 2.1 Level A and AA. Findings are logged with the affected screen, the criterion and a proposed fix, and the portal template or theme is adjusted before build sign-off. The output is a baseline accessibility report and a flow map that the accessibility lead has reviewed.
Design routing across departments and queues
Service owners from each department define the queues, groups, categories and escalation paths that intake will feed, including which requests cross departments and who owns the handoff. DeployOpen maps these into Zammad groups, roles and triggers, and confirms which agents can see which cases so that personal data is limited to the team that needs it. The step ends with an approved routing matrix and a role permission table signed by each department lead.
Build the hosting stack with encryption and logging
The team deploys Zammad inside the agency's own or sovereign infrastructure with PostgreSQL, Redis, a reverse proxy and, where search and attachment content matter, Elasticsearch, as documented in the Zammad software requirements. Transport and storage encryption, key management, administrator access and audit logging are configured and written into the system security plan. The step is complete when the build matches the approved architecture and the hardening checklist has been run with recorded results.
Migrate or import existing cases and articles
Existing case history, contacts and knowledge articles are extracted from the legacy tool, mapped to Zammad objects and loaded first into a staging environment. Attachments and personal data are checked against the retention schedule so that records past their period are not carried forward. The step closes with a reconciliation report comparing record counts, sample case fidelity and any items deliberately excluded, approved by the records officer.
Run accessibility, security and restore tests
Testers repeat the accessibility checks on the production-like portal, run application and infrastructure security tests, and perform a timed restore of the database and attachment store to confirm backups are usable. Each failed item is fixed and retested, and access logging is checked to confirm it records the activity the audit controls require. The output is a test report set covering accessibility, security and restore, with a sign-off from the security owner.
Train agents and publish the knowledge base
Agents and team leads are trained on their queues, escalation paths and the data handling rules set in the scope, using the staging environment. Knowledge base articles for the most common citizen questions are reviewed for plain language and accessibility, then published to the portal. The step ends when each agent has completed the training record and the published article list has an owner for updates.
Hand over runbooks and the update procedure
DeployOpen delivers runbooks for daily operations, incident response, backup and restore, and the security update procedure for Zammad releases, including how the operator tracks security releases on the 6.5 and 7.x lines. The agency's operations team runs a supervised change to confirm the procedure works before go-live is declared. Go-live is closed with signed handover documents, a list of named owners and the first scheduled review of the scope and retention schedule.
Which evidence public sector auditors and regulators ask the helpdesk to produce
This table maps each evidence item that public sector assessors commonly request from a citizen service desk to the component that produces it and the control family it supports. Read it as a preparation list: DeployOpen prepares the records and configurations, while independent auditors and assessors decide whether the controls meet the applicable standard.
| Evidence item | Produced by | What the reader should confirm |
|---|---|---|
| Accessibility test results for the citizen portal | Portal test reports from the chosen test tooling, plus remediation tickets tracked in the helpdesk or project tool | Which WCAG 2.1 Level A and AA criteria were tested, and whether results cover the portal and any mobile app |
| Role-based access configuration and access review records | Zammad role, group and permission settings, exported and versioned, plus periodic review sign-offs | Which agent roles can see restricted queues, such as benefits or case files, and who approves changes |
| Audit logs of administrative and data access activity | Zammad activity and history records, forwarded to a central log store outside the application | Retention period for logs, who can read them, and whether tamper protection is required by the assessor |
| Encryption configuration for data in transit and at rest | TLS settings on the reverse proxy (Nginx or Apache), database and storage encryption settings, and key management records | Whether CJI or other regulated data is in scope, and whether modules must be FIPS 140-3 validated |
| Vulnerability scan records | Scanner reports for the application, operating system and containers, with remediation tracking | Scan frequency required by the applicable baseline, which is at least monthly where CJI is in scope |
| Security update records | Change records showing when vendor security releases were applied to the helpdesk and its dependencies | Patch window expectations in your contracts and how emergency updates are approved |
| Backup and restore test records | Backup job logs for PostgreSQL and attachment storage, and dated restore test results | Recovery objectives set by the business, and who signs off a successful restore test |
| Retention settings and configuration history | Retention rules in the helpdesk, with version-controlled configuration history and change approvals | Which record classes apply to public records law, and how deletion requests are documented |
| Assessor responsibilities | Evidence packs prepared by DeployOpen from the components above | Independent auditors and certification bodies issue any opinion or certification, not DeployOpen |
What to ask an implementation partner before a public body signs
Start with accessibility, because the deadline is fixed. Ask how the partner scopes WCAG 2.1 Level A and AA testing for the citizen portal, which pages and flows are in the test set, which tools and manual checks are used, and who signs off the result. The ADA Title II rule applies WCAG 2.1 A and AA to state and local government web content, including content provided through contracts, from 26 April 2027 for entities serving 50,000 or more people and from 26 April 2028 for smaller entities and special districts. Ask for the written sign-off role on the partner side and on your side, and confirm whether retesting is included after each Zammad upgrade or theme change.
Next, ask how the partner handles criminal justice information or other sensitive data that citizens may type into tickets. Ask which fields and attachments are excluded from intake, whether Elasticsearch indexing of attachment content is enabled, and how storage encryption is set up. If any ticket data falls under the FBI CJIS Security Policy, the requirement in version 6.1 for FIPS 140-3 validated modules or FIPS 197 AES with 256-bit keys is a design input, so confirm with your CJIS officer and the partner which modules and key lengths are in use. Also ask which hosting locations and operators the partner supports, whether that includes closed networks, and how an operator's access to your database is logged and limited.
Then cover operations and exit. Ask how security releases are applied in a closed network, who receives the advisories, how the partner tests a patch before it reaches production, and how long a rollback takes. Ask how the existing citizen desk is migrated: whether tickets, attachments, timestamps, merge history and audit trails are carried over, how the partner verifies record counts, and how original records are kept during cutover. For Kubernetes, confirm in writing that support covers the Zammad application and not cluster issues, and agree who owns the cluster. Finally, require a fixed-scope statement of work with written deliverables, and ask how data is returned at exit: export formats, attachment handling, deletion certificates, and a tested restore into a new environment.
What public bodies ask before building an open source helpdesk
What drives the cost of a self-hosted public sector helpdesk?
The software license is not the main cost driver: self-hosted Zammad has no license fee. Costs come from hosting in your own or sovereign infrastructure, migration of existing tickets and attachments, integrations with case management, identity and telephony systems, accessibility testing of the citizen portal, and an optional support tier. The published Zammad support subscriptions are Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to the Zammad pricing page. Ask any quote to split one-time work (design, migration, testing) from recurring work (hosting, patching, support, testing after upgrades), and to state who holds the support contract.
How long does a public helpdesk rollout take?
Duration depends on the number of channels, the number of departments routed through the desk, the volume and format of legacy data to migrate, and how many systems must integrate with it. Procurement and legal sign-off often take longer than the technical build, so agencies should plan those phases first. Ask the implementation partner for a written schedule with milestones for hosting, migration trials, integration tests, accessibility review and staff training, and confirm which of those depend on your own approvals. No standard duration applies across bodies, so treat any generic figure with caution.
What must a public body provide before an implementation starts?
The body needs to supply four things before work starts:
- A legal opinion on the lawful basis for processing citizen data and on records retention periods that apply to correspondence.
- A data inventory listing the channels, queues, attachment types and systems that hold citizen records.
- Named staff for testing, including agents who can check routing rules and accessibility reviewers who can test the portal with assistive technology.
- A decision-maker who signs off the scope, hosting location and support model in writing.
Without these inputs, a fixed-scope quote cannot be accurate.
Can an in-house IT team run a self-hosted helpdesk itself?
Many teams can run it, provided they have skills in Linux administration, PostgreSQL, Redis and a reverse proxy, and a plan for patching. Zammad's documentation lists PostgreSQL 15 or newer, Redis 7 or newer, and Nginx or Apache as required components, with Elasticsearch optional but strongly recommended for search. Zammad's security releases in 2026 came out on separate lines (7.2.1 and 7.2.2 on the 7.x line, and 6.5.5 on the 6.5 line), so an operator needs a routine to apply them quickly. Be explicit about who answers the vendor support queue, and who is on call when a security update must be applied.
Do accessibility deadlines require the citizen portal to change first?
Yes, the portal is usually the first item to review. The ADA Title II rule in 28 CFR 35.200 requires state and local government web content and mobile apps, including those provided through contracts or licenses, to meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts. Helpdesk portals often include forms, file upload and status pages that fail keyboard or screen reader tests. Plan an accessibility audit of the portal as part of the build, and confirm with counsel which deadline applies to your entity.
How does DeployOpen scope a fixed-scope public helpdesk quote?
DeployOpen works from a written scope agreed before any work starts. The scope usually covers the hosting target in your own infrastructure, the channels to connect, the departments and queues to route, the migration sources, the integrations, the accessibility and security testing to run, the documentation and training, and the support or upgrade retainer if one is wanted. DeployOpen does not publish a price list, so the quote follows directly from that written scope. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications, which independent auditors and certification bodies provide.
Which compliance frameworks shape a public helpdesk design?
The applicable frameworks depend on the body and its data. For US federal work, NIST SP 800-53 Rev. 5 control baselines apply, and the FedRAMP scope covers cloud services that handle federal information on behalf of an agency. For criminal justice data, the FBI CJIS Security Policy version 6.1 took effect on 26 June 2026 and requires FIPS 140-3 validated modules or FIPS 197 AES with 256-bit keys in certain cases. In the EU, NIS2 treats public administration as a high-criticality sector, although Member States decide how far it reaches local bodies. Confirm with your legal and security leads which of these apply before choosing a hosting model.
How DeployOpen scopes and supports a public sector helpdesk
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up and supports self-hosted open-source platforms inside your own infrastructure, whether that is a government cloud tenancy, a data center you operate or an air-gapped network. For a citizen service desk, that means the helpdesk, its database, search index, cache and reverse proxy run where your data residency and sovereignty rules require them to run. The first decision is therefore where the helpdesk lives and who holds administrative access to each layer, and DeployOpen scopes that before any installation begins. Most engagements are fixed-scope, with the systems in scope, the channels connected, the migration volumes, the deliverables and the timeline agreed in writing before work starts. Ask for the written scope to name each channel (web form, email, phone integration, portal) and each department queue, because those define the integration and testing effort.
Security work on a public-facing intake is scoped separately from the platform build. DeployOpen runs security testing of applications and APIs, including the citizen portal, the ticket API used by partner systems and the attachment upload path, and these tests should be agreed before go-live rather than after a complaint or incident. Compliance readiness is also part of the scope: DeployOpen prepares systems, configuration baselines, access reviews, logging and evidence packs that your auditors or certification bodies can examine, but it does not issue audit reports, attestations or certifications. Confirm with your assessor which framework applies, such as the accessibility, records or security obligations in your jurisdiction, before you accept a scope that claims readiness for it. After launch, ongoing support, security patching and version upgrades are available as retainers, which matter for a helpdesk where security releases are published frequently and must be applied on a schedule your change board approves.
DeployOpen does not publish a price list. A quote follows from the written scope, so the useful comparison is between proposals that state the same systems, integrations, testing depth, evidence deliverables and support hours. Ask each bidder to separate one-time work (design, migration, integration, testing, accessibility remediation and documentation) from recurring work (hosting you pay for directly, subscriptions, retainers and patching). Ask how the quote changes if the channel count, the number of departments or the data volume grows during the project. Ask which parts of the scope depend on your own teams, such as identity provider configuration, network changes or sign-off on test evidence, because those dependencies determine the real timeline. A quote that is clear on these points is one you can approve and audit later.
