Creating tasks for interaction

Hi All!

Does anybody know how can I create tasks (like for incident and request modules) for interaction? Is it possible in SM?

We use SM 9.40

  • Everything is possible. The question should be: "How much..." (just kidding)

    You should make sure that this is really necessary. Can you explain what's the objective?

     

     

  • Hi @BrenoAbreu,

    it's a request of our customer. We have special scenario that should be implemented in the system: simple interactions and complex interactions with several tasks assigned to different operators/departments. So, maybe we could use request object for this purpose or could you advice something else?

  • You can follow thw way for incident or rqeuest module.  :)

  • By ITIL definition, an Interaction _isn't_ something complex.  An Interaction is intentionally simple.  The customer contacts the help desk with a problem.  If the help desk can solve the problem right away, the ticket closes and the customer goes away.  If the help desk cannot solve the problem right away, they escalate the ticket to one of the other modules.  If something that is supposed to be working is broken, that's an Incident ticket.  If something exists but needs to be modified, or something brand new needs to be created, that's a Change ticket.  If the customer needs access to goods or services that already exist, that's a Request ticket.  

    There's also relationships between those modules (like an Incident that might need a Change to resolve, or multiple groups working together to solve the Incident or whatever).

    Once a ticket is escalated, the customer still sees updates in his Interaction, and some companies have the help desk work almost like a concierge - a single point of contact between the customer and the organization that is working to meet the customer's needs - but that additional workflow is not done in the Interaction itself.

    But Interaction is, by its definition, meant to have a simple, straightfoward workflow.  So if someone is pushing for an Incident-like workflow in Interaction, remind them of best practices, ITIL, what each module is meant for, and then remind them that breaking that workflow will be costly and ineffective.  It's much better to let the tool do what it's designed to do, rather than forcing the tool to work against itself because one guy doesn't know the difference between the modules.

  • By ITIL definition, an Interaction _isn't_ something complex.  An Interaction is intentionally simple.  The customer contacts the help desk with a problem.  If the help desk can solve the problem right away, the ticket closes and the customer goes away.  If the help desk cannot solve the problem right away, they escalate the ticket to one of the other modules.  If something that is supposed to be working is broken, that's an Incident ticket.  If something exists but needs to be modified, or something brand new needs to be created, that's a Change ticket.  If the customer needs access to goods or services that already exist, that's a Request ticket.  

    There's also relationships between those modules (like an Incident that might need a Change to resolve, or multiple groups working together to solve the Incident or whatever).

    Once a ticket is escalated, the customer still sees updates in his Interaction, and some companies have the help desk work almost like a concierge - a single point of contact between the customer and the organization that is working to meet the customer's needs - but that additional workflow is not done in the Interaction itself.

    But Interaction is, by its definition, meant to have a simple, straightfoward workflow.  So if someone is pushing for an Incident-like workflow in Interaction, remind them of best practices, ITIL, what each module is meant for, and then remind them that breaking that workflow will be costly and ineffective.  It's much better to let the tool do what it's designed to do, rather than forcing the tool to work against itself because one guy doesn't know the difference between the modules.

  • By ITIL definition, an Interaction _isn't_ something complex.  An Interaction is intentionally simple.  The customer contacts the help desk with a problem.  If the help desk can solve the problem right away, the ticket closes and the customer goes away.  If the help desk cannot solve the problem right away, they escalate the ticket to one of the other modules.  If something that is supposed to be working is broken, that's an Incident ticket.  If something exists but needs to be modified, or something brand new needs to be created, that's a Change ticket.  If the customer needs access to goods or services that already exist, that's a Request ticket.  

    There's also relationships between those modules (like an Incident that might need a Change to resolve, or multiple groups working together to solve the Incident or whatever).

    Once a ticket is escalated, the customer still sees updates in his Interaction, and some companies have the help desk work almost like a concierge - a single point of contact between the customer and the organization that is working to meet the customer's needs - but that additional workflow is not done in the Interaction itself.

    But Interaction is, by its definition, meant to have a simple, straightfoward workflow.  So if someone is pushing for an Incident-like workflow in Interaction, remind them of best practices, ITIL, what each module is meant for, and then remind them that breaking that workflow will be costly and ineffective.  It's much better to let the tool do what it's designed to do, rather than forcing the tool to work against itself because one guy doesn't know the difference between the modules.