Anhand der Mail-API können Sie Ticketeigenschaften festlegen, indem Sie zum Text einer E-Mail-Antwort auf eine Benachrichtigung oder einer E-Mail, mit der ein neues Ticket erstellt wird, Befehle hinzufügen. Nur Agenten können die Mail-API nutzen. Wenn Endbenutzer diese Befehle verwenden, werden sie von Zendesk ignoriert.
Im folgenden Beispiel sehen Sie, wie ein Agent den Status und den zugewiesenen Mitarbeiter eines Tickets in einer Antwort auf eine E-Mail-Benachrichtigung einstellt:
Ein Agent kann die Befehle auch in einer neuen E-Mail an die Supportadresse des jeweiligen Zendesk Support-Kontos angeben. Durch diese Art von E-Mail wird ein neues Ticket erstellt.
Syntax
Die Mail-API sucht am Anfang einer E-Mail nach einer Liste von Befehlen, die ausgeführt werden sollen.
Diese Befehle müssen in reinem Textformat (nicht HTML) eingegeben werden und dem folgenden Muster entsprechen:
#command value
Wenn Sie beispielsweise den Status eines Tickets festlegen möchten, können Sie folgenden Befehl verwenden:
#status solved
Jeder Befehl muss in einer separaten Zeile eingegeben werden. Wenn Sie beispielsweise den Status eines Tickets und den zugewiesenen Mitarbeiter festlegen möchten, können Sie folgende Befehle verwenden:
#status solved
#assignee jake@zendesk.com
Geben Sie den Text der E-Mail nach dem Befehlsblock ein.
Befehlsreferenz
Nachfolgend sind alle unterstützten Befehle aufgelistet, die Sie in einer gültigen E-Mail verwenden können. Jeder Befehl muss in einer eigenen Zeile stehen. Die Liste enthält auch aus einem Wort bestehende Kurzbefehle, die anstelle der normalen Befehle verwendet werden können. Bei diesen Kurzbefehlen braucht kein Wert angegeben zu werden. So können Sie beispielsweise einfach den Kurzbefehl #solved
anstelle von #status
solved
verwenden.
Befehl | Beschreibung |
---|---|
#status
|
Gültige Werte: „open“, „pending“ und „solved“. Hinweis: Um ein Ticket auf „Gelöst“ zu setzen, muss der Befehl #assignee verwendet werden. Kurzsyntax: #solved funktioniert nur bei Tickets, in denen der Agent keine erforderlichen Felder ausfüllen muss, bevor sie gelöst werden können. |
#requester
|
Legt den Anfordernden für das Ticket fest. Gültige Werte: die Benutzer-ID der Person in Ihrem Konto oder ihre E-Mail-Adresse. Wenn der Benutzer noch nicht in Ihrem Konto vorhanden ist, wird er von Zendesk erstellt. Dieser Befehl ist für Light Agents nicht verfügbar. |
#group
|
Weist das Ticket einer Gruppe zu. Gültige Werte: Name oder ID einer Gruppe.
Dieser Befehl ist besonders bei der E-Mail-Weiterleitung hilfreich. Wenn ein Agent eine E-Mail an Zendesk weiterleitet, ist das entsprechende Ticket standardmäßig entweder nicht zugewiesen oder der Standardgruppe des Agenten zugewiesen. (Weitere Informationen finden Sie unter Übergeben von E-Mails an Ihre Supportadresse.) Agenten können das weitergeleitete Ticket mit diesem Befehl stattdessen automatisch der angegebenen Gruppe zuweisen. |
#assignee |
Weist das Ticket einem Agenten zu. Gültige Werte: E-Mail-Adresse des Mitarbeiters oder seine Zendesk Support-ID (z. B. über eine REST-Integration abgerufen). Bei Verwendung dieses Befehls werden Sie automatisch zu einem Beitragenden (CC) im Ticket. |
#priority
|
Legt die Priorität des Tickets fest. Gültige Werte: „low“, „normal“, „high“ und „urgent“. Hinweis: Sie können nur dann eine Priorität festlegen, wenn Sie auch einen Tickettyp festlegen (siehe unten). Kurzsyntax: |
#type |
Gültige Werte: „incident“, „question“, „task“ und „problem“. Kurzsyntax: |
|
Fügt Stichwörter zum Ticket hinzu. Wenn Sie mehrere Stichwörter auf einmal eingeben, sind diese durch Leerzeichen oder Kommas zu trennen. Hinweis: Beim Hinzufügen neuer Stichwörter werden alle bereits im Ticket vorhandenen Stichwörter entfernt. |
#public
|
Macht die Kommentaraktualisierung im Ticket öffentlich sichtbar. Dieser Befehl kann nur beim Aktualisieren eines Tickets verwendet werden. Bei öffentlichen Tickets lautet der Standardwert „true“, was bedeutet, dass der Anfragende alles andere sehen kann, was Sie im Text der E-Mail eingeben. Bei privaten Tickets wie solchen, die von Light Agents erstellt werden, lautet der Standardwert „false“. Kurzsyntax: |
Ungültige Befehle
Ungültige Befehle oder Werte werden von Zendesk ignoriert.
Beispiel
Im folgenden Beispiel verwendet der Agent alle verfügbaren Befehle.
Durch diese E-Mail werden in Ticket #178 folgende Aktionen durchgeführt:
- Der Status wird auf „offen“ gesetzt.
- Die Gruppe wird auf „Support“ und der Mitarbeiter auf den Agenten mit der E-Mail-Adresse „jonas@zendesk.com“ gesetzt.
- Die Priorität wird auf „normal“ gesetzt.
- Der Tickettyp wird auf „Frage“ gesetzt.
- Die Stichwörter „hilfe“ und „api“ werden hinzugefügt.
- Die Sichtbarkeit des Kommentars wird auf „privat“ gesetzt.
- Der neue Kommentar „Hallo Welt!“ wird zum Ticket hinzugefügt. Er – und die Befehle darüber – sind für den Anfragenden nicht sichtbar.
28 Kommentare
Gail Day
Any chance of introducing a CC (copy) Mail API tag? We have a third-party form that creates tickets via email, and this would be useful.
0
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
Anmelden, um einen Kommentar zu hinterlassen.