Using Salesforce to Manage Users’ Requests – Part 1

In order to manage users’ requests it is important to have a defined process where all requests are processed.  The steps needed to define and implement a process are:

  • Determine the what
    • type of user requests are to be handled in this processNowServing
    • key metrics will be tracked for this process
    • information for each request the user must supply
    • non-user supplied information is needed
  • Determine and implement the how
    • Input channels for submitting a request
    • Salesforce object to use (CASE or custom)
    • Fields (existing and new)
    • User Experience (Page Layout(s), Existing fields to use, etc)
    • Data Quality (validation rules)
    • Setup appropriate components within Salesforce
  • Determine communication
    • Reports and dashboards
    • Training
    • Release Communication

In part 1 of Using Salesforce to Manage Users’ Requests we will be addressing the “what”.

Type of User RequestsDM Gears1

Users may ask you for many things which can be grouped into the following general types:

  • Information: how do I do something, how does this work
  • Issue: can you fix my problem
  • Functional Need: I need system to do this

In your request management system you will need to decide if you want to handle all three types of requests through the same system.  In some organizations production problems (issues) may already be handled through a different application or process.  For this series of posts we will assume that our request management app will handle all three types.

Key Metrics

If you don’t measure your process, metrics1
you can’t manage or improve your process.

With every process and system you need to define your success criteria so you will know if what you created is meeting everyone’s needs and performing well.  You must therefore identify some key metrics upon which you will monitor and evaluate the request management process and app.  As you are considering what to measure remember that every metric should lead to a management decision.

Some suggestions are shown below.  The KPI Library is a great resource for ideas on metrics.

  • Time to Completion by request type

For each type of request define what an acceptable completion time will be and communication that to the users.

Example:  Information requests will be completed within 72 hours; Issues will be acknowledged within 1 hour and addressed within 24 hours; Functional change requests will be acknowledge within 4 hours, vetted within 3 days and completed within 2 weeks.

  • Hours to Complete by Request Type

For each type of request capture number of actual hours worked to complete it.  This information can be used in a metric called

  • Percent of requests by priority

This metric reflects the size of the potential risk of urgent changes on the quality and performance of the change management process.

User Supplied Informationclipboard2

What information should a user be required to provide when submitting a request.  The information will probably vary depending on the type of request.

For all requests I suggest gathering the following:

  • Requester’s full name and contact information (at least phone and email)
  • Type of request (Information, Production Issue, Functional Need)

Below is a suggested list of information based on request type:

  • Information
    • Question
    • Why do you need the information
  • Issue
    • Description of Issue
    • When did it occur
    • Name of application (if you are supporting several applications)
    • Attachments for screenshots
  • Functional Need
    • Name of application (if you are supporting several applications)
    • What business problem are you trying to solve?
    • Why does this problem need to be solved?
    • How many users are affected?
    • If there currently a workaround? If so, describe workaround.

Non-User Supplied Information

As requests are processed additional information is needed to support our key metrics as well as to manage the process.  This information would be supplied by someone other than the user.

Below are some suggested information:

  • When (date) was request submitted
  • What is the request’s priority
  • Who owns the request / who is working on the request
  • When (date/time) did a person start working on the request
  • When (date) did the request get completed
  • What is the status of the request
  • What was the answer (if request was Informational)
  • What was the solution (if request was production issue or functional need)
  • Who approved work on the request (If request was production issue or functional need AND your process requires approvals)

Stay tuned for the next part in this series where we will explore the “how”.

Questions for Youbusiness-man-question-mark1-300x282

Have you implemented a process to manage user requests?  If so, what types of requests do you track and what information do you capture?

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s