Random tip for Microsoft Office Word 2007 users that I just learned: MS Word defaults to saving documents in the new .docx format, which is incompatible with all the existing versions of Word that are out there. So, to send a file to someone who has the older version, you have to go through an annoying "Save as…" loop every time (which you’ll invariably forget when it’s most important).
However, my friend Korbett just alerted me to the fact that there is a four-levels-deep setting that can make Word 2007 default to save in the friendlier .doc format instead of .docx. Here’s the sequence:
"Office" button =>
"Word Options" button (it’s hidden down at the bottom) =>
"Save" link =>
"Save Files in this Format" = Word 97-2003
There ya go.
Conversation evolves humanity’s software. This has a larger reach than the "traditional" kind of evolution, which merely evolves our hardware.
Related: "What we call ‘authority’ is the right we give others to author us, to change us."
As retailers crank up the marketing machine, and Black Friday and Cyber Monday and BuyMoreStuff Tuesday come to pass, it warms my heart to find a site like this:
(Note to Dave Winer: you’ll be pleased to know isitchristmas has an RSS feed.)
One of the primary models for "customer support" is the triage method. While the definitions vary, these three support levels are usually defined as some variant on the following:
- Level 1: The Level 1 support team is the first point of
contact in the incident response process. Customer service personnel
are responsible for call handling, triage, problem characterization,
and resolution of basic problems. Oftentimes, Level 1 Support answers
questions by consulting lists of frequently-asked questions (FAQs).
- Level 2: The Level 2 support team is staffed with
support engineers assigned by product type. The support engineers are
responsible for lab-based simulation, difficult problem resolution,
defect correction or escalation management to Level 3 support.
- Level 3: The Level 3 support team is staffed with
senior analysts, program managers, and development engineers dedicated
to working on the critical problems. They are responsible for
confirmation of defects, including complex failures, performing
interoperability studies, and enacting engineering level changes to
permanently resolve any issues in released products.
But, there are other, customer-centric models that could exist (raise the VRM flag here, charge the hill, etc.), other models that do not inflict the vendor’s silo and processes on the customer who just wants to get the damn thing fixed. Paul Sweeney asks:
"To post a blunt example, I leave a comment on the recent Service Untitled post
about a poor experience he had with Toyota. How does Toyota sense this?
who should get a call, what "interaction opportunity should be
offered"? Could they "sense" that this particular post was about the
fact that a particular part did not function well, or that a particular
dealer wasn’t all that friendly? How could Enterprise 2.0 solutions
re-design how this is handled?"
Great question. This is a logical progression from the thoughts I had ("We’re Listening") and Alex Barnett ("Support Tagging") Stowe Boyd and Greg Narain posited as well ("Support Tag Beacons") on the idea of "support tags" (or "beacons" as Stowe and Greg call them, although the "Beacon" term has been co-opted by Facebook these days, more here and here on that).
Extra credit: The Consortium for Service Innovation on swarming as a customer support model
Sean Coon’s impassioned take on what’s wrong with the music industry (and RIAA in particular) is a must-read on how to do all the wrong things and, in the process, destroy any hope you ever had for a relationship with a customer. The best quote is…actually, I can’t pick just one. It’s a great piece. Here’s the link.
"The more I think about it, the more VRM [Vendor Relationship Management] makes sense. If you think about vendor customer interactions as an arms race then you have to admit that vendors have invested
heavily in their weapons while customers are still playing with
slingshots. Time to recalibrate." – Denis Pombriant
"What makes [VRM] so compelling is what it calls
upon business to do. The truth is that the customer control of the
business ecosystem is just part of what actually has gone on with
consumers in the past three years or so. What may or may not have
occurred to you is that the change has been social, not commercial. Customers are in command of their own destiny because they are humans with new ways to communicate with those of their own kind." – Paul Greenberg
photo credit: aidan jones
"There are clear signs that momentum is building for enterprise implementation of social networks as tools to improve internal communication and to deepen customer relationships. The growing number of companies offering private-label social network solutions, as well as IBM’s recent entry into the field with its Lotus Connections social software platform for business, is a sure sign of increased demand." – Nancy Davis Kho, EContent Magazine
"The more I think about social networks in the enterprise,
the more convinced I am that there are great business applications for
the technology. The networks won’t be ad based, though." – Bruce Richardson, AMR Research.
Indeed. But, I’m biased.
Bonus reading: Social Networking for Businesses and Associations
Over at the Tom Peters blog, Steve Yastrow asks:
"What is a customer relationship?"
The definition that Yastrow finally offers is a good start. Yastrow offers:
"A relationship is an ongoing conversation with a customer…"
(He later offers a longer version which reads "A relationship is an ongoing conversation with a customer…in which the
customer never thinks of you without thinking of the two of you." I think the longer version muddles the point a bit. I also think the longer version is a little creepy, in a Sting/Police, "Every Breath You Take" stalker-y kind of way. But I digress.)
Yastrow’s definition is almost precisely aligned with a post that I made here in 2005 (paraphrased: "A customer relationship is a set of linked conversations over time"), which itself harkened back to a conversation with Doc Searls back in 2004.
This is really important, critical stuff.
Creation of this type of customer relationship has a number of prerequisites.
- Actively listening to the customer – A conversation requires multiple parties be present and interacting. If you’re the only one speaking, it’s not a conversation. It’s a monologue.
- Memory – Relationships are long-running. They are not atomic points in time, like transactions. As such, both customer and vendor need to be able to remember what’s been said and exchanged in the past.
- A long-term view – Relationships (typically) don’t have clearly defined end points. A relationship is, in most cases, intended to be an ongoing concern.
This puts a responsibility on the vendor to track conversations over time. But let me pose a question. For you, as a customer…if you want a relationship with a vendor, how do you track your interactions with that vendor over time? For example, how do you track things when you’re searching for a solution, or when you’ve bought something, or when you have a question or support issue? Note cards? Post-its? Excel? Simply "remembering?"
This issue becomes extremely relevant as we move into a VRM-enabled (VRM=Vendor Relationship Management) world. Because if we want buyers and sellers to build mutually beneficial relationships, both need to be involved, and both need to be able to contribute their portions of the conversation history to the dialog.
photo credit: AyG