Community Magic: How Collaboration Fuels an Engaged Community
Ever wondered what the secret sauce is to driving lasting community engagement and growth? In this session, Kenneth from the Gainsight Community team will share his insights and best practices from running Gainsight’s very own multi-product, multi-use case, and multi-persona community. How do you ensure that every member has a positive experience? How do you connect the dots across product conversations, peer-to-peer groups, ongoing product feedback, events, and so much more? A lot of that secret sauce lies in facilitating cross-functional collaboration and making the community a core part of the business across the entire company. Join this session to walk away with practical, real-world guidance and examples.
I hope you had a good time. As you can hear my voice, I definitely had a good
time. I'm
still having, actually. When I was Julian, I'm an enterprise CSM at Gainside. I
work
on the community products. So for me, like, I love, of course, you know, see
all this interest
for communities. And actually, right now, I'm announcing a very special session
. Why?
Because the person that I'm about to announce, I've been working with them with
all communities,
I think, for like almost 15 years now, time flies. But in various roles,
various companies,
various communities, these are true inspiration for me to this day also, still,
like, with
many things around communities. So I'm super happy to have him here and have
you enjoy
his session. Please give a warm welcome for Kenneth Lefkart.
Wow. One introduction. Thank you so much, Julian. Wonderful to be here. Thank
you all
for joining this session. As Julian said, my name is Kenneth. I lead the
programs for
the community programs for Gainside today. As Julian already indicated, I've
been in
this space for quite a while. I've worked at a few different companies. Very
happy to
be at Gainside today. I was just saying it's sort of bizarre to me today. I'm
here on stage
speaking, and Rich Millington is in the audience listening. It's a very strange
situation.
Anyway, love it. Thank you so much for being here. There's another name up here
on this
slide is Revitie. She could not be here in person today, but I really wanted to
include
her on this introduction slide because this is the Gainside community team. Rev
itie and
myself, we run the programs. Revitie is amazing. She's a powerhouse. Things I'm
going to be
talking about today, none of those things could be possible without her. So
just boy, she's here in spirit and I wanted to call that out. So I'm going to talk today
about
something which I think and hope is quite essential and hopefully relatable to
all of
us here who work with our community programs. It's about how to manage some of
the complexity
we encounter with our programs, specifically around internal collaboration
across the organization.
So I think that's something hopefully is very relatable. I sometimes gravitate
towards
very strategic decks and slides and frameworks and models that everyone takes
pictures of.
I love that, but today is designed to be a little bit more practical. I'm going
to give
some real world examples and case studies and things. So hopefully there's some
things
you can relate to and take with you. The Gainside community, for anyone who's
not familiar
with it, it's been around for a long time. We've had a community at Gainside
for over
10 years, a few different platforms. We did a big refresh beginning of this
year where
we merged the previous incited community. Incited is the product that became G
ainside
customer communities. And today we have this single central destination which
has everything
that our platform can do basically. We do platform Q&A. We host events there.
We do groups. We
have product ideation and product updates. We do all these things within the
community.
So there's a lot going on here. As I mentioned, yeah, a lot happening. We have
today five
Gainside products which are represented within the community. We have a lot of
engagement.
We have at any point between 20 to 30 groups running. We have more than 500
articles in
the KB. We have more than 10,000 ideas. I could go on and on. Lots more data
points I could
mention. But the takeaway is that this is a lot. It's a lot to manage, to
coordinate,
and to take care of. And I think you may not be in a situation with your
program yet where
we've been around for 10 years. We're fairly mature program. You may not be at
this stage
of maturity yet, but I think community programs over time will tend to become
more complex
and tend to become, have a bigger breadth and depth as they mature. This is a
statement
I wrote. This is kind of the essence of something I want to get across is that
I think it's
in the nature of a lot of our community programs to be complex and in breadth
of what we're
trying to do, but also in the depth of the engagement that we have with our
customers.
And I think that's because we're trying to do something really extraordinary
with our
community programs. We are in a sense serving our entire customer base as well
as the entirety
of our internal company a lot of the time. And that's kind of an extraordinary
thing
to be doing. It's an extraordinary charter. It makes our programs complex and
it's especially
fascinating when you consider how a lot of us run our programs fairly lean. So
we are
two people in our team. You may have a team of five or 10 or 20 or maybe you're
just one
person, but generally speaking a lot of our community programs are running
relatively
lean in relation to the charter that we have, serving so much of the company,
serving so
much of our customer base. So the challenge is that Revitie and I have today, I
would
summarize a little bit like this. So we have the five products. Revitie and I
do not have
product expertise in all those products. We have amazing community members who
answer
questions and are engaging throughout the community. But of course some content
needs
facilitation and needs help from GainSight. We cannot do that ourselves. We don
't know
everything. We also don't have the bandwidth to directly coordinate all of
these content,
all of this content and all of these programs. I've mentioned this kind of
complexity and
that also comes because we are super cross functional. We work all the time
across CS
and marketing and product and more. So how do we do this? How do we do this
with a team
today of two? The answer is AI. That's a joke. That's a joke. Sorry. No. I love
AI. We
use AI all the time. We use AI all nonstop every day all the time. That's not
what I'm
going to talk about today. The focus of this conversation is collaboration. So
building
out collaboration across the company in ways that help us manage these programs
at this
kind of scale and complexity. What I'm going to walk through is four strategies
that are
very alive for us today based on what we've been doing over the past year or
two. Nurturing
relationships, influencing processes, empowering our teammates cross
functionally and something
we call build in public. For anyone here yesterday listening to Bjorn from '02,
find it hilarious,
we picked the same gift. Of all the gifts in the world, we picked this one. It
is pretty
beautiful. Diving into the first of these four themes, nurturing relationships.
I think influencing
internally is for me such a core part of what we do in our community programs.
It's so,
so important. As we start up a new program, oh, sorry, this slide quickly, this
is from
our state of community report from 2024. That's a great report that you can
download from
our website. We've got input from 200 companies. It's about the state of
community as we see
it. These are the typical organizations that our programs partner with very
closely. Probably
no big surprises here. In case the text is small, the big bars are customer
success, marketing,
product, customer education support. Most likely when we have a community
program, most of
our programs and activities are in collaboration with one or more or all of
these different
organizations. A lot of what we're doing is we are influencing, we are working
across
the boundaries of all these organizations. As we're starting a new program,
which in
many cases is going to be collaborative and cross-functional, we're often
making a choice
about where to start. I like this work. We often have to make a very, very real
decision
about how do we influence these other organizations. Do we, for example, work
with our peers initially?
Do we go to the leaders of teams and work from there up and down? Or do we go
to the
top? Do we go to secure executive buy-in first and then have that program
trickle down? Or
do we go grassroots? Do we go to the people of our hands-on and try to build
out a program
from there and have that filter up into the organization? For us, these are
very real
decisions and over the past year or two, I think we've, in some cases, been
focusing
much more on one than the other. I think what I want to try to say today is
what we've found
to work really well is basically when we are, to the best of our abilities,
doing all of
them in unison as best as we can. I'm going to give a couple of these kind of
case studies.
The Gainside community has, as I mentioned, a lot of product ideas. We've been
doing product
feedback for many years. We have a ton of ideas. It's a very cross-functional
program because
we work with product very, very, very closely. Now, we realized a year or two
ago that we
needed and wanted to refresh our process for working with product-on-product
ideation.
We really needed to influence this organization. We had this very real decision
to make about
where do we go, where do we start? Do we start with the executive or do we
start grassroots?
What, in the end, worked for us really well is when we put all these together
and influenced
at multiple levels at the same time. Yes, we did connect with peers initially.
That was
probably our first step. We found some of those leaders in product who were
probably
already champions to some extent, the ones who understand what we're doing and
are already
partners of ours. We started to get their buy-in, their commitment, and with
them started to
design what this process could look like. We also went grassroots. We did go to
those
product managers, especially starting with our champions, the ones who are
active in
the community and get their input, get them on board, clarify the process. Then
we went
for the top-down commitment. Then we went to our executives. Then we didn't go
alone
to our executives. We came as a whole group, a whole team of cross-functional
people who
had been talking about this together. This, in the end, worked really well.
This is just
an example of a very real situation that we've been working through. I think
this is an encouragement
that I would offer. Of course, influencing at all levels simultaneously sounds
like a
lot of work, but it's about doing the best you can and finding those champions.
Just a few general tips around influencing I would share. Some of these are quite
common sense,
I think, but I think they're good to mention. This gets talked about a lot in
our space,
but just to reiterate it. When we're talking to other organizations, it's so
helpful,
I think, to speak their language. We don't say, "Hey, product. We have this
community
and you have to help us with it." We say, "We have this community. It's here to
help
you manage your feedback. It's here to help you in CS scale. Let's work
together to make
sure that happens." I've already mentioned this a bit, but I think it's so
useful over
time to dedicate energy into cultivating champions throughout the organization
at all levels.
Having an executive champion, we talk about a lot, that's great, but having
champions
in different places across all of these organizations, over time as your
program goes, grows, gives
you a door into those organizations, and it really helps facilitate
collaboration over
time. When we do get something moving, I think it's really good to be very
generous with recognition.
We do a lot of recognizing on Slack very publicly when a program is running and
it's cross-functional,
so make it feel good to be a partner of the program. A little bit linked to
that, so many
of the mechanisms that we use in our customer community, like leaderboards and
swag, they're
really good to use internally as well, to make it feel good to be a partner of
the program.
Example here is we have a few folks who help us out during the Pulse Conference
. During
this conference, a lot's happening in our community. There's a few people
helping us.
We call them the Pulse Tiger Team. We printed these really nice T-shirts with a
tiger on
it and their name and stuff, and it's a small thing, but it makes it feel good
to be a partner
of the program. The next one, designing processes. You may not be in a place
where you've had
a community program for 10 years yet. I know there's an audience member here
who's maybe
had 20 years, almost, but a lot of folks I think here have been running
programs less
long, so you may not have the complexity that I'm talking about, but over time,
as programs
grow and expand, it can sometimes feel a little bit like this. You have all
these modules,
you have all these use cases, you have stakeholders, you have people, and so I
think a lot of what
we're doing as we're architecting our programs is we're designing process. We
're designing
the process for how things can work. I mentioned our product feedback loop. An
example of a
process that we designed not so long ago is this. This is, I'm not going to go
into the
detail, this is just to show you might be interested to see how this looks for
us. It's not a complicated
process, but this is basically outlining how we envision our product feedback
to be managed
and shows who owns what and it shows some steps to take and so on. So this has
been very,
very helpful. What I want to do, though, is talk about something which is even
more fundamental
in terms of managing complexity in terms of process. So you might be in a
situation where
if you are very lucky, where within your organization, there's a lot of
enthusiasm around your community
program. There's a lot of adoption. We have, at GainSight, over 100 people in
our back-end
environment and it's all legitimate access. We have a lot of people involved.
So you might
get into the situation where people across the organization are coming to you
with ideas.
Let's open a category, let's start a group. I want to open this and we should
do this and
this and this and this. Now this is really, really good. It's a great situation
to be
in. It's a wonderful problem to have. The problem part only comes in because it
can
be quite time-consuming to understand and process and figure out all of these
ideas
and kind of flesh them out basically with all of these teammates. So something
that we've
done is, which I think is a good best practice if you have an organization
where this is
happening a lot, is designed like a helpful intake form basically for anything
that's
coming to your community program. So all of these wonderful teammates come to
you, have
a way where you encourage them to think through what it is they really want to
do and formalize
that as a kind of a process. So what we did is we developed a business canvas,
we can
call it a brief, which is really, we've all seen versions of this in our
careers where
it's a template where you fill in what it is you want to do in terms of the
value you
think you're going to get from it who's going to do what, what are the
activities and so
on. And having a, there's lots of different ways this template like this can
look, we
have one and we circulate it, we promote it and when folks come to us, we, in a
gentle
friendly way, nudge them towards this template and they are then encouraged to
really think
through what it is they want to do. And this helps us have a really meaningful,
efficient
conversation and we can start to steer them. I wanted to share one fundamental
best practice
that I absolutely love and I use it for everything and Dita from Sonos will
laugh when she sees
this. But this is something I picked up in my years working at Sonos. It's a
format for
writing a brief which I love so much because it's super, super, super simple.
You can
use this for intakes but you can also use it for anything. You can use it in
your personal
life. I use this for everything. And what I love about it is it asks five very,
very
simple questions in very natural language. Where are we today? What's the
opportunity?
What's the idea? What's the thing that we want to go do? How will we know when
we get
there? What's the impact we expect? Who are we going to need and what's our
timing?
It's so, so, so simple. People that get really good at writing a brief like
this, they can
basically explain why you need a new CRM system in a single page. I've seen one
like
that. It's a kind of a skill. It's a muscle that you develop to think really
thoughtfully
about what it is you want to go do and why. It's very, very, very, very, very
helpful.
So I wanted to share this. Like I said, I use this even in my personal life
sometimes.
Just sit down, crystallize my thinking. Also really good for intakes. So being
generous,
if you're in a situation like we are, where you have a lot going on in the
community and
you have somewhat limited people in the team, a lot of us are in the situation.
At some
point we need to start letting things go. We cannot, we're here to architect
the program,
design the program, but we can't coordinate everything we don't want to. We
want to take
ourselves out of the equation where we can. So an example for us is our groups.
Raise
a hand if you're managing groups in your program today. Wow, that's a lot. Okay
, awesome. Those
of you who are managing groups might agree with me that when you are launching
groups
in the community, typically they need some stewarding. So I've seen a lot of
groups fail
over the years. Groups notoriously, if you just put them live and leave them
there, often
they will fizzle out. They require very often a communication plan, a plan to
nurture, to
activate and basically to take care of the engagement within that group. We
cannot do
that in our team for 30 plus groups. We have groups for betas, we have peer
learning groups,
we have all kinds of, we have a few different use cases basically for groups.
So this is
one of those areas where we really do our best to let go and we do our best to
empower
our teammates to autonomously drive and own all the groups that we have within
the community.
We do know the best practices. So I think that's our role. So our role I think
really
is to help those teams get set up for success. So we help explain the best
practices, what
is a communication plan, look like and so on. And even what kind of metrics can
you look
at to health metrics for groups and all these kind of things. Set them up for
success and
then we try to take ourselves out of the equation and leave those teams to work
autonomously.
Today we don't actually, we're not very involved in the groups that are running
in our program
day to day. We do some monitoring. We do monitor the community. We do some
moderation.
And we will know if a community is being left to languish. So we can give
someone a friend
little top on the shoulder. That can happen. But generally speaking we can let
things go.
Next the final one I want to talk about is a principle is called building in
public.
So building in public is not a term we came up with. I think generally it means
you're
building a software product in public with your customers. That's a little bit
of what
we're talking about. But what we're really emphasizing here as well is building
in public
with your internal audience. I've learned over the years of my career that I
have a tendency
to want to polish something forever until it's perfect and then kind of jump
out and go
dah dah dah look at this thing. It's been a year on that. Isn't it beautiful.
And everyone
is human. Everybody likes to build something which is amazing and then show it
off to
the world. But what I've learned over and over is when we do that we miss an
opportunity
to educate and especially really bring awareness to what it is you want to do.
And I think
in our community space I think this is extra interesting because in most of our
organizations
what we do in the community is not so well understood. Often there's not a
great deal
of awareness of the detail of what it means to run a community program because
it's kind
of a niche and there's a ton of best practices and strategies that we employ
that are kind
of unique to our space. So building in public is a way to raise that awareness
and educate
and bring people along. So I'll give an example of something which is
absolutely not understood
very broadly around most organizations. This is a rank structure. Some of you
will love
these and be very familiar with them. Some of you may be a little bit less so.
It's part
of our gamification system. And we realized in the last year that we needed to
revamp
our rank structure. It had some problems with it. We really needed to redesign
it. By the
way we don't normally give away our internal rank structure. So you're going to
get these
slides later so you can steal our best practices if you want. I think there's
some good ones
in here. But this is one of those examples where we could absolutely have
hidden away
and built it and designed it and polished it and just gone live with it. But we
would
have missed an opportunity to bring the teams along. So what we did here is an
example.
We did our initial discovery around this program and we immediately started to
share it in
a public space and a public Slack channel what it is we've discovered. So we
communicated
there, started to build awareness. And interestingly quite a lot of people are
interested in this.
There's people who follow what we do across the organization. And people are
actually
quite interested to learn about this. We then developed a V1, shared that and
then ultimately
we did go live. And then that point, communication and enablement was very,
very easy to do because
we had already brought so many people along that people were aware of what we
were doing.
We had educated basically a lot of our teammates on what this means, why we do
it, why it's
important. And then people understand the community program a little bit better
. If
we do this regularly, influencing getting things done cross function, it
becomes easier
than people understand what it is we do day to day. There's other programs we
've applied
the same principle. We recently, quite part of this, we've designed all of our
groups to
look consistent. This was a nice one. So all of these types of programs we've
taken, we
tried to take this principle. And the principle is really simple. For me it's,
oops sorry,
instead of going into a DM, setting up a meeting one to one with someone, if I
can, go to a
public place and discuss publicly and share. And that's really, really powerful
in my experience.
So if we put it all together, I want to share a final case study here before we
go into Q
and A. So probably the trickiest thing that we have built in the last couple of
years has
been moderation. So moderation is not the sexiest topic, but it's very, very
important.
We need to take care of our members in the community. And as I mentioned, we
are in a
place where we have five products in one community. We have a team of two. It,
it, we have a team
myself cannot help when, when help is needed, we cannot cover everything
ourselves. So we
need some help from subject matter experts throughout the company. All those
experts
are busy. They have day jobs. They have other things on their minds and things
they need
to do. This is a tricky thing to solve for. So this might be something that you
're have
struggled with or thinking about and, and you, it's, it can get complicated,
especially
if you have multiple products and, and, and multiple, multiple teams of experts
. So I
can say happily today we're in a good place here. So we were not in a good
place to be
very vulnerable and honest. I think a year or two ago we were not doing a great
job here.
But today this is working pretty well. And the way we got there was by applying
these
principles in unison that I've described. So what we did was we did a lot of
influencing.
You can imagine these team with experts in them. They are busy. They have other
things
to do. So we needed to influence those teams. We needed to influence their
leaders. We did
go to the peers. We did grassroots. And ultimately we went to the, to the
leaders. And this allowed
us to build that coalition of folks who are willing to, who understood the
importance
of it and were willing to help us. This tip is very helpful here, making those
leaders
co-owners. So if you're tracking progress in your company, put that little name
next
to that. Very useful. Not in a weird political way, but if something needs a
little bit of
adjustment at some point, it really helps if leaders have their name next
initiative.
They feel ownership. We also, obviously it's moderation. We design processes
that were
as efficient and clear as possible. For those of us here working with the CC
platform recognizable
probably we do quite a lot of monitoring ourselves. And we use moderation
labels and custom views
so that these teams of experts, they have a single custom view with a beautiful
clean
queue of work. That's all they have to look at. Try to make it really, really
simple and
easy for them. Those are the things they have to look at. They don't have to do
anything
else. And with that set up, we can start to take ourselves out of the equation
a lot.
So we, we, we do some, we have Slack channels where we can coordinate a little
bit. But
it's often not necessary. We try to take ourselves out of the equation from
there. And that's
what this is all about. We're trying to empower these teams of experts to work
autonomously.
And also the leaders of these experts to be able to, to lead their teams
autonomously.
So we'll write them with the data and the insights they need to be able to, to,
to do
that. We try to, try to stay out of it if we can. And finally, yeah, we did all
of this
as much as possible in public. Not everything can be in public but we try to go
to those
public channels, try to certainly provide updates on our metrics and our
successes and
so on. So kind of bring the organization along and what it is we're doing. And
yeah, raise
that awareness of the importance of what we're doing.
So to summarize, these are the four thoughts that I wanted to share today.
These are very
real for us. Like I said, I wanted today to bring something which is kind of
more tangible
and hopefully relatable because these are real things that we have worked
through in
the last, certainly the last year. Hopefully some of this has been relatable
for you as
well. I think we can, we have a decent amount of, this went a little faster
than my dry run.
So we have a decent amount of time for Q&A. So I just want to say really thank
you so
much for joining the session today. And yeah, appreciate it.
[APPLAUSE]
Thank you so much. Super, super interesting. Hopefully also valuable for all of
you here.
Yeah, we have some time for questions. And I'm happy to say there are a bunch
of questions
already, but please go to the app, select track for, ask the questions that you
have,
and I'll start the time. First one, how do you handle a community for different
language
target groups? Did you decide to have one line language and how was this
perceived by
global customers? Yeah, that's an interesting one. So, inside it, which is now,
gainside
customer communities. So we have made, we made it a few years ago, a big pivot
into B2B
sauce. And for a long time, most of our customers in B2B sauce were primarily
English. So in
this space, it's quite normal to have communities that are in English only. So
we have some
customers who are, of course, multilingual. Those of you different places,
different
ways to do that. But we have until now been basically an English speaking
community. Now,
we are in the process today of building out our first multilanguage capability.
So we're
building out Japanese, because that's one of the growing, a very important
market for
us that's growing, where we know folks there are not able to follow. They
basically need
a localized experience. So we're building that out today. But yeah, it's very,
very
much English today in our community. And in our platform, we actually have some
really
good multilanguage capabilities that are partly live and some more coming that
are going to
make it way, way, way easier to have a multilanguage experience. It's going to
include some, yeah,
really, really nice features. In addition to that, maybe many of my customers,
they test
the waters first with a group. So they have their French speaking group or
whatever.
So when you also started with this now, they're now expanding on an actual mult
ilanguage.
But this is good for you also to see is actually an appetite for a certain
language in the
first place. Sometimes also hard to gauge. We started with a Japan group, for
example.
What has surprised you the most about the Gainsite community? What has been a
while
that's an interesting question. What has surprised me the most? I think I'll
say what surprised
me the most was how challenging it was to set up moderation. That's why I took
it as
an example. So hopefully to offer something relatable. Across organizations, so
many people,
so many experts in so many different places across different products. That was
a surprise,
because I've run communities and other companies and moderation was not nearly
so hard, especially
in P2C. Sometimes we have a friendly support team that will work with you. For
us, it was
definitely more challenging. Great. What advice do you have for someone
starting a community for
the first time in a company with over 1,000 customers? Advice when you're
starting out. I think
what I sometimes say to a question like this, I think when you're starting to
build out a program,
the very beginning we're typically building out strategy. I think one of the
pitfalls in the
beginning is to be a little bit, thinking a little bit inside out. When we're
starting to
build out a program for the first time, we naturally will think a lot about our
business
goals and what we want to achieve, we want to drive retention and all these
things. That's all
very important. I think at the beginning, what I would encourage is to double
down really hard on
your audience. Think about your customers more than anything else. Try to talk
to customers,
interview customers, talk to your CSMs, talk to anyone who talks to customers,
and try to get
really, really clear on what it is they need and want. What you want to do as a
company is also
important, but in the beginning especially, I think much more important to
understand what that
audience really needs and wants. What are their authentic needs? Are they
looking to network? Do
they need to have technical questions? Do they need to learn how the product
works and so on?
Then you can fine-tune your program initially to focus on those use cases which
are going to be
the most important and valuable to the audience. I think that would be my top
one.
Maybe a good thing also to collaborate on is content creation. For whatever
reason,
I see it sometimes that the community is launching and they have empty
categories. I like to compare
that with an empty restaurant. It's not very attractive for users if you come
to an empty community.
It's going to hurt your activation. Make sure also that there's something for
people to discover
to see where can I go and where can I talk about what. I think that's also
super important,
also again a good thing to collaborate on also with other teams.
I'm curious if you have spent time refining and focusing what problem the
community
solves for you and the members of your community. Your goal or community seems
quite broad.
Thank you. That's a wonderful question. Yeah, it is. It is absolutely. I would
never encourage
anyone to start with the community this broad. I think what we typically see
and I think has also
been the case in our evolution is that a program starts with probably one
primary use case.
Traditionally, it's always been support back in the day and I think even in B2B
today, that's
still a really good place to start. Just helping people with technical question
support. It's a
really, really good foundation. Like I said, I think over time as a program mat
ures, you start
to discover opportunities to do more with the community. That's what I love
about this space
that we're in with primarily B2B SaaS communities where we see that there's so
much more that you
can do beyond support. We are customer success. We want customers to be
successful with the products,
that there's an education opportunity. The product opportunity is really huge.
Over time, typically,
the scope of the program will expand step by step. It's a great way to approach
it. That's
been this case for our community as well. In the early days, we had one product
. We focused on
admins of GainSight CS and it was mostly about product feedback. That was what
we did. GainSight
has grown to become a multi-product company. We have a lot more disciplines
that we are interested
in now. The scope of our program has gradually and organically expanded and
grown. Also,
our platform CC has also expanded and grown. It's also sometimes about looking
at what
innovation is happening in the space that you can then also leverage like
events promotion, for
example. Thanks. Next one is a good one also. When discussing your gamification
strategy publicly
with your most active members, wouldn't that bias your strategy towards
existing highly active
members? How do you benefit to also make it work for newbies? Wonderful
question. I love these
questions. This is something I think we could both talk about for many hours
because we love
gamification. To avoid a bias, if you look at the structure that we designed,
there's a certain
practice that we have adopted and that we recommend often. As we're building
out the gamification,
we are looking at segments of types of users. We're trying to target particular
segments because
we don't want to have a bias only to super active users. We don't even want
every member that comes
to the community to be super active. It's never going to be the case. In any
community, there's
people who hit and run. There's going to be people who just come and don't
register. They just wanted
to look at one thing and go away. That's fine. That's good. In the structure
that we design,
we have segments of users and we have maybe three to five ranks for our rank
structure
for each of those segments. It starts from people who have just joined and
haven't posted,
people who are starting to contribute. Then there's a leap to people who are
maybe starting to help
others, the first person who gets a best answer. Then you get into highly
active members. You
spread these segments out and you want to see or hopefully an organic flow of
members activating
through this funnel. That I think is a really useful best practice because it's
very important
actually to focus on the first stages. Sometimes that's more important because
you really want to
get that activation going from the very first visit. Good one also. Maybe one
or two tips.
Keeping, I remember back in the days when we did we had colors for ranks and
only if you would
actually help answer questions. You would actually use a name would be in a
certain color. If I would
see your account and you would have a thousand posts on the community but you
're actually just
talking and you never reach the rank where you help somebody, you're probably a
detractor.
With this you can also see who you're talking to at a glance. I usually, as my
opinion,
people have different opinions about that. I think you should never tell users
like,
"Okay, you do 50 more topics or you get 20 more likes, then you're going to get
this rank because
that's exactly what they're going to do." We see that all the time that people
just spam the
system to get high on the leaderboard or do whatever. Don't be explicit but you
can say,
"Hey, use XYZ. If you help a little bit more, you will reach the rank or you
will get this or that
badge." I think that's for me important to not tell you users exactly what they
need to do to
reach a rank because that's really detrimental to the community experience of
others.
I'm glad by the way you mentioned the detractor rank. I think that was due to
the scope of genius.
It's really funny. I believe we gave it a really ugly color.
Brown.
It was like this.
Brown.
It was like this.
It was really unpleasant color.
A poop brown.
Yeah.
It was an outstanding something.
Yeah.
It was an outstanding something. Yeah. Anyways.
First off, I'm not going to shout this one because my voice is not a super
weather,
but what is the community's average time to response?
It isn't hard.
It depends a lot on how we define the metric. It depends on which part of the
community
and it depends on who's responding. I think we generally were looking for a
response within a day.
If it's product Q&A, this is a great best practice and I think Björn, you
mentioned it yesterday as well.
It's like we don't want to jump in too quickly because we have wonderful super
users and members in the community.
We don't want to jump in too late because then folks have a bad experience and
they go somewhere else.
So we generally are aiming for about a day on average.
That's good. Some communities have a much shorter. Some have much longer.
It really depends on your situation.
In some parts of the community, we'll also have a much longer time to response.
There are parts of the community where time to response is less important.
There are some of the groups where it's just not as important to have an
instant response.
It varies, but I think around a day is a good general.
I think it also depends on the vertical.
Like P2C communities, they're way faster because they're active in the weekends
but all B2B communities, they have an issue with weekends and then it's like,
average time to respond to skyrockets, because people post up on a Friday and
then nobody,
sometimes nobody comes back to you.
Which teams were the hardest to get by and from and how are we able to convince
them?
Yeah, that's an interesting one. I think
that sometimes the customer facing teams can be challenging when
just to do the focus and bandwidth.
That's a process of conversation and really explaining the charter of what we
're doing with
the program and explaining that it's a core part of scaling those motions.
That's a conversation that's at every level, it's grassroots and it's also with
the leaders.
That's kind of the process we went through and it's not something that happened
overnight.
This is a process that took some time to work through a number of conversations
with a number
of individuals over a number of different levels to get to that point where yes
we have enough buy-in and commitment to actually have this moving.
It varies. Product can also be challenging in its own way, but yeah, I think I
'll pause it there.
Yeah, with my customers I usually see it with support teams and product teams.
That's usually
like support to answer the questions and product you need of course experts to
help with the ideas.
But there if you also there if you limit the score, when there are also light
versions of how
you can collaborate, it doesn't have to be super or automation is also actually
a cool trick where
you can like have content already funneled into Slack so that people can work
in Slack and they
don't have to go to the community so you can't make it easier for them to
engage. This is like
a hack that sometimes can make a difference. What strategies have you
implemented to make the
community a core part of the business across Gainsite? Yeah, I think one of the
most helpful
one here is the letting go aspect that I described in the talk. So empowering
other organizations to
own and drive parts of the program as much as possible. So this is not only
because of bandwidth
constraints but I think it's also just we don't want to own everything. I think
it's the right thing
to do. So we are designing and architecting the program but for example in our
community we have
product updates for all of the news and announcements around our roadmaps. So
our product marketing
team we collaborated with them they own that autonomously. It's core to what
product marketing
now does. It's fantastic. I mentioned the product example as well and the
groups example. So by
letting go and giving away parts of the program to teams that are directly
going to be benefiting
from this and letting them really own and drive this. This is I think probably
the most effective
thing that we've done. It's also easier for us of course because we sell that
product so there
we should also be using it internally of course. How does your community fit in
your overall
digital CS strategy? Yeah, it's a big question. So there's a number of things
that we do so we
collaborate very closely with our with our digital CS teams. Some of the
examples are that we have
you might have seen that we have KC bot implementations that link out into
community content for example.
We include community in some of our mailings and outreaches and within app but
also just through
a journey orchestrator and things like that in CS. So I think it's an ongoing
process always
looking at digital CS and seeing how community can kind of be holistically
integrated within
those motions. I definitely we're not like 100% done and complete and crushing
this at all levels
that this is something we're also working through all the time. Ongoing
collaboration, dialogue,
what are the right places to put community where it's really relevant for the
user at that time
it's actually going to help them. It's actually going to be genuinely helpful
for the customer.
Last question of the day from under the helpful intake process. What are you
experiencing with
balancing that with discouragement of ideas for example if someone might find
the threshold to
submit an idea too high and therefore stops approaching you with ideas?
Yeah that's interesting yeah I my experience has been but having an intake
process that it's not
discouraging. It's also a little bit soft skills in terms of how we you know
manage that relationship
and that's influencing again is managing relationships within the company. So I
think if you have an
intake form template whatever you call it that is very simple. I find most
people actually like that
but most people enjoy the challenge of answering these questions they maybe
haven't thought about
it in that way yet. It's actually a kind of a way of coaching your teammates
around the
organization to think a little bit more strategically sometimes and so I don't
I don't think it's ever
really been seen as a discouraging thing to do but I think that yeah it will
come down to how you
yeah how you soft skill it basically and because you want to maintain those
relationships and to
the point of the question I think it's a really good call out you we want to
maintain that energy
and enthusiasm for the program. We don't want to build a wall and turn people
away for sure.
Thank you so much. Thanks for joining. Thanks for listening. Have a nice rest
of your day.
(applause)
