C4C ticket routing

[Former Member]

Hi guys,

We are looking at options for ticket routing based on post code and customer service priority.

1. By Post code

In the standard Organizational Work Distribution Rule view, there is no option to base the routing on customer address e.g. post code. Is there a standard way or any workaround to achieve so?

2. By Priority

Routing based on service priority is an available option, but my understanding is this priority is for the ticket itself. Is it possible to build it on a priority within customer master? e.g. ABC classification or a custom field? Otherwise we may need an enhancement to default the service priority code of the ticket based on customer master data.

Thanks,
David

[Former Member · Accepted solution]

Hi David,

Have you considered using Territory routing instead of Org-based routing?  It was delivered with release 1502.  You can access the routing rules from Administrator -> Service & Social Settings -> Ticket Routing Rules.  There we have used a more flexible engine, which allows you to define routing rules by customer postal code, customer category, extension fields, etc.

The concept of Territory is inherited from Sales, but it does not need to necessarily represent a geographical area.  You can define territories as queues, e.g. the C4C territory and the HANA territory, assign agents to one or more territories, and then have them monitor tickets using the standard query "Tickets in My Territories".  You can also configure "Get Next Ticket" to only pick tickets from the agent's territories.

The first step is to define the Territories based on your routing needs.  You can define them as a flat list under the root.  Then assign agents to one or more Territories (this is not possible with Orgs). Finally, define the routing rules.

More flexible Org-based routing is also planned, but if you need to move forward with 1505 I would use Territories.

Kind regards,

Gab

[Former Member · Accepted solution]

Hi Gabriele,

Thanks a lot.

In the administrator guide 1505, it still says "

As of February 2015 access restrictions for tickets are still determined solely by organizational structure. Be sure that territories and organizational structures are aligned to ensure proper access to tickets. ". Is this still the case in 1505?

If we use territory routing, when a ticket is routed to one territory, there is still no owner of the ticket yet, how does the organizational structure come into play?

Also we are considering use territory management for sales, so could we setup 2 sets of territory definitions, one for sales, one for service without impacting on each other? Would realignment be an issue?

Thanks,

David

[Former Member · Accepted solution]

Hi David,

As of 1505 we still do not support territory-based access restrictions.  That feature is currently on our backlog.  Do you need to define access restrictions?

Having Territories for both sales and service will not cause issues.  You'll have to create two sub-nodes under the root, to separate your sales and service territories.  The realignment would not be impacted:  when you define the rules that assign accounts to territories, simply ignore the service territories (and vice versa when you define the ticket routing rules).

Kind regards,

Gab

[Former Member · Accepted solution]

Hi Gab,

Much appreciated! Could you confirm my following understanding is correct?

1. We only define rules to assign accounts to sales territories but not service territories (so account team of service territories are not passed onto accounts.)

2. Define ticket routing rule to assign tickets to service territories

3. Technicians who are assigned to the service territories to which tickets are assigned or higher level territories can see tickets in "Tickets in My Territories" query, but they can still see all tickets in "All" if there is no additional access restriction by organizational structure.

Additionally if we want to add access restrictions by organizational structure on top of above, since the tickets are routed to territories and there is no account team of service territory populated into the accounts, would organizational structure restriction work at all? How?

Thanks,

David

[Former Member · Accepted solution]

Hi David,

1.  Correct

2.  Correct

3.  Almost correct.  "Tickets in My Territories" considers only Territories to which I am actually assigned, not those at a lower level hierarchically.  "All Tickets" works as you describe.

Org-based access restrictions would only work once a Team is assigned to the ticket.  This can happen for example when an agent takes over the ticket.  So you could for example define restrictions so that "when a tickets is taken over by the Legal department, nobody outside the Legal department can see it".  If possible, however, I would avoid mixing territory routing with org-based access restrictions. 

Kind regards,

Gab

[Former Member · Accepted solution]

Hi Gab,

Thanks so much! Absolutely agree on avoiding mixing territory routing with org-based access restrictions!

If we dont need org-based access restriction, do we still need to use team concept for ticket processing, or just keep going with territory and direct assignment to employees? (would org still be helpful for reporting?) What do you suggest if territory routing is used?

Just one more question regarding the sales territory side. Is territory account team separate to those partner functions from ECC which are sales area dependent? So the territory account team will exist in parallel? So when a customer replicates from ECC to C4C, who will be assigned as the owner of the account by standard?

Regards,
David

[Former Member · Accepted solution]

Hi David,

That's a bit beyond my expertise.  Let me find out.

Thanks,

Gab