QESTLab Internal

Incident Workflow for Products

The attached document outlines the guidelines and procedure for the investigation of QESTLab 3.3 Incidents by Products. Please familiarise yourself with the document. If required, print a copy and keep it handy.

As of now, the investigation of Incidents takes priority over Bugs and CRs unless told otherwise.

NOTE: For the time being all external correspondence (i.e. from Products to a customer) needs to be directed through a manager. This should change in the future.

The attached document contains a section on “Public Information”; I’d like to reiterate the importance of knowing which fields these are so that we don’t enter any information that was not intended for the customer in them.

Incident Workflow for Products (PDF)

Emailing Customers

When sending emails that are intended to be passed on to a customer then please CC the Customer Manager (in addition to the HelpDesk) too. When appropriate, Vaiju should also be CCed on such mails.

• Please refer to the product as QESTLab and not Qestlab/QL/QestLAB. That is the official branded name of the software. I can do a quick replace in the emails I receive for forwarding but it would save all of us effort if we did this right the first time– not to mention that mails look more polished and professional when we use consistent terms. In line with this, when referring to modules within QESTLab, for the purposes of easy readability, please capitalize the first letters of these words (i.e. “People” and not “people”, “Billing” and not “billing”).

• Avoid using the term “implementation” when discussing possible code solutions (i.e. “This is the proposed implementation for the field density report”). The client thinks of implementation as something that is related (and not limited) to release management, roll-outs, customer management etc. In other words, with the way we work, this term is not used in conjunction with code developments. Use terms like possible solutions/recommended development/feasible enhancement instead.

• We do not “mock” reports (or screens). We send mock-ups of reports. Even better, we send the customer proposed layouts or prototypes.

• Also, wherever possible, use short, simple sentences please. It takes the customer a lot of effort to understand the proposed solution when it is not clearly laid out. Keep in mind that you, as the developer, have already worked out a solution – but the customer does not have this insight (yet).

• If you have multiple attachments to be sent out with the email, please check that you did indeed attach all of them before forwarding the mail on.

• Please reference the attachments in your email clearly – best to refer to the file names of the attachments so as to avoid confusion.

• Lastly, a very obvious one – please spell check and proof-read at least once before sending on the email to BT/DF or to the customer managers. This is not such a huge deal for internal emails but when we have to proof read lengthy emails before forwarding them and re-do certain sections, it slows the whole process.