3 Replies Latest reply on Dec 10, 2015 1:28 PM by jkurutz

    Whether/How to use generic accounts to represent certain groups of employees


      Hi External Communities people!


      We have a strategic (maybe tactical) question concerning how company participants in our external/hybrid community should be represented. In our not-yet-public customer community, we will require users to use their real names and affiliations, like you would see at a professional conference or trade show. While most are OK with this, managers of the higher-level support engineers, who do not generally interact with customers, are proposing to use a single multi-user generic account for those engineers. Reasoning: once customers know the names of the brilliant people who solve the hard problems, they could bypass normal support channels and deluge the elite people with mundane problems. (Scroll to the bottom of this post to see more of what kinds of questions we get.)


      We want the elite engineers to participate because they are very knowledgable experts, but we acknowledge that they shouldn't be spending a lot of time in extensive community discussions. However, we'd like them to help contribute knowledgebase articles and blogs, which shouldn't take much time (though their managers worry that if their contributions are popular they'll spend a lot of time responding in the comments sections of their posts).


      How do we keep them involved while protecting them from customers who may seek them out? Does anyone here have experience with something similar?


      It seems we've got a few choices, each with pros and cons:


      Model 1: Real names for everyone
      1. Increases trust because you know with whom you're dealing
      2. Gives customers a sense of personal connection to the people in the company
      3. Is the most fair option, holding all employees to the same real name requirement as customers
      4. Gives credit to real authors of content (e.g., knowledgebase articles)
      5. Increases sense of community because all users have real participant names,  reinforcing connections that extend into the real world (some customers have worked with us for decades and know many employees by name, buying each other beer when getting together at professional meetings)
      1. Risks that some customers could send their support questions straight to the top engineers, bypassing normal support
      2. Risks sending mixed messages to customers if different employees have different ways of approaching a problem
      Model 2: Generic group accounts for non-customer-facing employees
      1. Shields non-customer-facing engineers from unwanted customer contact
      2. Places customer trust in the company, not the individual engineers
      3. Provides consistency, as if the company was speaking with one voice
      1. Makes company presence impersonal eroding the sense of community
      2. Customers are more likely to have an emotional attachment to individuals with whom they've interacted than a corporation, even if strongly branded
      3. Conversations must still be handled, and this gets confusing if different people respond under the same name
      4. Undermines the Real Name requirement for participants
      5. Incites internal tension between customer-facing engineers, who use their names, and non-customer-facing engineers, who do not.
      6. Deters participation in discussions by needing engineers using the same account to coordinate response, which incurs delays
      7. Very confusing if two or more engineers on one account wish to respond in one thread.
      Model 3: Individual pseudonym accounts only for non-customer-facing employees
      1. Shields non-customer-facing engineers from unwanted customer contact (aside from @-mentioning them)
      2. Retains some sense of individual connection
      3. Facilitates further integration in the community; engineers would would like to respond to a regular question won't feel obliged to coordinate with others in a group identity
      1. Connections between pseudonymous people online cannot reinforce or be reinforced by real-world contact
      2. Undermines the Real Name requirement for participants
      3. Erodes trust by customers, whether the name is realistic or obviously generic
      4. Incites internal tension between customer-facing engineers, who use their names, and non-customer-facing engineers, who do not.
      5. Doesn't reduce the workload of engineers responding to comments on their own posts



      What advice can you offer? To be clear, I’m starting out against anonymous accounts for a number of reasons, and I dislike “collective” accounts (multiple people who log in as the same username) for additional reasons. Yet there are certain circumstances where company accounts can be useful, such as posting manuals authored by “the company” instead of individual employees. And the managers of these high-tier engineers seem to have some painfully valid personal experience with customers who, once finding their names, guess their email addresses and deluge them with low-level support questions.


      Thoughts? Preferences for Model 1/2/3?


      Thanks! - Josh



      P.S.: To give you a concrete sense of the problem, consider that our call center handles all questions, from simple "what's the part number for...." to extensive applications dialogs like "I'm trying to use gas chromatography to separate two regioisomers of an 800-MW sterol and I'd like to increase my temperature but the thermostability of my column isn't rated very high; what do I do?" You can appreciate that the engineer on the second question would be hampered by answering versions of the former question. If the names of the high-level engineers are known to customers, then there's a real risk that customer will figure out their email addresses and deluge them.

        • Re: Whether/How to use generic accounts to represent certain groups of employees
          Libby Taylor

          Well, Josh, I can say that we do not take that approach here in the Jive Community and are often put into the situation with customers calling out individual experts who do not have the bandwidth to reply on a regular basis to every question. However, we approach support slightly differently in that we provide each customer with a secret support place where they know they will get fast response on a question from the next available support agent. I think that knowing they have that immediate help available does temper the amount of at-mentioning that our experts could otherwise see.  At Jive, we believe that communities are personal, so we do not have any generic accounts except for some system management functions. We think it's important to have people representing people. As long as there is someone in the right place to answer a question, even if it's directed at a specific person, I think the key take-away for the customer is that the question gets answered.

          1 person found this helpful
          • Re: Whether/How to use generic accounts to represent certain groups of employees



            I'm in a similar situation/industry.


            In the beginning, many of our Apps Engineers signed up with either their Windows username (i.e. jsmith) as their community username, or their actual BRCM email address as the community username.


            This created alot of issues as enterprising users would call our 1-800 number and start asking for the user by name.  Unknowingly, the receptionist would transfer.


            Embarrassingly enough, I was one of those users early on :-)


            I have since encouraged a more generic username policy internally, which helps tremendously.  In addition, since we hide the company name in the profile (Only title, location and username is visible to non-Admin users), for internal AEs assigned to support the community, we require all of them to use a visible BRCM Avatar; other "Advocate" employees/engineers are not required to do the same.


            Another problem we have run into is one where internal users insert their email addresses in the post. This is normally related to sending company confidential material that the customer is not comfortable posting to the discussion (i.e. their code, design files, etc.)


            When I see one of these, I delete their personal email address and insert the reflector email address I setup; I then make sure the email with attachment is routed to them and that they respond to the discussion.


            I refuse to use group emails as I found those do not work, at least not in this company as they unknowingly defer responsibility to someone else.


            I feel people only take responsibility when you address them by name and provide clear instructions with a set of possible responses.


            For this reason, I am also not a fan of sending emails with multiple people listed in the To: box....but that's me.



              • Re: Whether/How to use generic accounts to represent certain groups of employees

                Thanks, Michael. These are great insights.


                I've been wondering about how effective the shielding is in our situation. The intent is to dissuade customers from contacting engineers directly, and because people can guess an email address from a person's name, their full names are not supposed to be revealed. Yet if they phone the company and get support directly from a customer-facing engineer, the customer learns the engineer's name verbally. Our existing process thus exposes this risk already...and we don't seem to be having major problem.


                In our existing (but niche) community, the engineers tell me they have no more problem with direct contact than they used to before we had the community.


                Our situation really just boils down to change management - managers see the customer community as a very new thing (though it's not) and are thus identifying all the risks they can and then asking for ways to mitigate the risks. Of course, internal politics are also playing a role.


                I'll mull over the discussion here and come back with a proposed solution for comment.


                Thanks! - Josh