I have been talking informally with Oliver Thomas and Lisa Robinson in Customer Support about ways to integrate our work with theirs and ways to learn from them what our customers are thinking and doing and having problems with.
I came up with the following ideas:

  1. Using RAFT 3 rollout as a pilot of some sort. One thing that would be easy for us to do would be to provide a link in the footer that said "Create RAFT Help Ticket". It could easily pass along a ton of RAFT 3 data(browser, Operating System, User, current error if any, and any relevant RAFT data) to a specific RT queue. We could also just have some sort of feedback arrangement with CS (Lisa?) where once a month we got a report of ALL RAFT-related RT tickets.
  2. Similar idea, maybe same code as above: when the app throws an error condition, call the code to make an error report form appear, pipe into the form the current state of the application (what application, what page, what browser, what OS, etc.) User describes what they were doing and clicks send, form posts to RT in the RAFT queue.
  3. Work with CS to mine the RT data for all RAFT/Cognos/Space/Data Warehouse tickets and again look at the report periodically to learn what is going wrong.
  4. The metadata project could benefit from interviews with CS and again mining RT data for what kinds of questions users ask about metadata-related issues, where metadata in this case includes Business Actions (Create a PO, Annual Salary Review, Create a Budget, Approve a Requisition), the associated Roles, associated Reports, associated applications, associated DataWarehouse Packages and feed code and tables, etc.

Item 1 and 2: Creating Help Tickets that have technical information filled out for the user:
This development project would solve the following problem: Customer Support gets a bug report for a web application, but the user does not know or report on what browser, what operating system, and what page did the bug occur, which forces CS to ask those questions and teach the user over the phone how to answer them, or in the case of email, to never get those questions answered. This in turn costs each application development team time trying to reproduce a bug that is not fully described.
The solution is relatively straight-forward: create a small JavaScript program that when called opens up a window with a small form prepopulated with browser version, operating system version, page the bug occurred on , and any error message. The user then fills in just what they were doing at the time and clicks send. The form submits to cgiemail or another emailing service, which then sends it on to the customer support RT queue. The user gets an email back with the ticket number, as per usual and from the their the normal CS bug reporting workflow continues.

  • No labels