Plan requirement
| Subscription | Any plan |
| Access | Admin |
Start from the problem, not from the app list: five common problems and what solves each. Customer details beside the ticket is the highest-value one.
"Agents keep switching systems"
A display integration: CRM, shop or billing details beside the ticket. This is the highest-value category and the easiest to justify, because the time saved is visible immediately.
"Bugs get lost between support and development"
A Jira connection, plus an agreed process for who creates issues and what happens to them. The process matters more than the integration.
"Nobody knows when something urgent arrives"
Usually not an integration. A view, a trigger and an agreed rhythm solve it without a supplier, and they keep working.
Chat notifications help only for genuine exceptions, and only if somebody watches the channel.
"We need data in another system"
A webhook, or the API. An app is the wrong tool for moving data; apps add interface, and this problem has no interface.
"Our process needs something Zendesk does not do"
Check the built-in features first. A surprising share of app installations replace a view, a macro, a trigger or a custom field.
Those cost nothing, involve no supplier and never get abandoned.
The order to consider
| First | Can configuration do it? |
| Then | Can a webhook do it? |
| Then | Is there a Zendesk-published app? |
| Then | Is there a third-party app worth the supplier relationship? |
| Last | Does something need building? |
Check whose app it is
The decision order above asks whether an app is published by Zendesk, and the Marketplace answers it directly: on the app's page, under App details, the Author field names whoever maintains it, with a Contact Us link to reach them.
That field is the whole supplier question in one line. A third-party app is neither managed nor supported by Zendesk, so if it misbehaves the fix sits with its author rather than with the platform. Come to us and we will work out which side the problem is on, but knowing in advance that an app is somebody else's product is what makes the difference between a dependency you chose and one you inherited.
Ask what happens when it breaks
Every integration is a dependency. Knowing whether a failure is an inconvenience or an outage tells you how much diligence it deserves.
Comments
0 comments
Article is closed for comments.