This entry is part of a series: Artemis 2»

One of the original observations that led us to build Artemis 2 was that each client has a different process for managing work requests. This difference also extends to the actual type of work request the client needs.

As a coding company, we tend to receive a variety of requests that require detailed back and forth communication to fulfill. The original Artemis handled this kind of back and forth very well. However, lots of companies receive requests that are similar and simply kick off one of a few standard processes. For example, one of our clients, Southside Market Place (SSMP), publishes a monthly black and white real estate magazine. They only deal with one type of request; I would like to place an ad in the magazine. The type of ad and some of the particulars are different but what SSMP really needs to see is where each ad is in the process:

Does the typesetter have the copy and the photo?
Has the typesetter sent the client a proof?
Did the typesetter get changes from the client?
Did the typesetter send a reproof?
Has the ad been set in the paper?
Has the ad been billed?

Southside Market Place deals with hundreds of ads per month and employs a number of off-site typesetters to do the work. The communications between all the various people needs to be up to date for any given moment. For this type of client the original Artemis would have been less than deluxe. Adding a new note each time when all you really need to say is “yes, I got it” or “yes, I did it” would be a total nightmare. This led us to a simple conclusion; If it takes longer to update the request than it did to perform the actual task, something is very, very wrong.

We needed a special type of request, one that was based in a process.

This led us to augmenting a basic request with a series of checkboxes to represent the process the client uses. This allows the client to enter the details of the request and even notes as before. However it also lets them just check off items in the process as they are completed. This makes it much quicker the deal with a process centric ticket than it would be in a standard request system.

This also gives us some interesting options for streamlining with different user types. Many users will only deal with the step by step aspect of the process, so potentially they could get an interface that allows them to deal with multiple tickets at once. Managers could get a quick overview of where each ticket is within the process, allowing them to make quick decisions on where resources should go.

The steps in the process could also be designed with a few variations in mind; steps could be optional, dependent on another step or alert another user when the step is completed.

The big bonus for us is that the way Artemis 2 works, this kind of option is basically a change to the request object, not the entire system. Flexibility is good.