4 Replies Latest reply on Mar 24, 2011 11:40 AM by lizg

    Internal Site with Client Access

      I work for a small software company, and we are hoping to develop an internal community where employees can go to share code, discuss client projects, and really collaborate. But, we also want to give our clients access to the site, so that they will have a place to go for support and news from our company. Permissions are going to be key--that we know, but I was wondering about site structure and client confidentiality. Our clients really shouldn't know about each other, so this is the plan that we're devising..


      1) Secret groups will be created  (for confidentiality purposes), so that our customers will have a place to go to discuss questions that are specific to their situation. Here, they will be able to interact with a member of our support team.

      2) Our employee will then report to an internal ("no clients welcome") support space where the topic can be discussed within our company.

      3) A site/space administrator will then take popular questions/discussions and edit them for publishing in a public Support space. Any specific client information will be removed, so the information can be shared with a larger audience (and we can actually develop FAQ sheets).


      Too much? Does this seem unfeasible? Any and all input is welcome!

        • Re: Internal Site with Client Access

          Liz, how important is it that your clients don't know about each other? I ask because even if you can rope them off into private spaces or groups, user profiles, status updates, bookmarks, etc. would be viewable by anyone in your community.


          Thinking about the secret groups...the approach seems like it would work, although it is pretty resource intensive. The problem with step 1 is that your clients won't be able to self-discover those communities if they are secret. Someone will have to invite them and the recipient will likely have to check junk mail for the notification. That could slow your adoption and usage. I'm envisioning the process as:

          1. Tell client to create an account to access the community
          2. Someone watches to see which clients join each day, or the client is told to notify someone once they've joined the community
          3. Someone creates the secret group for that specific client
          4. Someone manually sends group invitations daily (or more frequently) for any new client users who have joined

          The problem is that you lose any momentum you had when getting the user in for the first time if he was really excited to collaborate. Now that the client has to wait for an invitation (that may go straight to junk mail), he potentially loses interest and doesn't come back. Is there any way to relax the client privacy needs?


          Your use case here sounds exactly like what some other clients have proposed to Jive around a multi-tenancy model. I know it's something Jive has considered for a future release, but I don't know where it is on the roadmap.

          1 person found this helpful
            • Re: Internal Site with Client Access

              This is (hopefully) going to be an excellent discussion.  Why? Because we're facing the same situation and I'm glad you've brought this up, Liz.


              Our strategy focuses on spaces.  We've defined a hierarchical setup in our spaces to deliniate between internal departments and external client zones.  We're a digital agency and have many clients (some of whom are also using Jive but on an external basis) and we need to have each space locked off.  What we've done is to create groups of people and define access points per sub-space (turning inheritence off for those spaces and defining access per space).  So what you'd see is:


              Your main space

              --external client spaces


              --------clientaccess (this is the space where clients would only have access to, via the space permissions setup)





              The benefit is you can create groups and apply group policies which is far easier to manage than individual users.  Also, internal employees can see INTO the client sub-space but clients cannot see OUT.  That reduces your admin load of moving things around.


              However, Brice brings up something fairly concerning in that user profiles and updates,etc. are viewable by all.  I suppose we could change the automatic display settings to "connections" instead of "everyone" to further secure people.


              The issue we've found with groups is the backend administrative console is --frankly-- pretty lame in how it manages groups.  It's a lot of hunt-n-peck and spaces are more -- for us anyway -- enforceable and manageable.


              I too would like information on multi-tenancy setup. I suspect Jive would like a bridged community setup but that's a whole other issue.  (it does however resolve all the problems....)

              1 person found this helpful
                • Re: Internal Site with Client Access

                  Thanks for your input Doug and Brice!


                  We considered creating spaces for each client, but are these visible in the user interface? That was our main concern. Although, I guess we could use code names or something for each company.. I will definitely bring this up again with our executives.


                  As for user profiles, that would really be up for the client company (and likewise their employees) to decide what is acceptable. We haven't worked all of the details out, but I expect a lot of these guidelines will be based on the client company's Internet use and Privacy policies, as well as a mutual Confidentiality agreement between our company and our clients. And of course, there is no obligation for our clients to participate in the community. Just an option.


                  On the whole though, assuming the client opts-in, I think we will discourage users from sharing the name of the company they work for and have them focus, instead, on areas of expertise. And if they want to be really private, they can use an alias.

                • Re: Internal Site with Client Access

                  We are going to be controlling invitations, as we are running Jive Express and our license is currently for 100 users. All clients will have to wait for an invitation to join, which will be followed by an email to join the client group.


                  On the site, the majority of spaces are public. We have really tried to emphasize these public spaces on the main landing page, so hopefully clients will be interested in these other aspects of the site and really rely on their "secret" group for very specific support needs.