Helpdesk software RFP questions

The right platform depends on team size, channel mix, search needs and how much operational weight you can carry. A good partner starts from your requirements and explains the trade-offs in writing. Zammad is the option built for larger, multi-team support operations, with PostgreSQL 15 or newer, Redis 7 or newer and optional Elasticsearch. FreeScout and osTicket are lighter tools that suit small shared inboxes. Ask the partner to name the features that would push you toward a different platform later, such as team routing, SLA rules, or attachment search. Confirm current capabilities and licensing (Zammad is AGPL-3.0) directly with the vendor and the Zammad repository before deciding.

Zammad includes migrators for Freshdesk and Zendesk, along with Kayako and OTRS, so a supported path exists for those sources. Ask the partner to show, on a test extract, how tickets, comments, users, organizations, tags and attachments map to Zammad objects. Other systems require the Zammad API or custom development. Confirm which history fields survive the move, how closed tickets and time stamps are handled, and how attachments are stored and linked. Ask for a written reconciliation step that compares ticket counts and attachment totals between source and target before cutover. Review the Zammad migration documentation with the partner so the scope is explicit.

Each channel needs its own configuration, and the partner should list them one by one. Email requires an inbound and outbound mailbox, correct DNS records for sending, and a plan for threading and spam filtering. Web forms and chat connect through the application's channel settings or APIs. Phone usually depends on a telephony system and an integration, so confirm whether it is native, via a connector, or out of scope. Ask who owns mail domain records, how bounced messages are handled, and how a channel outage is detected. Request a channel matrix in the statement of work that names the source system, the connector and the test cases for each channel.

Search quality depends on whether Elasticsearch is configured. Zammad documents Elasticsearch as optional but strongly recommended, because it speeds up search, supports reporting and enables search inside email attachment content. Without it, your agents may find ticket text but not the contents of attached files. Ask the partner to state the Elasticsearch version and sizing, index rebuild procedure after migration, and how index growth is monitored. Confirm how attachment text extraction handles scanned or encrypted files, and whether search access follows the same role rules as ticket access. Test with real attachment types before go-live.

The choice depends on your platform team and how many application instances you run. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. For Kubernetes, the vendor support covers only the Zammad application, so the partner must own cluster-level issues, networking and storage. Memcached is required for multi-instance deployments such as containers or cluster nodes, while a single installation can use the file system cache. Ask for the reverse proxy choice (Nginx or Apache), the PostgreSQL and Redis topology, backup of the database and attachment storage, and which team pages on-call alerts. Check the Zammad Kubernetes documentation to confirm the scope split.

Zammad supports third-party login through SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among other providers. Confirm which of these your identity provider uses and whether group or role claims map to Zammad roles. Ask how just-in-time user creation works, how leavers are deprovisioned, and whether local admin accounts remain as a break-glass path. For customer-facing portals, ask how identity is verified before account changes are made. Request written test cases for login, role mapping and deprovisioning. The Zammad third-party applications documentation lists the settings to review.

Ask the partner for a written patch process, not a promise. Zammad publishes security releases on its releases page, and in the researched timeline 7.2.1 and 7.2.2 followed the 7.2 minor release in October 2026, while security fixes were also published for the 6.5 line. A good answer names who monitors release notes, how a security release is tested in a staging copy, the approval step, the maintenance window and the rollback plan. Ask how parallel release lines are handled if you run an older version. Confirm the agreed response steps in writing, and check the Zammad releases page so the partner's process matches the vendor's cadence.

Backup covers at least three things: the PostgreSQL database, attachment storage and the configuration. Ask the partner to state the backup frequency, retention period, storage location and encryption, and to demonstrate a restore to a separate environment. Retention rules for tickets and customer communications depend on your regulator or contract, so ask how deletion is executed and logged. For regulated industries, confirm whether backups are included in your retention or erasure process. Request a restore test result as a deliverable and the recovery time objective agreed in writing.

Costs fall into four groups: the self-hosted software (no license fee for Zammad itself), the vendor support subscription, your infrastructure, and the implementation work. Zammad sells self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to its pricing page. Those subscriptions are separate from the partner's implementation and any retainer. Ask the partner to list what the retainer covers, including patching, monitoring, upgrades, incident response hours and testing. DeployOpen supports self-hosted platforms through fixed-scope engagements and optional retainers, and a quote follows from the written scope.

The software license is not the main cost. Zammad is free to self-host, and FreeScout and osTicket are open-source packages as well, so the spend comes from the work around the software. The cost components are migration (exporting tickets, users and attachments and mapping them to your new structure), hosting (servers or cloud resources, backups, and for Zammad a PostgreSQL database, Redis and, when you need faster search, Elasticsearch), integration with your CRM, telephony and identity provider, and support. For Zammad, the vendor sells self-hosted support subscriptions at 2,999 EUR per year (Business), 5,999 EUR per year (Enterprise) and 9,999 EUR per year (Corporation), according to its pricing page. Ask any partner to split the quote into one-time work (migration, integration, hardening) and recurring items (hosting, patching, support retainer, and any vendor subscription).

Timing depends mostly on the volume and shape of your data, the number of integrations, and the compliance evidence you must produce. Large ticket histories with many attachments take longer to move and validate than a clean export of recent tickets. Every system that writes to or reads from the helpdesk, such as your CRM, telephony, billing or identity provider, adds design and testing work. Compliance evidence matters too: if you must show retention periods, access logs or audit trails, those controls need to be built and documented before cutover. Zammad includes migrators for Freshdesk and Zendesk, while other sources may need custom import through the Zammad API. Ask for a written timeline that lists each phase, its dependencies and the data sets you have confirmed, rather than a single end date.

The engagement needs named people on your side, and the quality of their time sets the pace. Plan for a few agents who will test real queues, macros and escalation paths, because they will find gaps that administrators miss. You need an administrator or platform owner with access to the server or cloud account where the helpdesk will run, plus accounts for your identity provider if single sign-on is in scope. Decision makers should approve the channel list, the retention rules and the support model early, since changes late in the project are costly. Legal, privacy or compliance staff should review retention and access rules before data is migrated. Ask any partner to list these roles and the hours they expect from each person in the written scope.

Yes, a capable team can run a small evaluation alone, especially for a shared inbox with few agents. You can install a test instance of Zammad, FreeScout or osTicket from the project documentation, load a sample of tickets, and test channels, roles and reporting. The gap usually appears when the evaluation moves toward production: migrating full ticket history, setting up search, applying security updates on a schedule, connecting to other systems and producing audit evidence. Zammad, for example, documents Kubernetes and Docker Compose installs, but its Kubernetes support covers only the Zammad application, so cluster operations stay with your team or a partner. A useful test is whether your team can describe how it would restore a backup and apply a security release without an outage.

Start with the requirements that are hard to change later: volume of agents, channel mix, search needs, reporting, single sign-on, and how much data you must keep and audit. Zammad is licensed under AGPL-3.0 and documents PostgreSQL 15 or newer, Redis 7 or newer and optional Elasticsearch for search, reporting and attachment content, so it carries the heaviest footprint and the widest feature set. FreeScout is also AGPL-3.0 and osTicket is GPL-2.0, and both are lighter products for smaller teams. Check each project's current release notes, since security fixes can ship on different lines. Ask a partner to score each option against your requirements in writing, with the reasons for the choice.

The vendor publishes security releases, and your team or partner applies them to your environment. Zammad, for instance, shipped security release 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026, and also shipped security release 6.5.5 on 15 October 2026 for its older line. Because security fixes can land on more than one line, your patch process must track each version you run. Ask the partner how they monitor releases, how long a critical update takes to reach a test environment, how they roll back if an update fails, and who signs off before production. The answer should be a written procedure, not a promise.

Auditors usually look for access control, audit logging, retention and secure transmission, and the evidence depends on your sector and the frameworks you are assessed against. For broker-dealers, SEC Rule 17a-4(b)(4) requires preserving communications relating to the business for not less than three years. For healthcare, the HIPAA Security Rule at 45 CFR 164.312 requires technical measures that guard against unauthorized access to ePHI sent over networks and audit controls that record and examine activity in systems holding ePHI. DeployOpen prepares systems, controls and evidence for these assessments but does not issue audit reports or certifications. Ask your assessor which evidence they need before the design is fixed.

A support plan should state what is covered, who responds, how fast, and what is excluded. Ask for the response channels, the hours, the severity levels and the response targets written as commitments in the scope. Confirm whether the plan covers the application only or also the operating system, database, Redis, Elasticsearch, reverse proxy and cluster. Check who applies security releases, handles backups and restores, and documents changes. Engagements are normally fixed-scope with agreed deliverables, and ongoing support is available as a retainer, so ask for the retainer terms and what happens at renewal. Request the support terms in writing and compare them with any vendor subscription you are considering.