Jump to content

Keith

Hornbill Users
  • Posts

    524
  • Joined

  • Last visited

  • Days Won

    17

Posts posted by Keith

  1. @James Ainsworth Thanks for responding.

    I don't use the notes feature (had either forgotten about it or missed its announcement), but I will in future :) .

    However, I was thinking more of a high level documentation/process flow showing services available, SLA's for those services, Routings etc. Originally I had designed this as a table, but I have been asked to produce a process flow and have started to draft something but it gets messy very quickly (see below). Note: I haven't even added in Catalog Items yet. 

     

    image.thumb.png.088a3f935af786e654c27d53f258c13c.png

     

     

  2. All,

    Does anyone have any good examples of how you have documented the process flow for your high level basic workflow. There are so many variables (services, catalog items, teams, routings, BPM's, progressive captures) that I'm finding it to be an almost impossible task.

    Would really love to see some examples. 

     

    Regards

     

    Keith

  3. @Michael Sharp as usual @Martyn Houghton beat me to it :)

    As Martyn states, the New status would need to be explicitly set in your BPM. We've never used the new status though TBH. 

    We have a really complex routing structure with many multi national teams supporting different aspects of the same service/BPM. Using the logging category along with site is absolutely essential for us with lots of decision points in the BPM to assist with the routing. Ideally you should route to a team rather than naming an individual in your BPM. Individuals will change over time making it difficult to administer the BPM. I mostly just route to a team and have them monitor and manage from there but you can set this to round robin if you want to spread the load more evenly but I find that letting the team decide who is the most appropriate person to deal with the call works for us.

    I'll defer to someone else on the widgets as we mostly use PowerBI but it sounds like it should be possible.

    Regards

     

    Keith

     

     

    • Like 1
  4. When creating an FAQ it is possible to embed screenshots for added information. However, when accepting the FAQ as a solution these images do not copy into the resolution along with the text which limits their usefulness.

    Could you added functionality for the images to be brought into the resolution in future?

    • Like 1
  5. Hi James,

    The #1 reason for cancellations is by far due to users raising requests under an incorrect service. This has all kind of implications as I'm sure you appreciate i.e. different BPM, different supporting teams (means we can;t actually allocate the request to the correct team)  etc.

    In my view these are incorrectly created. If I resolve/close them they impact my statistics, artificially inflating the number of incidents since we end up with two requests being raised for the same event (after we create one under the correct service). Since this is so common we have extended the right to cancel to all analysts.

    I don't understand why you would think the user would know nothing about the request, since they are the one raising it via the service portal. So simply cancelling a request and not telling them why would surely confuse them more?

    From discussion in the thread below we are not alone in the need to cancel requests.

     

  6.  Hi @samwoo I like your thought process but my concern would be that the user then has two requests open for essentially the same issue which may cause them some confusion. I can't help but think its just cleaner to cancel the initial request after linking it to a new request. 

    Plus, I like that it is cancelled as I just ignore all cancelled requests in any reports so I'm not inflating my statistics with duplicated requests.

     

    Regards

    Keith

  7. We almost exclusively use the self service portal which in combination with users being restricted from some services, leads to requests sometimes being input under an incorrect service.

    I see our analysts taking several approaches.

     

    1. Cancel request and ask user to create correctly. (not very customer friendly)

    2. Cancel the original request and raise a new request on the users behalf under the correct service. (causes some confusion on end users part to understand why their original request is cancelled)

    3. Create a linked request of the correct type then cancel the original request.

    4. Handle the issue under the incorrectly raised request (I hate when they do this :) )

     

    How are you guys handing this and or enforcing thats its handled in a specific way?

     

    Appreciate any input.

     

    Keith

     

     

     

×
×
  • Create New...