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.
What is the difference between this solution and your other repo (zendesk-translation-via-aws-eventbridge-partner)? This fork does not use the zendesk partner integration that requiers a subscription package from zendesk, instead we are using zendesk webhooks and pushing the information to eventbridge via apigateway with basic auth protection (only supported solution for zendesk). Read more about this for details here.
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)
- AWS SAM
The following needs to be on your machine to be able to deploy
- git
- cat
- sam
- aws-cli
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-apigateway-webhook.git- Edit the samconfig.toml to reflect your setup
stack_name = "wh-zendesk-trans-dev"
s3_bucket = "your-artifactory-bucket-dev"
s3_prefix = "lambda/zendesk-translate-eventbridge-webhook-dev"
region = "eu-west-1"4.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. 5. Edit parameters file 6.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",
"ZendeskKeySSMParameterPath=/config/zendesk-translation/zendesk_api_key",
"[email protected]",
"ZendeskSubdomain=zendesk-subdomain",
"ZendeskTicketLangFieldId=<ticketfield_id>",
"KmsKeyId=kms_key_id_to_protect_ssm_parameters",
"EventBusName=customer-eventbus-dev",
"BasicAuthUsernameSSMParameterPath=/config/zendesk-translation/basicauth_username",
"BasicAuthPasswordSSMParameterPath=/config/zendesk-translation/basicauth_password",
"EventBusName=customer-eventbus-dev"
- Deploy
sam build
sam depoy
#Example if you have multiple accounts with a aws cli dev and prod profile
sam deploy --profile dev --config-env default
sam deploy --profile prod --config-env production
This needs to be done after the deployment have been done, take a note on the basic auth user and password and the ApiUrl output from the deployment (sam output or cloudformation console). Follow this guide to setup the outgoing zendesk configuration.
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
You need the "api package" subscription from zendesk, they basically bill you for not needing to setup webhooks. Is it a price question? No, we got our setup deleted (we participated in the beta) in production from no where by zendesk. After we escalated the support ticket to our account manager we got informed that this is a subscription based feature, we also thought that the attitude was not right as we did not get any info about this before or during the beta.
Even if we were happy with the partner setup that was running for 6-7 months we started to build this setup instead as of the experience above.
Remove some code and use the new feature for outgoing webhooks from eventbridge
Distributed under the GPL-3.0 License. See LICENSE for more information.
Lezgin Bakircioglu - 
