Our own silly take is allowing an urgency of "24 hour", along with "not", "urgent", "emergency", and "by date". For instance, I see a request outstanding in our system right now that is essentially a user asking for some education on the use of the rm command; it has the urgency flag set to "24h". What does that mean? I don't know, but the user set it. Looking at the item, I see she probably set it because after 24 hours, the answer no longer really mattered; she'd already taken care of it herself. However, it will become an issue again next term (she was cleaning out course accounts). So now what? We're discouraged from changing urgency flags ourselves - the user set it, after all - but clearly, the matter is no longer very important (until 2 January 2008 or so, at which point it will again presumably attain "24 hour" urgency again). Our documentation states:
The "Urgency" field in the Create Request form provides an indication of how urgent the request is to the person for whom the work is being done. It is used to determine a rough starting position for the work in the "Upcoming Projects" part of the work queue, unless of course it's an "Emergency", in which case it's added to the "Emergency" section at the top of the queue.Clearly our documentation needs to be updated, as it doesn't include this 24 hour notion, but I suspect it would go something like this: "An item which, if not resolved within 24 hours, ceases to be important, and so may get done on an 'as time allows' basis, or not at all." Neither of these outcomes are generally satisfying to the user; in fact, the former is often a synonym for the latter, and not just in our organisation.
In any event, without reading a request in its entirety, this particular flag is meaningless, and due to differences in interpretation, it may actually impede communication. We like to allow our users to feel "in control", even if they're really not - but how far should we go in so doing?
