Helpdesk software requirements checklist: how to use it before you choose a platform
This checklist turns the needs of a support team into testable requirements for Zammad, FreeScout or osTicket. Most teams that outgrow a shared inbox or a hosted helpdesk know what hurts today, but not yet what the replacement must do on day one and what it must still do after two years of growth. Each requirement below is written so that you can answer one question: does this platform meet it, and how do we know? Work through the requirements in the order of your own constraints, starting with channels and data retention, because those two areas often rule out a platform before feature comparisons begin.
Use the tables that follow as three columns: the requirement, why it matters to your operation, and how to verify it. Verification means a proof-of-concept run on a test instance with your own sample data, or a check against the vendor's current documentation with the release you plan to deploy. It does not mean a sales claim, a demo script or a feature list on a comparison site. Record the result of each check, the version tested and the person who ran it. A requirement that cannot be verified in your environment, such as a support plan response time or a hosting location, should be written into the RFP as a question for the partner. When a checked item depends on an add-on, a plugin or a paid subscription, mark it as such, because the cost and the support obligations change with it.
Treat the checklist as a living document. Revisit it when your channel mix changes, when a regulator or customer contract adds retention or access rules, and before each security release is applied, since Zammad, FreeScout and osTicket all publish fixes on their own schedules. Keep the completed checklist with your architecture record. It becomes the evidence that the platform was selected against stated requirements, which is useful later for audits and for the migration plan. Confirm any figure you need for a quote directly with the vendor or your partner, because this page does not set prices, support durations or service levels.
Functional requirements: channels, agents, SLAs and escalation
This table lists the functional requirements a helpdesk must meet for channels, agents, service levels, customer self-service and automation, with the reason each one matters and how to test it in a trial. Read each row as a question to put to a vendor or implementation partner, and treat the verification column as the acceptance test you run before signing off.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Email intake with threading and shared inboxes | Email is usually the largest channel, and a poor threading model splits one customer's history across several tickets. | Send a test thread from an external address, reply from two agents and confirm one ticket keeps the full history. |
| Chat and web contact channels | Chat widgets and contact forms need to create tickets with the customer identity attached, or agents lose context. | Submit a chat or form test from a signed-in and an anonymous session and check the ticket fields and contact record. |
| Phone and social channels | Phone and social usually need separate connectors or a telephony integration, so they are rarely covered by the core email setup alone. | Confirm each channel in the exact version you plan to run, then test an inbound call or message end to end. Do not assume support from the product name. |
| Agent roles, teams and permissions | Routing, visibility and reporting depend on how agents, groups and roles are structured, and changes later are costly. | Run a role matrix review with the support lead and test that an agent in one team cannot open another team's restricted queue. |
| SLA targets per queue or customer tier | Response and resolution targets must match contracts, and they must start and pause on the right events. | Create two test tickets in different queues, let one breach its target and confirm the breach, pause rule and report entry. |
| Escalation paths and notifications | Unanswered tickets need to reach a team lead or on-call owner automatically, not rely on someone checking a list. | Trigger an escalation with no agent response and confirm who is notified, through which channel and at what time. |
| Macros, triggers and automations | Automations drive routing, tagging and status changes; untested rules can close tickets or send wrong replies. | Trial each macro and trigger against sample tickets, review the audit of changes and confirm rollback before go-live. |
| Customer portal and knowledge base | Self-service reduces inbound volume only if articles are findable, access rules are right and portal users see only their own tickets. | Log in as two customers and confirm each sees only their tickets and only the articles permitted for their group. |
| Reporting and performance under load | Managers need queue, SLA and workload reports, and search speed depends on the components you deploy. | Load representative ticket volumes into a staging instance, then check report accuracy and search response with your own data. |
How the helpdesk components connect to channels and data
A self-hosted Zammad deployment depends on four components that you need to plan for before any channel is connected. PostgreSQL 15 or newer stores the content of the system, including tickets, users and history, so it is the component your retention and backup policies will apply to first. Redis 7 or newer handles realtime websocket communication, which is how agent screens update without a page reload. Nginx or Apache sits in front of the application as the reverse proxy and carries the TLS termination, so the certificate, cipher policy and access logging decisions are made there. Confirm these versions against the current Zammad software requirements page before you size the hosts, because the minimums change between releases.
Elasticsearch is optional, but the documentation recommends it strongly because it provides faster search, the reporting features and the ability to search the text of email attachments. If your agents depend on finding past conversations by attachment content, or your reporting relies on it, treat Elasticsearch as a required component in the design and budget for its own hosting, patching and index backups. Multi-instance deployments, such as containers or cluster nodes, need Memcached, while a single installation can use the file system cache. The practical decision is whether you will run more than one application node from the start, because adding Memcached later changes the deployment.
For FreeScout and osTicket, the component list is different and you should confirm it rather than assume it. Both are PHP applications, so the web server, PHP version, extensions and database engine are the points to check against each project's current installation documentation in the FreeScout GitHub repository and the osTicket GitHub repository. Ask your partner to document whether either stack needs a cache, a queue worker or a search index for your volume, how channel polling runs, and which database versions the release you select supports. Map every component to the channel, data store and owner it serves, so each one has a named backup, monitoring and patch process.
Which security requirements the helpdesk must meet
A helpdesk holds customer identities, complaints and often attachments with sensitive personal data, so its security controls matter as much as its features. The cards below set out the controls to specify and then verify in your own environment, from access and encryption to patching and recovery.
Role-based access and queue separation
Define agent, supervisor and administrator roles, then restrict which queues, groups and customer records each role can open. Separate queues for sensitive matters, such as complaints or clinical billing, should not be visible to general agents. Test the model with real accounts before go-live, including what an agent sees in search, reports and attachments. Confirm that the platform's role and group permissions can express your separation without workarounds.
Encryption in transit for conversations
Customer messages, agent sessions and API calls should all travel over encrypted connections, including the path from the mail server to the helpdesk and from the reverse proxy to browsers. Verify that inbound email can be required to use TLS where your mail provider supports it, and that web access is HTTPS only. This control maps to the transmission security requirement in 45 CFR 164.312(e)(1) for ePHI, and you should confirm how it applies to your data.
Audit logging of ticket access and changes
Record who viewed, changed, merged, deleted or exported a ticket, and when. Logs should cover administrator changes to roles, channels and automations as well. Decide where logs are stored, who can read them, and how long they are kept, and confirm that agents cannot alter them. The audit control described in 45 CFR 164.312(b) is one reference point for healthcare deployments, while financial services teams should map the same evidence to their own retention rules.
Attachment storage location
Attachments often carry the most sensitive data in a ticket, such as identity documents, medical forms or statements. Decide whether they are stored on the helpdesk server, on an encrypted volume you control, or in object storage within your boundary, and confirm the storage location in writing. Check that deletion or retention policies also reach attachment copies, backups and search indexes, since the search engine may extract attachment text.
Patch cadence and security release handling
Zammad published security releases 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026, and security release 6.5.5 on 15 October 2026 for the 6.5 line, so fixes arrived on more than one branch in the same month. Agree with your operator who monitors releases, how quickly a security update is tested and applied, and how a rollback works. Confirm which branch you run and whether it still receives security fixes.
Admin hardening and backup
Limit administrator accounts, require strong authentication for them, and keep the admin interface off public networks where possible. Restrict database and cache access to the application, and store secrets outside configuration files shared with the team. Back up the PostgreSQL database, attachments and configuration together, then test a restore on a separate host. Confirm that the backup set includes the search index or can be rebuilt from source data.
Migrating tickets and setting retention before go-live
Before go-live, inventory what the current tool holds and decide what moves and what is archived. Export a count of open tickets, closed tickets by year, users (agents, admins and customers), attachments with their total size, macros, canned responses, triggers, automations and SLA rules. Each object needs a decision: migrate with history, migrate only open items, or archive read-only. Zammad includes migrators for Freshdesk, Kayako, OTRS and Zendesk, and other systems can be imported through the Zammad API or custom development, so confirm with your implementation partner whether your source tool is covered by a migrator or needs a custom import. Ask for a sample migration of a few hundred tickets with attachments before committing to the full run, and check that agent roles, group assignments and customer email addresses map correctly.
Set retention as a written schedule before the first production ticket arrives, because it determines the database design, attachment storage and backup policy. Separate ticket metadata, message bodies, attachments and audit logs, since each may carry a different period. Regulated sectors may need to keep customer communications for fixed periods. As one illustrative example, SEC Rule 17a-4(b)(4) requires broker-dealers to preserve originals of communications relating to the business for not less than three years. The HIPAA Security Rule's audit control requirement in 45 CFR 164.312(b) requires systems holding ePHI to record and examine activity, which shapes what your helpdesk logs and how long they are kept. Confirm your own retention schedule, legal hold procedure and deletion rules with counsel and your compliance lead, not with the platform vendor.
Operational requirements and how to verify them
This table lists the operating requirements a helpdesk needs after go-live, why each matters, and how to verify it before you commit. Read each row as a question to put to your team and to any implementation partner: the verification method is the evidence you should expect to see. The main takeaway is that a helpdesk is judged in operation (restores, patches, search load and staff skills), so these checks belong in the scope and acceptance criteria, not in a later phase.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Hosting model and Kubernetes support boundary | Zammad documents package, Docker Compose and Kubernetes Helm installs, but its Kubernetes support covers only the Zammad application, not Kubernetes-specific issues. Your platform team may own the cluster, and the gap between the two must be clear before go-live. | Write down who owns the cluster, nodes, ingress and storage. Confirm the vendor support tier and its scope in writing, and ask for the support boundary in the quote. |
| Backup and restore testing | A backup that has never been restored is an assumption. A helpdesk holds ticket history, attachments and customer identifiers, so a lost database or attachment store affects both operations and records retention. | Run a scheduled restore into a separate environment covering the PostgreSQL database and attachment storage. Time the restore, check ticket counts and attachment integrity, and record the result as evidence. |
| Upgrade and security patch process | Zammad published security releases on 6.5 and 7.x lines in parallel (for example 7.2.1 on 6 October 2026, 7.2.2 on 8 October 2026 and 6.5.5 on 15 October 2026), so patching is an ongoing duty, not a one-off project. | Agree a staging environment that mirrors production. Apply each security release there first, run ticket, email and API smoke tests, then promote. Keep a dated change record for each release. |
| Monitoring and alerting | Failed mail fetches, stalled background jobs, websocket failures and full disks silently stop support. Customers notice before the team does. | Confirm alerts for the mail channel, background worker queue, Redis availability and disk usage. Test each alert by triggering it in staging and confirm who receives it. |
| Support plan and response commitments | Self-hosted Zammad has no license fee, but vendor support subscriptions are sold separately. Without a written support tier, escalations for a security issue or outage may have no defined path. | Request the support tier, response targets and escalation path in writing before signing. Compare the included scope with your own in-house cover, and confirm whether security releases are covered. |
| Capacity for search and attachments | Zammad describes Elasticsearch as optional but strongly recommended for faster search, reporting and attachment content search. Attachment growth and search index size drive storage and memory needs over time. | Load test with a realistic volume of historical tickets and attachments drawn from your migration sample. Measure search latency and index size, then set storage growth alerts based on the observed rate. |
| Multi-instance cache and session design | Zammad documents Memcached for multi-instance deployments such as containers or cluster nodes, while single installations can use the file system cache. A wrong choice causes intermittent session and cache issues under load. | Confirm the deployment topology in the design document. In staging, run two application nodes behind the reverse proxy and verify sessions, websocket updates and cache behavior during a rolling restart. |
| Staff skills to administer the system | The platform needs people who can run PostgreSQL, Redis, Elasticsearch, the reverse proxy and the mail channel, as well as the helpdesk itself. Skills gaps tend to surface during the first incident, not at go-live. | List the named administrators and their skills against each component. Schedule a handover with runbooks, and test that a second person can perform a restore and a security upgrade without outside help. |
Questions buyers ask before hiring help with a helpdesk
What drives the cost of implementing a self-hosted helpdesk?
The cost is driven by how many channels, integrations and data sources must be connected, how much history must be migrated, and how many teams and routing rules must be configured. Zammad itself carries no license fee when self-hosted, so the spend is on the work and the infrastructure: hosting in your own cloud or data center, the database and cache layers, the mail and telephony connections, and the people who build and test them. Zammad's published self-hosted support subscriptions are priced at 2,999 EUR per year for Business, 5,999 EUR per year for Enterprise and 9,999 EUR per year for Corporation, according to its pricing page. Ask any partner for a quote that separates one-time work (design, migration, integration, hardening, training) from recurring work (hosting, upgrades, security patching, support), and that lists each item in the written scope.
How long does a helpdesk migration and rollout usually take?
The duration depends mainly on the volume and quality of the data being moved, the number of channels to cut over, and how many integrations must be tested before agents switch. Large histories with many attachments, inconsistent custom fields or legacy email routing take longer to validate than a clean export. Zammad documents migrators for Freshdesk, Kayako, OTRS and Zendesk, while other systems usually require the Zammad API or custom development, which adds scope. A phased rollout, where one team or one mailbox moves first, usually reduces risk, but it extends the calendar. Ask for a timeline tied to named phases, a data validation step and a cutover plan with a rollback path, and do not accept a single date without those milestones.
What does the work need from our own team?
Your team provides decisions and access, which are often the slowest part of the project. Expect to supply named owners for queues, SLAs, escalation paths and knowledge base content, plus the mail domains, DNS records, telephony trunks, identity provider settings and API credentials the integrations require. Security and compliance staff should confirm retention periods, access roles and where attachments are stored, because those choices shape the configuration. Agents and team leads need time for testing and training, and someone must approve each cutover step. Ask a partner to list these inputs by name and role in the written scope, so you can plan availability before the project starts.
Can a small support team run Zammad without a partner?
A team with platform administration skills can run Zammad alone, provided it can operate a PostgreSQL 15 or newer database, a Redis 7 or newer service for realtime communication, and a reverse proxy such as Nginx or Apache, as described in the software requirements. Teams that lack these skills, or that need multi-instance hosting with Memcached, Elasticsearch search or Kubernetes, usually benefit from outside help at setup and during security releases. Zammad 7.2.2 was released on October 8, 2026 as a security update, which shows that patching is an ongoing task. Ask yourself who will apply those releases within your change window, who monitors backups, and who handles incidents at night. If the answers are unclear, a partner can cover the gap through a retainer.
Which platform questions should we put in an RFP?
Ask the bidder to explain why it recommends Zammad, FreeScout or osTicket for your channel mix, agent count and compliance needs, and to show the architecture it proposes. Ask how tickets, users, attachments and history are migrated from your current tool, and which parts require custom work. Ask how each channel (email, chat, phone, social) is connected, how search is configured, and how security releases are tested and applied. Ask which identity options are supported, such as SAML or OpenID Connect, and how the platform is backed up and restored. Finally, ask what the included support plan covers and what it excludes, in writing. Vague answers to these points are a common reason projects overrun.
What do support subscriptions cover, and what do they leave out?
A vendor support subscription typically covers help with the product itself, while your infrastructure, network, identity provider and custom code stay your responsibility unless a separate agreement says otherwise. Zammad's self-hosted tiers, Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, are published on its pricing page, but the tier you need depends on your response expectations and your environment. The Zammad documentation also states that support on Kubernetes covers only the Zammad application, not Kubernetes-specific issues. Ask any partner to map each responsibility to a named party, and to confirm whether the subscription is bought directly from the vendor or handled through a separate services agreement.
Does a partner's retainer replace internal ownership of the helpdesk?
No. A retainer adds capacity for upgrades, testing, monitoring and support, but your organization still decides queue design, SLA targets, data retention and who may access tickets. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, so the system and its evidence remain in your environment. Ask for a responsibility matrix that shows which tasks the partner performs, which your team keeps, and how handover works if the engagement ends.
How to turn the checklist into a platform decision
This sequence turns a list of helpdesk requirements into a written, evidence-based choice between Zammad, FreeScout and osTicket. Each step ends with a document or test result that the buyer can review before committing to a platform or a support plan.
Confirm must-have channels and compliance drivers
Support leads and the compliance owner sort every requirement from the checklist into must-have, should-have and not needed, and mark which regulations apply to ticket content, such as retention or audit logging rules. Record the channels that customers already use, including email, chat, phone and social, and the systems that must receive ticket data. The step is done when a signed-off requirements register exists and each compliance driver names the control owner who will verify it later.
Score the three candidate platforms
The solution architect and a support lead score Zammad, FreeScout and osTicket against the register, one row per requirement, using the same evidence for each product. Scoring covers channel connectors, SSO options, search, automation rules, portal features, integration paths and the database and cache components each platform needs. Confirm every capability against the current vendor documentation and release notes rather than from memory. The step is done when each must-have has a yes, no or needs-confirmation answer with a source link.
Shortlist one platform and its hosting model
The architect compares the scored results with the hosting constraints, team size and expected operating model, then selects one platform for testing and records why the other two were set aside. Include the target infrastructure, such as a cloud account, data center or air-gapped network, and the supporting services the chosen platform requires. The step is done when a written decision note lists the selected product, the rejected options, and the open questions that the proof of concept must answer.
Run a proof of concept with real email and one integration
The implementation team connects a test mailbox that receives real inbound messages from a limited group of users, and configures one priority integration such as the CRM, telephony or identity provider. Agents work tickets through SLA timers, escalation rules and at least one automation, and the team checks attachment handling and search results. Keep the environment in the client's own infrastructure during the test. The step is done when a test report shows which must-have requirements passed, failed or need a workaround.
Test migration on a sample export
The team exports a representative sample of tickets, users, attachments and closed history from the current helpdesk, then imports it into the test instance using the migration method the platform supports, such as a built-in migrator, the API or custom development. Compare record counts, ticket status, timestamps, ownership and attachment integrity against the source. The step is done when a reconciliation report lists every mismatch, its cause and the decision on whether to fix, accept or exclude it.
Verify access, audit and retention controls
The security engineer and compliance lead check that SSO works with the chosen identity provider, that role and group permissions match the agent structure, and that audit logs record the activity the regulations require. They also confirm where attachments are stored and how retention and deletion rules will run against the database and storage. The step is done when a control checklist is signed by the compliance owner, with each item linked to test evidence or a documented gap.
Agree the support and patch plan in writing
The client and the implementation partner agree in writing who applies security releases, how quickly they are tested in a staging instance, who handles incidents, and whether a vendor support subscription or a partner retainer covers the platform. The scope document should name the platform version, the environments in scope and the exclusions, such as Kubernetes platform issues that the application vendor does not support. The step is done when the signed scope, support terms and patch calendar are filed with the decision note.
How DeployOpen scopes and delivers helpdesk selection and implementation
DeployOpen turns a helpdesk requirements list into a written scope before any build starts. We plan, implement, customize, integrate, harden, document and support self-hosted open-source helpdesk platforms inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with deliverables and timelines agreed in writing.
How we scope
- Review your channel, team, SLA, integration and retention requirements against the candidate platforms
- Confirm which channels, identity provider and CRM or telephony links are needed on day one
- Agree in writing which data sources, migration volumes and retention rules are in and out of scope
How we build
- Deploy the chosen helpdesk and its PostgreSQL, Redis and search dependencies in your environment
- Configure channels, groups, SLA rules, automations and SSO against the agreed requirements
- Test email intake, escalation paths, role permissions and attachment handling before go-live
How we hand over
- Deliver architecture, configuration and runbook documentation covering the agreed requirements
- Train administrators and agents on queues, roles, automations and reporting in your environment
- Record the evidence your auditors may ask for, such as access settings, audit logs and retention configuration
How we support
- Offer ongoing support, upgrades and security patch application as a retainer after handover
- Track vendor security releases and schedule applying them to your production instance
- Review requirements again when channels, teams or compliance obligations change
