av juan uria 16 år siden
262
Mer som dette
I found this map in the web as a good example of a process.
I transfered the process into Mindomo to show, how a process can be builded in Mindomo.
Definition: A {case|request for action|problem|need} springs into existence,
either through customer action or an external trigger.
o Customer issues vary from "trivial" to "substantive" (e.g. MIT-business-related
vs. listening to FM radio in Real Player)
o Expectations
o Each group deals with different sets of customers
o Customer Outreach
Definition: The customer does triage; this can take the form of formal triage
and problem analysis, or be a simple who-to-contact decision based on
historical or other available date.
o Difficult for customers to triage; may misdirect themselves; frustration builds up
during this part of process
o Should the customer have to do triage at all?
o What makes a customer choose a particular avenue of support?
o How hard is Information Systems to navigate (i.e. who do I contact for what)?
o Customers build an affinity towards particular groups or people who have served
them well in the past
o Certain groups also proactively seek out certain customers
o Process is relationship-driven
o Willingness to hand off varies due to differing expectations around the results of
doing so
o Lack of formal expectations across teams and interfaces
Definition: Contact with Information Systems is made; this contact may be
with a first-contact team or with someone in a first-contact role but outside
the formal first-contact teams.
o Customer sets own context, picks a contact to make
o Initial contact with I.S. is an area rife with improvement opportunities
o Some customers prefer non-interactive methods (email); in Athena Consulting
and Accounts, 95% electronic
o Some customers really want to talk to someone
o Electronic contact works better for I.S., as it forces more (up front) clarification
from the customer
o We are often not as available during off-hours (home users, students, etc.)
o Broad spectrum of customers and customer diversity demand diverse, parallel,
and efficient ways to contact IS
o Improvement opportunities exist in areas of: support technologies, consistency,
training
Classify
Definition: The case is classified into one of six (following) buckets; this is
currently often not a formal step in the process, but would benefit from being
a formal, explicit step.
o Reference (Request for information; status; solution to known and documented
problem)
o Customer was misdirected: Divert (give customer info; really sub-set of
Reference)
o Consulting / Real-Time
o Request for Action / Transaction / Resources
o Problem-Solving
o Referral / handoff (how do we define these terms?)
o Escalation
o A single request may move through multiple classification iterations
Clarify
ResearchProblem SolvingTroubleshooting
Proxy(open...close)
Deliver
Verify
Close
Refer(open...close)
Action
Reference
Definition: A type “Reference” case involves the lookup, retrieval, and
transmission of existing, managed information; it does not involve problem
solving or extensive research.
o Technology not integrated (Casetracker-KB link)
o No knowledge-base tool that includes all [knowledge]
o Problem Queue
o Tighter feedback loop between problem solving and reference
o First contact based on who you know
o Potential improvement opportunity: everyone does lookups/is able to do lookups
[in the knowledge base]
o "Lookups" can also mean getting info from another person (the knowledge in
people's heads
