Topics for discussion
The only topic discussed at this meeting was "Relationship with IS
Helpdesk". This was examined at some length, with the use of the
whiteboard to aid proceedings. Some of the
main points to come out of this were:
- There are three options:
- Stick with RT (and implicitly do first-line processing
of our own calls); or
- Use Unidesk, with calls going straight into an Informatics queue
which we would process ourselves; or
- Use Unidesk, with calls initially going to the IS Helpdesk team,
who would handle what they could and pass anything they couldn't to the
appropriate second-line teams (including us).
- We should analyse the options rigorously.
- We shouldn't change unless the service for the users would be at
least as good and ideally better. They're unlikely to accept an
additional step and resulting delays unless there's an obvious benefit.
- If users find Unidesk too painful they're likely to resort to
the support desk or buttonholing specific C(S)Os instead, which is one of
the reasons we set up the RT system in the first place.
- The IS Helpdesk would give us some out-of-hours cover.
- Could we do different things for different categories of users,
within the Unidesk context?
- We could have one Unidesk Informatics queue, or we could (probably)
have second-level queue(s) if we thought it necessary.
- By default, everyone can read Unidesk tickets. This is a matter of
queue policy. We have to be aware of DP and confidentiality
issues. There would be
pros and cons in making our queue(s) private, and it's hard to see how
we could maintain privacy if we were to use the IS Helpdesk.
- We would have to run an RT installation for the ISS and Forum-issues
anyway, and the marginal cost of running a third is negligible.
Unidesk would not be suitable for ISS use, due to DP and training issues.
- In overall cost terms, Unidesk is perceived as so relatively
inefficient to use that the additional cost would more than outweigh
any RT support costs.
- It's easy to skim RT, so people do. It's unlikely they would take
the trouble to do the same with Unidesk.
- Unidesk has some general issues: ticket dateline issues, specific
browser versions, overriding normal browser behaviour
- ... and some specific bugs (responses can create a fresh ticket, with
possible privacy issues), reporting features broken, ...
- RT is intuitive to use, and needs practically no training, whereas
Unidesk training is pretty much essential in order to use the system at all
- If we were to use Unidesk it should be easier to pass tickets to and
from IS as required
- ... but there was some doubt as to whether this would outweigh the
general inefficiencies of using Unidesk in the first place.
- Unidesk tickets we create are often (usually?) passed back to us to
"solve", though this may be partly documentation and (Helpdesk) training.
- "Graham's Unidesk rant" actually has
contributions from several other people too.
- See also the whiteboard notes.
Yan will trawl a selection of our past tickets, to see how they might
have been handled under the Unidesk options, and how this would compare
against our own RT-handling of them. Once that's done, Alison will try
to write this all up coherently...
[Post-meeting comment: Alison's write-up is