Client Protocols
In the late 1990s, as a teenager caught up in the excitement of the
first dot-com boom, I cofounded a technology company with my
friend Michael Simmons. Because we lived near Princeton, New
Jersey, and thought this was a prestigious-sounding address, we
named the firm Princeton Web Solutions.
15
We focused on website
design, starting off by hand-coding sites for small businesses in the
area. At some point, however, Michael connected online with a group
of freelance developers based in India. We soon realized two key
points. First, this team was much better at web development than we
were, and second, their rates were quite low by American standards
at the time. We struck a deal in which we would find clients and
manage the projects while the Indian team would do the actual
graphic design and HTML coding. In my memory, our first contracts
were around $1,000. With the new team on board, we began landing
contracts in the $15,000 to $40,000 range. The problem with all
this, of course, was that we were teenagers living in the 1990s,
meaning that we were in school all day and didn’t have cell phones.
As a result, we were running large contracts for demanding clients
who basically had no way to get in touch with us.
Our solution to this problem was to code up an elaborate client
portal. Each client had their own username and password they could
use to log in to the portal. Once inside, they were presented with
detailed information about their project. Sample designs and pre-
launch versions of their site were all available for review in the
portal, as was a calendar that listed the major upcoming milestones.
A “work diary” contained daily updates on what work had been
completed that day. Most actual interaction about the projects was
condensed to specific meetings that were connected to our detailed
project process. Each of these meetings generated a corresponding
memo outlining what we’d decided, which we asked the clients to
sign, indicating that they approved. (We found that this minimized
the chances that the client would later change their mind once
development was underway.) Scans of these signed memos could be
downloaded through the portal.
We never directly explained to our clients that we relied on our
portal because we were in school all day—though I have to imagine
they figured this out on their own—we just set things up so that this
reality wouldn’t be an issue. Designers today often complain about
how much time they spend dealing with emails. We were doing more
or less the same work back then, but did so with basically no emails
at all.
Of course, we weren’t unique in our commitment to becoming
clever about client communications. Back in chapter 1, I told the
story of Sean overhauling the workflow at his small technology start-
up. In this story, it was overwhelming client communication, more
than anything else, that drove him to a breaking point. For Sean,
things really began to unravel when a particularly demanding client
asked to be given access to their internal Slack setup—causing the
pings of Slack notifications to become a constant background hum,
with each message carrying yet another anxiety-producing demand
from the client. Not surprisingly, when Sean finally decided to
replace the hyperactive hive mind at the company with better
practices, one of the main areas where he focused was how they
interacted with their clients.
Sean’s company began adding a section titled “Communication”
to every statement of work. “We want the client to be aware of all of
this at the front of the project,” he told me. The new section specified
the rules for communication between the client and the company,
including, as Sean emphasized to me, what to do when urgent
matters arose. In most cases, the standard setup was a prescheduled
weekly conference call with the client, after which a written summary
of the call was sent to the client. Sean’s business partner, who was in
charge of client relations, was anxious about this change. “He was
worried the clients would not be happy about this because we are a
user experience company, so the experience has to be top-notch,”
Sean explained. “But they are absolutely much happier. It’s all about
managing expectations.”
—
Though we didn’t use this terminology, both Sean and my high
school company deployed improved communication protocols to
handle interactions between our organizations and our clients. By
doing so, we significantly decreased the average cost of this
coordination. Having studied other examples of these client
protocols, I’ve identified a few useful pointers for helping these
efforts succeed.
First, when seeking to minimize costs, consider the client’s cost
in addition to your own. A key factor that helps a client protocol work
is if it reduces the cognitive cycles or inconveniences that the client
faces as well. Few clients actually like sending you endless messages.
They often instead feel forced into this behavior because they don’t
know how else to get in touch or make sure work is being done. As I
learned with Princeton Web Solutions, the structured nature of our
portal didn’t frustrate clients; it instead gave them peace of mind, as
they didn’t have to waste cognitive energy worrying about our
contract. By contrast, if you come up with a communication scheme
that makes your experience easier while simultaneously making the
client’s experience costlier—to provide an extreme example: forcing
them to fax you detailed client request forms every time they need
something—you’ll have a much harder sell on your hands, and for
good reason.
Another important point is the need for clarity. Sean’s company
included a detailed description of their client protocol in the
statement of work all their clients signed. This was smart. If they had
instead just casually suggested to their clients that a weekly call
should work, the clients would have been much more likely to default
to the hive mind as soon as the first minor inconvenience arose.
When the language is contractual, however, the client is more likely
to just suffer the minor inconvenience and learn over time how much
they actually enjoy the lower average cost of a more constrained
system.
Finally, despite your best efforts, there will always be some
clients for which these types of protocols just won’t work. I talked
with a communication consultant who used to work at a twelve-
person shop in Washington, DC. She told me that for many of their
clients, they used a variation of Sean’s setup: a scheduled weekly call
followed by a written summary of all the points discussed. For some
of their clients, however, they offered crisis communication services.
These clients needed a way of getting immediate attention when
publicity crises occurred, so their protocol essentially simplified to
“call right away if anything happens.” The details of these protocols,
in other words, can depend on the specific type of work.
There are also certain individuals for whom this approach won’t
apply, not because of the nature of their work but because of their
personalities. To use the technical term, I’m talking about jerks who
enjoy badgering people because it makes them feel important. Tim
Ferriss wrote about this exact situation in his 2007 bestseller, The 4-
Hour Workweek. In discussing how he upgraded the workflows of
his supplement company, BrainQuicken, he talked about how he
ended up “firing” one of his more stress-inducing and belligerent
clients. This idea that you might fire toxic clients struck a nerve.
“That passage just leapt off the page for me,” explained Tobi Lütke,
the CEO of the tech company Shopify, in a Ferriss profile appearing
in Inc. magazine. “If you go into business school and suggest firing a
customer, they’ll kick you out of the building. But it’s so true in my
experience. It allows you to identify the customers you really want to
work with.”
16
Claude Shannon’s framework helps validate the logic of
this client-firing strategy. While it’s true that you’ll lose money in the
short term, you’ll also eliminate significant cognitive costs. Once you
start treating the latter more seriously, it becomes easier to move on
from clients whose costs to your psyche don’t justify the
improvements to your immediate bottom line.
Pulling together these pieces, it should be clear that if you deal
with clients, an optimized client communication protocol will be
crucial in your journey to move past the hyperactive hive mind
workflow.
Do'stlaringiz bilan baham: |