Zammad phone integration with CTI, Placetel and sipgate

The choice between the generic CTI webhook and the Placetel integration depends on two things: what your telephone system can send, and which Placetel product line your organization licenses. Settle both before anyone configures Zammad, because the answer decides who builds the connection, what the administrators must hold, and what has to be maintained after go-live.

The generic path asks more of the telephone system than of Zammad. Zammad expects the PBX to send outbound webhooks that carry a unique call ID, both phone numbers and the call direction. If the PBX cannot emit those fields in a consistent form, something else has to translate its events before Zammad can use them. The Zammad instance must also be reachable from the phone system, so confirm the network path, DNS name, TLS setup and firewall rules between the two. Ask the PBX vendor whether the call ID stays the same across the call lifecycle and whether direction is included on every event.

The Placetel integration asks something different of the account. Zammad's documentation requires an administrative Placetel account, so the person who sets up the connection must hold admin rights, not only a user login. It also requires the legacy Placetel Pro product. Check the product line on your contract before planning. If your numbers sit on Webex for Placetel, the documented Placetel integration does not apply to that line, so confirm the route with Placetel and with Zammad's admin documentation before committing to a timeline.

For sipgate, the team must check whether a native integration or a generic webhook route is documented for the specific sipgate product in use before choosing. Do not assume the Placetel answer carries over. The choice also decides who builds and maintains the middle layer. A native integration keeps that layer with the vendor's supported configuration. A generic webhook route makes your team or an implementation partner responsible for the translation service, including its uptime, logs, certificates and upgrades.

Before the build starts, record the PBX model and firmware, the exact product line or sipgate product, the name of the administrative account holder, whether the required webhook fields are available, and who will own the middle layer after handover. Illustratively, if the PBX cannot emit a unique call ID, the generic route stops being viable until the vendor or a translation service fills that gap, and that finding should change the plan before any Zammad configuration begins.

Whether Zammad finds a caller depends less on the integration than on whether the phone system and Zammad agree on how a number is written. A customer stored as +49 30 1234567 in Zammad will not match an inbound webhook that delivers 030 1234567 or 0049301234567, so the first practical step is to decide one canonical format for stored customer numbers and to make sure the phone system sends numbers in that same form. Customer records that were imported from an old helpdesk, a CRM or a spreadsheet often mix local and international notation, so plan a cleanup pass before go-live rather than assuming the integration will normalize them. The generic CTI interface expects the telephone system to send a unique call ID, both phone numbers and the call direction with each event. Zammad uses that information to look up the customer, show the caller in the agent view and create or update a call log entry. The exact normalization and lookup rules are the part to confirm against the current Zammad CTI documentation for your version, because they decide which formats match. Do not reconstruct them from memory or from a forum post, and do not assume the Placetel or sipgate integration applies the same rules as the generic interface. Unknown numbers need an explicit policy. When no customer matches, you need to decide whether the call still produces a log entry, whether an agent is prompted to create a customer and who is allowed to do so. Ask your team which of these outcomes they expect and check what the chosen integration actually does with an unmatched number in a test instance. Also confirm what a call log entry contains in your version: typically the direction, both numbers, timestamps and the linked customer or ticket where one exists, but the set of fields and their labels should be checked rather than assumed. The call ID is what makes event handling safe. Phone systems may retry webhooks or send separate events for ringing, answering and ending the same call, so Zammad needs a stable identifier to recognize that several events describe one call. If the ID is missing, changes between events or is not unique across the phone system, you can get duplicate log entries or a call split into several records. Ask your telephony provider how it generates call IDs and whether they are unique over time. Test with real numbers from your own customer base, not with a few invented examples. Export a sample of customer numbers, include mobile, landline, international and older formats, place test calls in both directions and record what each agent sees. This test will show mismatches that no documentation summary can predict, and it gives you a baseline to repeat after any change to the phone system, the Zammad version or the number format.

The phone integration is only ready for agents when a documented test plan has run against the same phone configuration and Zammad version that production will use. Testing against a lab PBX or an older Zammad build can pass every case and still fail on the live system, because the webhook payload, extension mapping and caller ID normalization all depend on details that change between environments. Agree on this rule before the first test call is placed, and record the exact Zammad version, the Placetel or sipgate account settings, and the PBX or webhook sender configuration in the test record.

Each test case needs a defined expected result and a fixed set of fields the tester records. For every call, record the call ID as it arrives, the direction, both numbers as received and as displayed, the extension that rang, the agent who answered, whether the caller card opened, which customer or ticket was linked, and whether a call log entry was created. Cover these cases: an inbound call from a known customer, an outbound call started from a Zammad link, an internal extension-to-extension call, a call from an unknown number, and a known customer whose number is stored in a non-standard format such as a national prefix or missing country code. Include two agents receiving calls on different extensions at the same time, so that the extension mapping is tested rather than assumed.

Add one case that fails on purpose. Drop the webhook connection or interrupt the call mid-way, then confirm what Zammad does with the partial call: whether a log entry is written, whether an incomplete record is flagged, and whether the next call still routes correctly. Note which failures the phone system itself reports and which must be caught from Zammad's side, since this determines what agents and administrators should watch for after go-live.

Assign roles before testing starts. A test lead runs the cases in order, a second tester places or receives the calls from the other end, and an administrator checks the Zammad logs for each case. Sign-off should come from the operations owner who will support the integration, and from the telephony owner for the PBX or provider account, not only from the person who built the connection. Store the signed test record with the change ticket so the same cases can be rerun after a Zammad upgrade or a change to extensions, trunks or caller ID rules.

Ask your telephony provider and the Zammad documentation for any setting that changes call data before it reaches Zammad, and confirm it in writing. Ask whether the test plan should be repeated for each Zammad release that touches the telephony code, and who pays for retesting if a fix from a vendor is needed. The result should be a short list of open issues, each with an owner, that is closed before agents start depending on caller information in their daily work.