[rt-users] Need some help with suppliers

[Raed El-Hames]

Bart:

The way I deal with the scenario below is as follow:

1-      Customer ticket about their issue with customer as requestor

2-      Create depends on ticket to the supplier with the supplier as a requestor

3-      We put the customer ticket to status 'on-hold' which we added to the inactive status list

4-      We have a scrip that pushes updates from depends on ticket to the Depended on By as comments (it also changes the ticket status to open) , so when the supplier reply back with the solution etc, this update is trickled into the main customer ticket and the customer ticket becomes active again.
Hope that helps.

Regards;
Roy


From: rt-users-bounces at lists.bestpractical.com [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Bart
Sent: 15 June 2011 07:07
To: rt-users at lists.bestpractical.com
Subject: Re: [rt-users] Need some help with suppliers

Hi,

Our suppliers use different systems and the people dealing with them is our supportdesk. So basically any ticket from our supportdesk "could" rely on an action from our suppliers.

Creating a "depends on" ticket and giving the supplier a user which becomes owner of that ticket could do it, or we could at least make them requestor for that ticket in order to mail them. I think requestor is the best case for us, the main function we need is the ability to mail towards someone else other then the requestor in the "To" field. (I'll explain below)

Something I haven't mentioned, the usual fllow with our supplier is that incidents are called in. So we write down that we've called them + I can make a CF or something like that specifying that it's now with that supplier.
But changes are things that we e-mail towards our suppliers (sometimes incidents too), and that specific action isn't possible by default. You can only mail a requestor + CC a few people (or make a comment and CC that towards someone). In that context the CC option is a problem for us since suppliers expect them to be mailed directly (CC usually means, read but don't do anything).

We could talk to them about it but I want to avoid it and use mail the way it should be used ;)

Best regards,

Bart


2011/6/14 Kenneth Crocker <kfcrocker at lbl.gov<mailto:kfcrocker at lbl.gov>>
Bart,

Do all your suppliers have RT? If not, then who in your organization deals with the suppliers? Perhaps creating a "Child/DependsOn" ticket that is owned by the person dealing with that particular supplier would work.

Just a thought.

Kenn
LBNL

On Tue, Jun 14, 2011 at 5:04 AM, Bart <bart at pleh.info<mailto:bart at pleh.info>> wrote:
Hi,

I need some help understanding the flow of tickets in RT, specifically how to work with suppliers.

In our test setup one questing came forth about sending a ticket to a supplier and how to go about it.
Lets say we have a customer sending us an incident ticket. The incident ends up being the problem of our supplier so we need to have the ticket depend on a suppliers actions.

Our current setup is pretty much default with two queue's for internal departments:

  *   Queues:

     *   Servicedesk: All new e-mails go to this queue.
     *   Tech support: Thirdline support for the servicedesk.

  *   CF's:

     *   A few under users for easy selection of organizations.
     *   And a few for the tickets for selecting to what categorie a ticket belongs to.
     *   In addition I've installed the SLA plugin with two test SLA's.
In our old system we would do these things by assigning a ticket to a supplier, does that mean that I would need to create a queue for each supplier that we work with for this to work?

I'm guessing "yes", hoping "no", for some suppliers having a queue is ok but for allot of other ones it's not ok. We work for the government, some direct suppliers are easy to write down as a queue but sometimes a townhall needs to fix something which would mean that we have to add roughly 450 queue's (one for each townhall).

Anyway, if someone could help me understand how to work with suppliers then I'd be extremely gratefull.


Best regards,

Bart


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110615/f41f9c4d/attachment.htm>