Allow light agents to use agent forwarding

6 Comments

  • Andrew J
    Community Moderator

    This used to work as it was part of a workflow we designed but didn't implement some years back.
    Perhaps open a support request.

    1
  • Amy Dee
    Zendesk Customer Care

    Hi Daniel! The reason is called out in our article on forwarding email:

    Note: This feature is available for agents, but not light agents. Light agents are excluded because it involves making a public comment on behalf of an end user on a ticket.

    In the past, there were some loopholes that could allow light agents to perform tasks they shouldn't have had permission to do. Many of those loopholes have since been closed.

    The current restrictions are expected - light agents can't make public comments, so they can't create public tickets through forwarding.

    I hope this helps!

    0
  • Kelsey Davis

    Amy, thanks for explaining - why can't the comment come in on behalf of the original requester but just as a private comment? Thanks

    1
  • Oscar Tobar

    If I understand correctly, based on documentation, connecting with your support team, and our own testing, Zendesk allows for:

    • A light agent submitting a ticket for themselves with a private comment and it will trigger an SLA
    • A light agent CC's "support@" and that ticket still triggers an SLA (this workflow was always taught as the "wrong way" of creating/forwarding a ticket on behalf of a customer)

    But Zendesk doesn't allow for:

    • A customer emailing an employee and that employee (as a light agent based on role) forwards the email to "support@" which is then recognized by SLA rules, placing the ticket in the SLA-organized queue.

    I understand the "loopholes" were closed in an effort to prevent light agents from making public comments. What I don't understand is why the system won't recognize that the private comment is from an actual customer and then applies an SLA. Currently, tickets with no SLAs will end up at the bottom of our queues (if a team works from an SLA breach sorted queue) and requires teams that are leveraging your SLA functionality to always be checking the end of a queue for any forwarded tickets.

    This seems like a rule in your system that isn't aligned with workflows suggested by Zendesk for many years. We're left with trying to figure out alternative solutions that create more manual work or adding licenses JUST to forward tickets. 

    2
  • Greer Davis

    We also heavily rely on SLAs, and this is an incredibly common scenario whereby customers will email the CSR vs Support and they forward it to us. CSRs don't need any access to tickets other than viewing and internal comments, so there's no need for us to pay for them to have accounts. But when comments come in as internal, the threading can get strange from the customer's perspective (support emails me but I don't see my original comment).

    We act as Tier 2 for our customers, so we tend to deal with the same smaller subset of users. If the person already has an active account in the Help Center could there be some scenario where only the initial comment by the end user is posted publicly and any subsequent comments in the thread are private? Or, is there some way for a full agent to convert a comment to public? I would say this is a solid 30% of the way our tickets are created and it's getting negative feedback from customers.

    1
  • Paul French

    This recent "closing of loopholes" has made a mess of our workflow too, and like Oscar Tobar and Greer Davis above we were using this function legitimately and not to avoid paying for licences. (CSM forwarding client emails)

    With this change, customer comments forwarded in by light agents are private (and hence NEVER show within Help Centre), so we have used a semi work around by building a macro and using the {{ticket.description}} placeholder. The formatting is terrible however at least the end user can see the original comments.

    Additionally, SLAs are not set so have to be set manually, wasting resource and time.

    This change is also causing us to consider moving as the user experience is awful.

    0

Please sign in to leave a comment.

Powered by Zendesk