Intranet Management Software Blog

I come across an issue regularly when creating Infocapture (Process Manager) projects…

How to name the statuses appropriately?

I’ve so far concluded the following;

It depends on the project that you are creating

• How complex is the project
• How critical is the process that the project will control

It depends on the audience of the project and who will be interacting with the project

• Users with limited technical understanding or IT competence may require very simple status titles to ensure that they are not confused
• More technically competent users may be confused by a very simple status naming convention

It depends on the workflow within the project

• If the work flow is very simple, you are likely to  have statuses that reflect this.
• If the work flow is complex (perhaps even requiring an approval process), your statuses will be used to assist in the implementation of this.

Here is an example I’ve just run into…

The first status of almost every project is something along the lines of…

• New
• Submitted
• Received

All of those first status titles tells the users a single value of where the issue/ticket is at… but it’s static… it doesn’t say what it’s awaiting for…

What does “New” mean…other than it’s new… Who’’s attention is it pending?  Is it pending attention at all?  Does it require approval?  If so, by who??

Sure, we can send notifications to the person it’s pending some attention from, but what about everyone else who see’s this… what does it mean to everyone else?

In an attempt to provide clarity on this to all users, I tend to create statuses with a dual title…

• New - Pending IT
• Submitted - Awaiting Approval
• Received - Being Processed by IT

However, in doing so, I think it’s easy to potentially get carried away and end up with a status such as…

• New - Pending further information from IT before being approved and sent to HR

My solution - A compromise…

1. Chose clear and meaningful statuses that are targeted to the audiences that will be involved in the project.  “Dual statuses” help achieve this… (see examples above)
2. Try not to define static statuses such as “New” or “Approved” - These are only likely to mean something to a percentage of the overall audience.
3. Use the description fields within the form to describe the work flow and process to all users.
4. Be clear in your notifications to users about what they should be doing in order to get the ticket moved forward

I would be interested in hearing alternative opinions and approaches…

Prod-Process e-forms, infocapture, processes, statuses