Despite IT automation and the richness of social knowledge, classifying support requests remains one of the most vexing information management problems for support organizations. Solving the problem requires a commitment to logic and to picking the right job for the tool to do, not picking the right tool to do the job.

1. Narrating User Support:
Tracking What Matters vs. What Counts
An archestra notebook.
© 2013 Malcolm Ryder / archestra

2. Support the known, study the unknown
ASSUMPTIONS:
• Users are involved in Production. Production is the essence of their work and why they need things.
• Things that are designed well and made well usually work well when used as directed.
• “Support” should always be seen as reinforcement of an intended design and behavior.
• This allows intentions and designs to change, however those changes do not alter the purpose of Support.
• Support presupposes that the intended design and behavior are described in authoritative references.
• Unintended conditions are variances that need to be detectable and comparable against the reference.
• Defects, omissions and errors are the basic intended variances within directed use.
• Mis-use and ab-use are special cases that can create or exacerbate defects, omissions and errors.
• Many things can be observed, tracked, and counted… but not everything that is countable matters. What
matters, primarily, is the things that fit the design or that affect the fit.
OBSERVATIONS:
• The user effort of production also has an intended design and behavior.
• As described above, user support involves infrastructure, but it is not the same as infrastructure support.

3. Rational user support systems start with respect for the expectations of IT usagethat are most consistently in
the foreground. The expectations originate from varied points: engineers, operators, and IT users customers
each have reasons for emphasizing some things more than others. Those parties maintain relationships with
each other including expectations that need to be managed. These include plans, promotions, and
presumptions that express and explain their range of activities. But sometimes they compete or conflict.
© 2013 Malcolm Ryder / archestra

4. The Business view of support
Value, motivations and responsibilities are built into expectations about support of IT usage.
Users are aiming for certain production outcomes; providers are aiming for relevant deliveries; and
supporters aim to be responsive. These aims can be logically associated to each other.
User Requirements - define types of outcomes of user functions drawn from capabilities
• User Functions are task-enabling abilities, such as permissions, resourcing, controls, and tracking
Service Definitions - define access and activation of capabilities providing user functions
• Capabilities are operational resources such as tools, apps, solutions
Support Categories - define responses to demand for user function or service capability
• Demands are requests for instructions, supplies, configurations, execution, repairs, and changes
Actual support efforts then consistently make sense to managers in a user-centric context.

5. Itemizing the logical design of Users’ Production
The proper ability for Users to leverage IT is not opportunistic, but instead is based on a design for that usage.
In turn, supportability of the usage is itself based on the state of compliance to the design.
Describing…
Relating to…
Defined as…
Such as…
User Requirements
Outcomes
User Functions
Task-enabling
abilities
permissions,
resourcing,
controls,
tracking
Service Definitions
Access and
Activation
Capabilities
Operational
resources
tools,
applications,
solutions
Support Categories
Responses
Demand
Requests
instructions,
supplies,
configurations,
execution,
changes
© 2013 Malcolm Ryder / archestra
Concept

6. Issue reports are not the same as Support requests. For example: an issue can go unsupported; and a
request can be a desire without an issue. But requests allow anyone to “place an order” for relevant
items or actions (fulfillments) that are pertinent to requirements, terms of service, or issues.
Defined as…
Such as…
User
Requirements
Task-enabling
abilities
permissions,
resourcing,
controls,
tracking
Service
Definitions
Operational
resources
tools,
applications,
solutions
Requests
instructions,
supplies,
configurations,
execution,
changes
Issues with
Omissions
Issues with
Errors
(Examples)
(Examples)
(Examples)
(Examples)
(Examples)
(Examples)
responses
Support
Categories
Issues with
Defects
responses
responses
(provide or
improve via
fulfillment
techniques)
(provide or
improve via
fulfillment
techniques)
(provide or
improve via
fulfillment
techniques)
© 2013 Malcolm Ryder / archestra
Concept

7. Deployment is obviously the prerequisite to the availability of IT resources. But actual deployments
may not be readily apparent. Bad deployment leads to user issues. The issues reflect variations from
the intended design of production. The variations are numerous, but generic. Example:
Defined as…
Such as…
Issues with
Defects
User
Requirements
Task-enabling
abilities
permissions
Correct setting is No setting exists
not working
Incorrect setting
exists
resourcing
Correct item has
a flaw
Needed item is
missing
Incorrect item is
in use
controls
Item is nonresponsive
Control is
unavailable
Aftereffects are
inappropriate
applications
Feature failure
Deactivated
Wrong version
Service
Definitions
Operational
resources
Issues with
Omissions
Issues with
Errors
© 2013 Malcolm Ryder / archestra
Concept

8. The support organization, in its responsibility to users, wants to understand its performance.
Supporting a service involves matching a fulfillment technique (response) to a type of issue.
Example:
Defined as…
Such as…
Issues with
Defects
Issues with
Omissions
Issues with
Errors
Service
Definitions
Operational
resources
applications
Feature failure
Deactivated
Wrong version
responses
responses
responses
supplies
repair
refresh
upgrade
configurations
rebuild
reset
replace
Support
Categories
Requests
In providing assistance, Support organizations also need a way to associate the current experience of using infrastructure
with the requirements for making infrastructure beneficial. Users may have no significant awareness of the underpinnings of
infrastructure, or even if they do there may be nothing they can act on themselves. As a result, the user support organization
is the user’s agent for making requests to validate or conduct infrastructure support. That is, the matchup of request
fulfillments with service issues begins to correlate the user experience with the infrastructure state.
A common mistake in reporting “support” is a failure to recognize that the type of association being observed and reported is
correlation. The proper information system for reporting on user support should capture the users’ effort and experience,
separately from infrastructure conditions, but concurrently with them. “Solving” issues with support responses may involve
unknowns: trying to discover the infrastructure conditions and to determine if the correlation is a causal relationship or not.
© 2013 Malcolm Ryder / archestra
Concept

9. Reporting the Support
The support tracking model recognizes numerous independent variables that are associated with each other
within support efforts.
The narrative explaining any support effort has a baseline plot. Support tracking collects and records three
main events in the plot.
• <User Effort> involving <desire or issue> instigated <Support Request>.
• When <User Effort> was addressed with <Support Response> during <Infrastructure State>, then <Result>
occurred.
• <Support Response> included <Infrastructure Support> conducted to validate or adjust <Infrastructure
State>.
In the narrative, each variable may be rendered in more or less detail. But, compared to each other, their
generic distinctions always remain the same within the narrative. They do not substitute for each other.
Their independent variability means that the support information system should associate the variables as
multiple dimensions of the event. Statistical insights are readily drawn from this tracking.