Interpreting user-specified metadata

The problem with allowing users to specify metadata when they file a request is it doesn’t always mean the same thing to them as it does to those who handle the requests. Even if you supply definitions, users won’t necessarily read the definitions, and even if they do, interpretation differs. For instance, urgency: something may be incredibly urgent to that user in the sense that they feel dead in the water until that issue is resolved; however, if that issue affects only them, it’s probably more important to take care of an issue like a downed research group server first. (Even that is fraught; like most organisations, we have a few users generally deemed to be more important than everybody else, even if we pretend that everybody’s equal.)

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?