Búsquedas recientes
No hay búsquedas recientes

Amy Dee
Incorporación 14 abr 2021
·
Última actividad 18 nov 2024
Seguimientos
0
Seguidores
4
Actividad total
86
Votos
29
Suscripciones
18
RESUMEN DE LA ACTIVIDAD
INSIGNIAS
ARTÍCULOS
PUBLICACIONES
COMENTARIOS DE LA COMUNIDAD
COMENTARIOS DE ARTÍCULOS
RESUMEN DE LA ACTIVIDAD
Última actividad de Amy Dee
Amy Dee creó un artículo,
Pregunta
¿Cómo se envían los mensajes de correo electrónico entrantes a los tickets?
Respuesta
Cuando se recibe un correo electrónico entrante, Zendesk verifica el correo electrónico en busca de referencias a tickets existentes. Esto determina si el correo electrónico se agregará como una actualización del ticket o si se creará un nuevo ticket.
Zendesk verifica tres referencias principales para encadenar mensajes de correo electrónico:
- Elementos del encabezado del correo electrónico
- ID codificadas en el cuerpo del mensaje
- ID codificadas en la dirección de recepción de Zendesk
1. Elementos del encabezado del correo electrónico
En el encabezado del correo electrónico, References
y In-Reply-To
contienen las ID de mensaje para otros mensajes de correo electrónico en el mismo hilo. Zendesk buscará esas ID de mensajes en los tickets existentes. Si Zendesk encuentra una coincidencia, el correo electrónico se agregará como una respuesta al ticket coincidente.
El encabezado del correo electrónico está visible en el origen del correo electrónico. Consulte el artículo: Ver el HTML y la fuente original de los tickets entrantes para ver los detalles.
Si desea más información sobre cómo resolver problemas con los encabezados de correo electrónico, consulte el artículo: ¿Por qué los correos electrónicos llegan al ticket equivocado?
2. ID codificadas en el cuerpo del mensaje
Una ID codificada es una referencia única a un ticket específico. Zendesk incluye una ID codificada de manera predeterminada en cada correo electrónico de notificación saliente, lo que ayuda a hacer coincidir las respuestas con el ticket correcto.
Una ID codificada se puede agregar a cualquier cuerpo de correo electrónico y no es exclusiva de los mensajes de correo electrónico generados por Zendesk. La ID codificada debe aparecer entre corchetes [1G7EOR-0Q2J]
para que Zendesk pueda detectar la ID.
3. ID codificadas en la dirección de recepción de Zendesk
Las direcciones de correo electrónico de soporte de Zendesk pueden usar alias que incluyan la ID codificada. Por ejemplo, la dirección de correo electrónico de un ticket con ID codificada 1G7EOR-0Q2J
en el subdominio mondocam se vería así: support+id1G7EOR-0Q2J@mondocam.zendesk.com
.
Esta estructura ayuda a permitir que el correo electrónico se dirija al ticket correspondiente, incluso si no hay otras referencias presentes.
Este uso de ID codificadas solo funciona para las direcciones de correo electrónico de soporte de Zendesk y no funciona para las direcciones de soporte externas.
Cómo acceder a la ID codificada
Para encontrar la ID codificada de un ticket, siga los pasos a continuación:
- Utilice el
{{ticket.encoded_id}}
marcador de posición en macros o comentarios de tickets para mostrar la ID codificada. - Use la API de tickets para ver los
encoded_id
parámetro. Este enfoque permite que los flujos de trabajo de la API accedan a la ID codificada sin manipular los comentarios del ticket.
Conversation ID
del cuerpo del correo electrónico, y no Reference
o In-Reply-To
en el encabezado del correo electrónico.Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.
Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.
Editado 17 dic 2024 · Amy Dee
1
Seguidor
2
Votos
0
Comentarios
Amy Dee hizo un comentario,
Hi David Durr !
That is a valid security concern, and it's one that Zendesk shares.
These account exports are always restricted to administrators. Agents don't have permission to see or initiate them. In addition, the account owner can restrict exports to administrators in specific email domains (or disable exports entirely). We have more information in this article: Restricting or deactivating account data exports.
Those settings apply to the account export tools described in this article. It doesn't extend to the API. That said, while agents can access some data through the API, the Incremental Exports API endpoints are all admin-only as well.
I hope this helps!
Ver comentario · Publicado 28 ago 2024 · Amy Dee
0
Seguidores
1
Voto
0
Comentarios
Amy Dee hizo un comentario,
Hi Riah Lao -
Correct again! Zendesk functions - including views, automations, and analytics - use the full timestamp of the SLA target. That means views should consistently show a 1:40 ticket ahead of a 2:20 ticket, even though they both show a “2h” badge. The badge is just there as a quick visual indicator for agents.
I hope this helps!
Ver comentario · Publicado 02 may 2024 · Amy Dee
0
Seguidores
0
Votos
0
Comentarios
Amy Dee hizo un comentario,
Hi there!
Solving a ticket also fulfills all active SLA targets. This includes reply and update targets, which typically require a public comment. In your example, solving the ticket would fulfill the next reply time target, even if the agent didn't publicly respond to “Thank you.”
I hope this helps!
Ver comentario · Publicado 01 may 2024 · Amy Dee
0
Seguidores
0
Votos
0
Comentarios
Amy Dee hizo un comentario,
Hi Riah Lao
Thanks for the question! Your example is spot on. If the time remaining is 2:20, the badge will round down and show “2h.” If the time remaining is 2:40, the badge will round up and show “3h.” The exact halfway point - 2:30 - also rounds down to “2h.”
SLA badges have three different units: minutes, hours, and days. They start displaying the next unit up when that unit rounds to 2. For example, a target of 36 hours and 30 minutes would round down to a “36h” badge. A target of 36 hours and 31 minutes would round up to 37 hours, which then rounds up to “2d.”
There is no unit above “days." If you have a 2-year target, you'll see “730d” in the badge. There is also no unit below “minutes.” When the target is at or below 30 seconds, you'll see “now” in the badge.
I hope this helps!
Ver comentario · Publicado 01 may 2024 · Amy Dee
0
Seguidores
0
Votos
0
Comentarios
Amy Dee hizo un comentario,
Hi Jon!
At this time, there's no way to adjust how first reply time is measured. The system metric will start at ticket creation and end at the first public agent comment after that. The SLA target will wait for a public end user comment to get started (if the ticket was created with a private note).
You could create separate SLA policies for phone tickets. That wouldn't change the first reply target behavior, but it would allow you to manage those tickets and agent expectations separately.
I do have some good news. Our SLA team is hard at work on enhancements that will give users more flexibility over reply time SLA targets. That could help for workflows like yours. I recommend following our Announcements page for more information.
I hope this helps!
Ver comentario · Publicado 15 abr 2024 · Amy Dee
0
Seguidores
0
Votos
0
Comentarios
Amy Dee hizo un comentario,
Hi Hannah!
Schedules are applied to tickets, not SLA policies (or other business rules). For the SLA policy, you just choose between calendar and business hours for each target. If you choose business hours, the SLA will use the schedule associated with the ticket.
Professional accounts only have one schedule, so there isn't much flexibility with business hours. Enterprise accounts can have multiple schedules, though, and they're controlled with business rules. That would allow you to create corresponding schedules and SLA policies for tickets in certain workflows.
We have more information about schedules here: Setting your schedule with business hours and holidays.
I hope this helps!
Ver comentario · Publicado 10 abr 2024 · Amy Dee
0
Seguidores
0
Votos
0
Comentarios
Amy Dee creó un artículo,
Síntomas del problema
- Los usuarios finales reciben una notificación de rebote de Microsoft después de enviar un correo electrónico a una dirección de soporte.
- La notificación comienza con: Su mensaje no se pudo entregar.
- El mensaje incluye un código de error o estado con un
550 5.7.x
. - Los mensajes de correo electrónico no llegan a Zendesk.
El texto del mensaje será diferente para cada problema subyacente. Sin embargo, el problema principal sigue siendo el mismo: el correo electrónico del usuario fue rechazado antes de que pudiera llegar a Zendesk.
Pasos de resolución
Estos errores son generados por Microsoft, no por Zendesk. Zendesk no puede ayudar a resolver estos errores. Si los usuarios informan repentinamente de notificaciones de rebote y mensajes de error, contacte al administrador de su correo electrónico. Deberán revisar el mensaje de error y la configuración de su correo electrónico.
El administrador de correo electrónico de su dominio de correo electrónico puede investigar y resolver estos errores. Microsoft puede haber actualizado sus políticas en torno al reenvío automático de correo electrónico, y eso puede afectar las direcciones de soporte que han estado funcionando sin problemas durante mucho tiempo. Para obtener más información, consulte este artículo: Reenvío de mensajes de correo electrónico entrantes de su dirección de correo electrónico existente a Zendesk Support.
Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.
Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.
Editado 26 mar 2024 · Amy Dee
1
Seguidor
1
Voto
0
Comentarios
Amy Dee hizo un comentario,
Hi @...! A business hours badge could work, but it would require total consistency: one schedule that never changes; no holidays (or exhaustively communicated holidays); all users in the same time zone; no SLA targets in calendar hours, ever.
If there's any variation in any of those points, a business hours badge becomes ambiguous. Multiple schedules, schedule changes, different regions, and different SLA policies all impact how much time is actually left on a target. Agents could no longer take the badge at face value.
Even if there is total consistency, SLA badges round their numbers to hours (or days) when the target is far enough away. This means two tickets could both have a "2 business hours" badge, but one is due Friday at 4:50pm while the other is due Monday at 9:10am. Agents should prioritize the Friday ticket, but they need an easy way to know which is which.
SLA badges in business hours put a burden on agents. Before agents can act on a badge, they'd need to interpret that number in relation to the schedule and their current time. That mental math is taxing, even in simple environments. In more complex environments, it's prohibitive.
SLA badges are designed to quickly prioritize workflows. It's important to ensure that they're all on the same scale, regardless of account complexity, and that the scale is intuitive at a glance. That's why badges show real time remaining. This allows agents to see accurate deadlines, without any extra effort required.
I hope this helps!
Ver comentario · Publicado 16 jun 2023 · Amy Dee
0
Seguidores
3
Votos
0
Comentarios
Amy Dee hizo un comentario,
Hi Leif Cederblom! At this time, Explore only captures SLA durations after the target has been fulfilled. There is no way to create an Explore report that shows live SLA counters for breached tickets.
This is due to how Explore syncs data. It isn't a live feed; it pulls data at periodic intervals. That means it has no way to maintain live durations for metrics. Explore can't tell whether an SLA has been fulfilled until after the next data sync, so durations would be stale.
If you need to monitor active SLAs in real time, we recommend using Views. You can export Views to CSV as well if needed. Explore is better suited for historic reporting.
I hope this helps!
Ver comentario · Publicado 12 jun 2023 · Amy Dee
0
Seguidores
0
Votos
0
Comentarios