[MUD-Dev] Criminalize Community Volunteers?

Josh Olson jolson at micron.net
Wed Sep 6 23:45:27 CEST 2000


-----Original Message-----
From: Madrona Tree <madronatree at hotmail.com>
>I think anyone who is given powers above and beyond a 'regular player' in
>order to solve customer problems (I've fallen and I can't get up!) and/or
>adding content (decorating player taverns) or being the 'first line of
>defense' in deciding who should get punished and when and how much are
>working for the company.
>
>I believe that companies should encourage and support the first scenario,
>and let paid employees of the company deal with the second.

EQ Guides are all of these things except for the punishment bit.  When
designing EQ's dynamic quest system, my intent was that participation in
dynamic content (which most people enjoy) would be a reward for the less
pleasant aspects of volunteering (like being shouted at).  I believe that a
lot of good Guides have remained in the program because of this carrot who
might otherwise have gotten fed up with the abuse and left a long time ago.

In other words, you have to be careful about assigning only the worst jobs
to volunteers, or pretty soon you'll have a lot fewer volunteers.  Like it
or not, you have to trust volunteers with some potentially dangerous
abilities if they are going to be effective and happy.  The necessary checks
and balances are probably best saved for another thread.  Or a book.  :)

>I still think that companies can have good customer support without hiring
>volunteers.  My phone company doesn't hire volunteers, and their customer
>service is probably better than UO's.  Course, I also think that UO's
>customer base is probably a little more easily dissatisfied with customer
>service than my phone companies.

Apples and oranges.  The phone company's service doesn't fail anywhere near
as often as a game company's service, nor is it anywhere near as complex as
a game company's service, nor do the phone company's customers conflict with
each other anywhere near as often as a game company's customers, nor are
their per-customer revenues on the same scale, etc., etc.

>Realize, I don't want to throw the baby out with the bathwater.  I'm
>positive there are good volunteers out there, cause I know some former
>counselors, and a couple of guides ... and they're good folks.

I'll do you one better, and posit that the *best* potential customer service
people are volunteers.  Customer service for MMORPGs is a job that should
only be taken in small doses.  Doing it day in and day out can break
anyone's will.

>...I think it would be a lot
>easier for Origin to say, "You know what?  You're fired" to a paid employee
>than to a volunteer -- and then get one who wasn't a slacker.

Firing an employee involves legal and tax paperwork.  Firing a volunteer
doesn't.  Trust me, it's real easy to fire a volunteer.  Finding
non-slackers is always hard, employee or otherwise.

Of course, there are political issues to consider when dealing with
volunteers.  This can be a decided disadvantage to a company that isn't
treating its volunteers right.  Suffice it to say that both Verant and OSI
have glimpsed what can happen when volunteers realize en masse that they
don't have to put up with the company's bullshit.  Chalk it up to growing
pains, but it's something to consider.  A volunteer force is one that could,
in theory, vanish at any time.

>>     You think so?  Think again.  For one thing, 20% of the current
>> Guides do 80% of the work, some of them put in 60+ hours a week.
>> If they were employees, they couldn't be *allowed* to put in those
>> hours.  Yet those people are the administrative backbone of the
>> programs.
>
>Sure they could, you'd just have to pay them OT.

Heh... I think you're missing the point that keeps coming up: cost actually
is a significant issue.

>Is the "20% do 80%" because of hours worked or efficiency of guiding?

Dedicated few vs. adequate many.

-Josh Olson






_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list