It's not surprising that we count so many software consulting, web design and general project shops amongst our customer base. After all, we originally built Assembla.com as an internal tool suite that our sister company, Assembla Consulting, could use to build and deliver software for other companies. What does amaze us, though, is how many different ways our customers use Assembla to involve their clients by selectively giving them access to certain tools or the entirety of a workspace that they are using to coordinate and accelerate that client's project.

We thought that you might find some of these tactics of client interaction interesting, so we have grouped them together into generic use cases. Please leave us comments about which use case(s) you find most effective or if you have developed a different way of using Assembla to work with your clients.

Complete Transparency with a Handoff at the End

Before we started reaching out and conducting lots of interviews, we assumed that our customers used Assembla.com to interact with clients the same way we do. We basically invite interested folks on the client side, usually the "business-side" project manager and occasionally others, to view the entirety of the project. Then, at the end of the project, we hand off the workspace to the client.

Many clients will sign up for our lowest level plan and use Assmebla.com to archive the workspace should they ever decide to do version 2.0 of the project or need to go back a year later and understand why something was built the way that it was. A persistent (archived) workspace is a fantastic way for clients to safeguard their intellectual property - and not just their code, but all of the thought that went into conceiving, architecting, building and testing a piece of software or some other complex project.

However, we have learned from our customers that there are lots of good reasons to manage client interaction with a workspace differently. For example, you may not want clients having access to a code repository before they have paid their bill or you might be afraid that if clients have access to the Tickets Tool that your team will constantly have to self-censor what they say in ticket comments so as not to offend the client.

Parallel Workspaces

Some of our customers use a slight variation of the completely transparent approach and set up two workspaces for each project - one that is inward-facing and is only used by the project team and another that is outward-facing and the clients have access to. It's a great way to control what the client sees while still allowing them to observe the incremental progress being made on a project and feel like they are involved. Often times, the outward-facing workspace will use the ticket tool as a way for clients to test the project and leave feedback along the way.  The obvious downside of this approach is that you have to synchronize the parts of the workspaces that you want the client to see frequently. 

Using the Customer Service Tool for Client Testing

Similarly, if customers don't want to set up an entirely separate workspace, they may opt to use the Customer Service tool as means by which the end client can test the project along the way and report problems without allowing the client to see all of the tickets. This way clients can be continuously involved, but without the possibility of stumbling across something that may be embarrassing to the project team.

Limiting Access to One Tool

It is also possible to give the client very limited access to a workspace on Assembla.com. Here's a great example.  Many of our customers will use a wiki as a set of working documents that house the project scope and other content that help to define the project. Initially, both our customers and their clients will go back and forth editing the wiki and recording their comments. When our customers and the clients agree on the scope, that wiki becomes the de facto Statement of Work for the project.  However, a workspace can be configured so that this is the only tool that a client that can see. 

This can be done by defining the permissions of each tool for a workspace for the team member level of "Watcher" (visit the Admin tab and click the "more" link in the Security section ) and then inviting the client as a Watcher.