La API de correo permite establecer las propiedades de los tickets agregando comandos al cuerpo de una respuesta por correo electrónico a una notificación o a un mensaje de correo electrónico que crea un nuevo ticket. Solo los agentes pueden usar la API de correo. Si los usuarios finales utilizan estos comandos, Zendesk los ignora.
El siguiente es un ejemplo de un agente que establece el estado y el agente asignado de un ticket en una respuesta a una notificación por correo electrónico:
Un agente también puede usar los comandos en un nuevo mensaje de correo electrónico que se envía a su dirección de soporte. Este tipo de correo electrónico crea un nuevo ticket.
Sintaxis
La API de correo simplemente busca en la parte superior del correo electrónico la lista de comandos que se deben ejecutar.
Los comandos deben estar en texto sin formato, no HTML, y deben seguir el siguiente patrón:
#command value
Por ejemplo, si desea establecer el estado de un ticket, utilice este comando:
#status solved
Cada comando debe estar en una línea separada. Por ejemplo, si desea establecer el estado y el agente asignado, escriba los comandos como sigue:
#status solved
#assignee jake@zendesk.com
Ingrese el cuerpo del mensaje de correo electrónico después del bloque de comandos.
Referencia de comandos
A continuación se muestra una lista de todos los comandos admitidos que se pueden agregar, una línea a la vez, al cuerpo de un mensaje de correo electrónico válido. La lista también incluye comandos cortos, que son comandos de una sola palabra para los comandos que se usan con frecuencia y que no necesitan un valor. Por ejemplo, se puede usar el comando corto #solved
en lugar de #status
solved
.
Comando | Descripción |
---|---|
#status
|
Los valores válidos son abierto, pendiente y resuelto. Para poder marcar un ticket como resuelto, el #assignee debe estar configurado. Sintaxis corta: #solved solo sirve para aquellos tickets que no tienen campos que el agente está obligado a llenar antes de que el ticket se considere resuelto. |
#requester
|
Establece el solicitante del ticket. Puede ser la ID del usuario en la cuenta o simplemente su dirección de correo electrónico. Si aún no existe en su cuenta, Zendesk lo creará. Este comando no está disponible para los agentes Light. |
#group
|
Asigna el ticket a un grupo. Los valores válidos son el nombre del grupo o la ID de un grupo.
Este comando es particularmente útil para los correos electrónicos reenviados. Cuando un agente reenvía un correo electrónico a Zendesk, de manera predeterminada el ticket resultante está sin asignar o bien está asignado al grupo predeterminado del agente. (Consulte Remitir correo electrónico a su dirección de soporte.) En lugar de eso, los agentes pueden usar este comando para asignar automáticamente el ticket reenviado al grupo especificado. |
#assignee |
Asigna el ticket a un agente. Los valores válidos son la dirección de correo electrónico del agente asignado o la ID de Zendesk Support del agente asignado (obtenida a través de una integración REST, por ejemplo). Si usa este comando, automáticamente se convertirá en un colaborador (cc) del ticket. |
#priority
|
Establece la prioridad del ticket. Los valores válidos son baja, normal, alta y urgente. Nota: Para establecer una prioridad, también es necesario establecer un tipo de ticket (ver a continuación) Sintaxis corta: |
#type |
Los valores válidos son incidente, pregunta, tarea y problema. Sintaxis corta: |
|
Establece las etiquetas del ticket, que pueden separarse con espacios o comas. Nota: Al establecer las etiquetas se eliminan todas las etiquetas establecidas anteriormente en ese ticket. |
#public
|
Establece la actualización del comentario de un ticket en pública. Solo se puede usar al actualizar un ticket. El valor predeterminado es “verdadero” para tickets públicos, lo que quiere decir que el solicitante podrá ver cualquier otra cosa que se incluya en el cuerpo del correo electrónico. El valor predeterminado para tickets privados, como los tickets que crean los agentes Light, es “falso”. Sintaxis corta: |
Comandos no válidos
Si se ingresan comandos o valores no válidos, Zendesk no los toma en cuenta.
Ejemplo
En este ejemplo, el agente usa todos los comandos.
El correo electrónico hace lo siguiente en el ticket n.º 178:
- Establece el estado en "abierto"
- Establece el grupo en "Soporte" y el agente asignado en el agente que tiene la dirección de correo electrónico “juan@zendesk.com”
- Establece la prioridad en "normal"
- Establece el tipo en "pregunta"
- Establece las etiquetas en "ayuda" y "api"
- Establece la visibilidad del comentario en "privado"
- Agrega un nuevo comentario que diga "¡Hola a todos!" al ticket, que si se combina con el comando de arriba no estará a la vista del solicitante.
27 comentarios
Julian
On Dec 22, 2021, Jeff C said:
Yet, the article says
What would be, now, a turnaround to this scenario:
Goal:
When a partner company forwards a user request to my Zendesk, the forwarded email often includes internal information meant only for my agents and not for the requester.
Need:
I want the first message in the conversation (the forwarded email) to be created automatically as an internal note, so it is not visible to the end user.
Thank you for your ideas.
0
Axel de Jong
This is something we too would really appreciate: some kind of trigger to allow to set the organization on email tickets for users with multiple organisations.
1263792605130 did you ever find a way to achieve this?
0
Justin Near
We have several clients with multiple organizations. I'm not seeing “Organization” in the placeholder list, but I'm also not seeing a way to change organization on a ticket with a trigger. Is there a way to change the organization using a placeholder and/or some other method while forwarding an email?
0
Dainne Kiara Lucena-Laxamana
Hi 5094134994970
That's rather odd. I went ahead & created a ticket to look into that Email trail using the latest comment placeholder. Please keep an eye out for our Email
0
Kiran Yadav
Hi Team, if we are replying to the requester about the ticket and the requester is replying back through their email, is it possible that the requester see only the latest comment and not the other trail mail comments. I have tried using the latest comment placeholder in the trigger but still if the agent replies back the comments are visible in the trail mail
0
Sriram Parthasarathy
Support team, are you planning on getting html-formatted tags to work? We are not able to ask our agents (who all use Outlook) to make sure they switch to plain text email every single time they want to reply to a ticket and use mail api for changing the assignee, status, or adding a note.
0
Patrick Lanwehr
Hi Mike,
just check my comment from the 29.06.2023
I have already added the link.
0
Mike DR
0
Joyce
#brand
is not a supported command for Mail API. All the supported Mail API commands are listed in the Command reference topic of this article.As a workaround, you can use the
#tags
command to add a ticket tag and use this tag as a condition in a trigger to set the ticket brand.Hope this helps.
1
Patrick Lanwehr
Hallo Jennifer,
ich möchte gerne eine E-Mail, die bisher ohne Ticketbezug ist, als internen Kommentar einem bestehenden Tickets hinzufügen.
Im Jahr 2015 gab es dazu mal einen Community-Post mit sehr viel Feedback. Ist das nun die Lösung ?
https://support.zendesk.com/hc/de/community/posts/4409217600666-Ability-to-forward-emails-into-an-existing-ticket
0
Iniciar sesión para dejar un comentario.