Record Producer Variables Best Practices

[Derek Jones1]

All, 

Like most of you, our portal has several record producers that generate incident tickets around typical issues such as login issues, hardware break/fix, and software faults.  Also, like most of you, the record producers have a few lines of scripting behind them, linking the “current” and “producer” fields in addition to some variables, which allow us to gather preliminary triage information.  These collected variables are then exposed to the resulting INC via the work notes, assignment group, descriptions, etc. 

None of this is new or problematic, of course, but we’re left wondering if this is the best or even the only way.  We understand that a record producer gives non-ITIL-enabled users write access to the incident and other similarly restricted tables to understand its general purpose.  However, is there a better way for gathering data from end-users via a portal for incorporation on an incident record than RPs?  

Thanks! 

[bammar · Accepted solution]

I support and agree with how and what your doing with variables etc. If any of my advice below is obvious or something moot or something you already do disregard.

End users by Virtue of emailing ServiceNow to have a ticket autocreated by system OR filling out Record Producers / Service Requests using Self Service - stay in the Requestor Pool ( aside from an integration or them calling in/chatting and having an itil user create a ticket ) . If they created the Incidents or Requests by Direct Table/Application like ITIL users via FORM view access they would be Fulfillers and cost alot of money.  I will explain why I cant think of anything better than a record producer and how I try to make them work well for everyone.

1- Record producer can be filled out 24/7 - no human labor(helpdesk cost) to collect the original ticket data. Record Producer collects all the data a human would have asked to start the work. Record Producer can route to the appropriate group automatically since it has all data required.

2. Email - SO Easy for customer but the data is hard to classify- hard to set cat, subcat, prio from an email. Emails often have incomplete data so they have to be routed to general helpdesk ppl for vetting- callbacks may be necessary to collect additional data required before escalation or closing. Ticket will need to usually be manually escalated and if the queue is large and they do tickets in order received ticket can languish

3. Integrations are brilliant but how customer friendly is the other system and how many integrations do you need to be the source of all disparate request.

4. Calling in/Chatting - $ call centers, season staffing, hold times, inconsistent service, paying by the call, is there a premium for 24/7 service? Self Service chips away at the calls and yields less cost to manager operations. Chat with a human is also a cost. Chatbots could be interesting in the future if they are built out they can build the proverbial Record producer. 

I definitely believe fundamentally when it comes to Record Producers nothing is broken and this is the way its meant to be. BTW a user going to the Self Service Portal usually does not know or care about the minutia and the underlying tables and if it is really a request or a Incident -  They need a visually appealing, customer friendly area that they use to get help in an efficient manner.

Now to suggest things that may get to the heart of any doubts or curiosity - is this the best way or is there something better- I can suggest but without assuming your doing this already- things that make the customer and admin life easier.

A. If you can collect information by virtue of know the user who is logged in- automate it- For instance on a Record Producer prefill their name.

B. Ask questions in customer speak ( then map it to field where applicable)- A Question for a mapped field in in the Record Producer is a field in the table- would be too much if the fields were questions for itil users

C. Use variables like you do to ask those lead questions to help inform support ( Also great thing about variables is since they are in Record producer - you wont have to create a field in the Incident table for them since you can collect the data to going UI actions or scripts on form OR parse the text as you allude to and add to work notes) - This alone is huge as no one can afford to make a real field in a table for every variable in all the record producers

D. Reuse Variable Sets - reuse variable sets when you create new record producers

Tired now but if you read this far and forgive my spelling you see where im coming from

[Derek Jones1]

Yeah, we're pretty much on the same page on this, as far as having the script pull in any caller data, keeping the questions simple and "geekSpeak free" and using MRVS.  The idea of using variables to trigger UI actions or other scripting isn't something we're currently doing so that warrants some thought to see if there's something we can do there.  

Thanks for all the work on your post!

[bammar]

My Pleasure- Yes definitely use UI action or scripts to guide the user sort of like a decision tree or a mimicing of what a knowledgable person would ask them on a phone call.

This makes the Catalog items more dynamic and allows different resulting actions, escalation paths etc as well as saving a person from answering questions irrelevant to their case