This is a aws serverless solution to get translation for none english tickets in zendesk, both incoming and outgoing. If the language is detected wrong, the agent can easily change the language for the ticket inside of zendesk.
What is the difference between this project and the other ones out there including the AWS zendesk+eventbridge sample? This solution is more complete and is built on the actuall need from customer service agents (staff) as this replaced a (expensive) third party app. This was completed in april 2020 where most of other great contributions was released around that time. After running this in ~6 months in production with a dashboard from the first day to follow the cost and time saving we decided to release it. The following features was built to be able to move from the old solution:
- First message is detecting the language and sets a custom field in zendesk so it is easy to change the language for the agents.
- The agent/staff reply that should be translated is posted as a internal note started with #translate . The update to the customer should be the same as agent/staff and not the API user.
- If an attachment is also part of the internal note (eg return instructions) it will be part of the public reply response.
With the solution we build, we managed to save 99.97% in running cost (OPEX), we also saved agent time (~45s per ticket update) because the translation was automated. The old solution requierd the agents to request translation both for incoming and outgoing updates, while this solution already have the translation ready before the agents enters the case and also updates the ticket after translation is done.
We could also ignore the OPEX cost for the this solution, you may ask your self why? The cost is now the same as the daily leasing ratefor our seven coffee machines in our HQ in Stockholm, Sweden. You may now think, what about development/initial cost (CAPEX)? The savings covered them the first six weeks.
- Zendesk
- AWS Eventbridge
- AWS Lambda
- AWS Translate
- AWS Comprehend
- AWS Systems manager (Parameter Store)
The following needs to be on your machine to be able to deploy
- make
- git
- cat
- aws-cli
If you don't find the settings for eventbridge on zendesk side for steps bellow, it means you don't have the "api package" (they basically bill you for not needing to setup webhooks). We got our setup deleted (we participated in the beta) in production from no where by zendesk when they informed us after we escalated the support ticket to our account manager.
We started to build
for that function without informing us. On the good side of that, we have built a alternative solution that is based on the zendesk webhooks and api gateway + lambda for basic auth.
We moved instead to the alternative solution due to that after 6-7 months and its based on the similar stack with eventbridge but instead of using the partner integration, we utilized the zendesk webhook that is free and ingest it with the same format to api gateway with a lambda authorizer to get basic authentication protection. The API gateway will after a successful authorization put's the messages to eventbridge. The fork can be found here and this repo is not maintained anymore but feel free to fork it.
Sadly, this is manually as the setup needs to be done on the zendesk side. You will need to start with this as you need the name of the partner eventbus, after the setup you will find it in Amazon EventBridge => Events => Partner event sources. Edit your parameters-{dev/prod}.env file and add it to EventBusName=
Follow the guide https://support.zendesk.com/hc/en-us/articles/226022787-Generating-a-new-API-token- and create a ssm parameter store with the key inside, make sure it is encrypted / protected with kms by using secure string. The parameter needs to be setup in the variable ZendeskKeySSMParameterPath. https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html
https://support.zendesk.com/hc/en-us/articles/203661496-Adding-custom-fields-to-your-tickets-and-support-request-form Take a note on the ID as it will be set for ZendeskTicketLangFieldId
- Clone the repo
git clone https://github.com/dwtechnologies/zendesk-translation-via-aws-eventbridge-partner.git- Edit the Make file 2.1 Make sure to set the right region (same as the eventbridge), aws profile to use and artifact bucket to upload the lambda for deployment.
- Edit parameters file 3.1 Set the path that you created in "Setup zendesk api key" setep. Make sure that it is kms protected (secure string) or change CF + code.
ZendeskKeySSMParameterPath=/config/zendesk-translation/zendesk_api_key3.2 The rest of the parameters, the subdomain does not need to
Environment=dev
DebugParam=true
ZendeskUsernameMail=Same-User-that-created-the-api-key@localhost
ZendeskSubdomain=zendeskSubdomain
ZendeskTicketLangFieldId=9999999999
KmsKeyId=xxx-xx-xxxx-xxx-xxx
EventBusName=aws.partner/zendesk.com/xxx/default- Deploy
make I recommend to manually create a "catch all" / wildcard eventbus rule to save the data to cloudwatch in the beginning to debug the communication going on the bus. To test the lambda, use the json files and adjust them to your needs to test the lambda if you suspect that the lambda is not working as expected.
The eventbridge-cli tool is really awesome and have saved allot of time during testing
Any contributions you make are greatly appreciated but please have in mind to make what you create must be dynamic to not break current use case
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/AmazingFeature) - Commit your Changes (
git commit -m 'Add some AmazingFeature') - Push to the Branch (
git push origin feature/AmazingFeature) - Open a Pull Request
- Convert to sam cli build that makes more sense for the public
Distributed under the GPL-3.0 License. See LICENSE for more information.
Lezgin Bakircioglu - 
