Need to connect a Freenode channel to a room in HipChat? Or want to give customers a simple way to connect to a channel in your Slack team?

Sameroom does that!
Learn more

 Subscribe via RSS

Tag: slack

Introducing Yammer Integration

By Andrei Soroker

Today marks the arrival of the Sameroom Yammer integration. (!)

(Fast-forward to instructions.)

As with most things Yammer, it's not particularly clear what this really means, so let me explain.

Why would you want to connect Yammer with Lync (Skype for Business), regular Skype, Slack, HipChat, HipChat Server, Salesforce Chatter, Cisco Spark, Cisco Jabber, or other collaboration platforms?

In a word, because of entropy (increasing, obviously).

Let's consider the process of a mid-sized company adopting Microsoft Office 365.

On Monday, everyone starts using email with Microsoft Outlook.

On Tuesday, a subset of employees discover Outlook Groups—one place for team communications and sharing on mobile, on the web, and on the desktop—and start using that.

On Wednesday, IT conducts a Microsoft Skype for Business training session, and some folks in accounts and marketing begin using Skype for Business for meetings and messaging.

On Thursday, account executives ask IT how to migrate existing Microsoft Skype groups with customers to Skype for Business, and, upon learning the answer (“you can’t”), double down on their use of regular, not-for-business, Skype.

Later on Thursday, summer interns tasked with field research realize they need something that works well on mobile and start a tried-and-true Microsoft GroupMe group.

On Friday, there’s an all-hands manadatory Microsoft Yammer training, resulting in a handful of new fans—particularly among executives—excited about the faster, smarter way to connect and collaborate across the company.

On Saturday, there’s a multi-hour service outage that sends ops and development teams scrambling to organize a recovery task force while stuck on playgrounds, boats, road bicycles, and parents-in-law’s back yards. The outage finally gets resolved with the help of group SMS.

Later that day, the engineering manager creates a HipChat team, hooks up integrations to GitLab and JIRA and send invites to the entire engineering department.

On Sunday, the ops manager returns from an off-the-grid hike in the Stanislaus National Forest and, upon learning the details of Saturday’s meltdown, creates a Slack team and requires all ops people to use it for all communication.

The sales team doesn’t notice any of it: they swear by Salesforce Chatter to connect, engage, and motivate employees—ones with a Salesforce license that is—to work efficiently across the organization regardless of role or location.

The resulting fragmentation across collaboration systems is almost impossible to undo and will continue to increase and accelerate as the company grows, new tools emerge, and teams become more specialized.

If the rumors don’t disappoint, Microsoft Skype Teams will soon become available as an alternative to HipChat and Slack—to the delight of those aiming to keep their company fragmented primarily across Microsoft’s stack.

Back to our mid-sized Office 365 company: we fast forward to the next executive meeting and overhear high praise for Yammer as a platform and bewildered disappointment at low adoption. Why won’t they all just use Yammer?

The executives mostly ¯\_(ツ)_/¯, but one of them suggests “using one of those integration services, like I T F T, or whatever it’s called, to cross-connect all the stuff we use around the company to Yammer.”

Brilliant! That’s exactly why you’d use the Sameroom Yammer integration. To empower teams to use whatever works best for them, while avoiding the immurement of resulting organizational memory that should— no, must!—be available to the entire company.


The Sameroom Yammer integration can be configured to sync all top-level messages and files (but not comments) between a Yammer group and a room or channel in another collaboration platform.

It’s also possible to 2-way sync all comments in a Yammer post with a room or channel in another platform. This option is only available to users of Sameroom Enterprise, through -sameroom open/connect or -sameroom portal commands.

  1. We recommend creating a new Yammer user for the integration (with a name like Relay, or similar) and adding this special account to Sameroom on the Accounts page. If your Yammer group is private, invite the Relay account.

  2. Next, authenticate with a chat account you’d like connect with Yammer on the same Accounts page.

  3. On the Open a Tube page, select your Yammer account in Step 1 and your Yammer group in Step 2, for Side A. For Side B, select the room or channel in the other platform.

Below is a video of the integration in an Enterprise environment, where a Tube is created with open/connect commands. (To set up your own Enterprise environment, please fill out form 27B/6.)

Team Chat: The Trouble with Guest Access

By Andrei Soroker

As team chat is rapidly replacing other forms of internal business communication, it's not surprising that companies—and agencies in particular—are increasingly using this technology for external communication as well.

While this is, overall, a welcome and exciting development, significant dangers lurk beneath the surface. In this post, we'll take a look at a few of these dangers.

Since email continues to serve as the preeminent cross-company collaboration medium, we'll also consider how some important workflows differ between email and team chat.

Teams Don't Scale

With time, accepting a new Slack invitation is becoming a bigger and bigger ask. If 10 of your colleagues need to join as well, the ask gets multiplied by 10.

(It doesn't have to be Slack—any team-centric system with guest or multi-team access will have the same problem.)


Figure 1: Artist's impression of a decade of joining Slack teams

Being in many teams with the same group of people means that you've got as many unique direct message (DM) histories with each person as there are teams. You have to be vigilant to always head to your "home" team to DM with your colleagues. If everyone has the same avatar and name in each team, things can quickly get confusing.

This may not seem all that bad, beyond the obvious observation that being a guest or a full participant in many teams doesn't scale particularly well.

But, we're just scratching the surface. There are serious problems with guest and multi-team access—ranging from project management to data governance.

Presence and DM Considered Harmful

When you give your customer access to your team's online presence, along with ability to message every team member individually, you're summoning Sauron.

It's often noted that the beauty of email communication is in the ability to respond at your own pace. With email, you're offline by default.

If you work at an agency (management consulting, PR, marketing, development, design—you name it) and you've got many companies as customers, you're undoubtedly tending to multiple concurrent fires at any given moment. This often means hopscotching around the schedule and the communication matrix with the goal of maximizing throughput ($$) without blowing deadlines or pissing off clients. It's a delicate dance.

Email and its "offline by default" mode lets you control the switchboard explicitly.


Figure 2: Explicit control of the communication switchboard

Email has many other redeeming qualities, like the ability to forward messages, a global user directory, and being truly cross-platform.

For tight collaboration—with fires aflame and all—email kind of sucks. Hence the recent and ongoing hypergrowth in the team chat space.

Team chat makes it really easy to tell whether someone is online or not—this feature is called presence. Another near-universal feature of team chat is direct, one-on-one messaging (DM).

Turns out, presence is not necessarily desired in agency-client communication, and neither is the ability to DM.

Here's how the problem plays out.

You've got three customers, three projects. Your team are guests in each customer's team chat. You've got major fires with two projects and just a little bit of smoke with the third.

The third customer, the one with the smoke, engages your team in a conversation—you're all online—available!—after all.

You ignore. Not because you don't care, but because your entire career hinges on preventing the two burning projects from turning to ash.

The third customer thinks that maybe you didn't get the messages, so he DMs you. You ignore for a few hours, then respond with "I'm so sorry," and come up with chipper-sounding reason for being slammed.

Now he knows you're ignoring him.

Just to be sure you respond from now on, the third customer stops using the multi-user channel altogether in favor of DMing you. Now you have to copy and paste stuff from your DM with the customer into your "home" chat, so your colleagues know what's going on. So long, transparency!

The same scenario is more likely than not to play out on every single project, causing a bit of a mess.

Presence and 1:1 DM is a privilege for inner-circle colleagues. Extending this privilege to customers and other external contacts is not a great idea.

They Control Access

Whenever two companies are engaged on a project, each party needs the ability to unilaterally invite additional members to relevant project communication channels. Guest access robs the guest party of this ability.

Complex, long-running projects often require the attention of experts to solve critical, but very well-defined problems.

To maximize the effectiveness of an expert, a project manager has to engage the expert—call the Wolf—at just the right time, provide the least—but sufficient—amount of context, enable the expert to temporarily take the wheel, which will often include calling their own Wolves, and remove the expert once the problem is solved.

Traditionally, this has been handled over email, but email is notoriously unkind to experts in the long run. Here's how.

Bob, the project manager, is faced with a problem only Alice can solve. Bob adds Alice to the main project email thread, provides sufficient context, and asks her to steer. Alice solves the problem with the help of Jo, who is also copied, but neither Alice, nor Bob can get Alice or Jo reliably removed from the thread going forward.

Alice solves critical, but well-defined problems on many concurrently-running projects. In the end, Alice, Jo, and all other experts get every single email for every single project they touch.

This is one of the most common criticisms of email—it's hard to modulate noise and almost impossible to undo "invitations".

If you're the one inviting customers as guests, team chat actually solves the problem of the ever-expanding noise for your experts. You're free to bring them in and out of channels as needed, they are free to engage their own experts, and everyone can use notification settings to ignore anything that doesn't concern them.

But if your team are guests in another company's chat, you lose the ability to invite your experts—instead, you have to ask an admin of the other team to do it. Your experts are even worse off—they have to ask you to ask an admin for further invitations.

Relinquishing the right to engage and disengage team members at will is a huge problem for project managers—it hinders the very essence of the job. Project managers absolutely need the ability to unilaterally grant and remove access to a project's communication channels.

They Own Your Data

Whenever two companies are engaged on a project, each party should own a complete copy of all communication history at all times. Guest and multi-team access prevents the guest party from owning history.

The problems caused by allowing DMs and presence in vendor-client communication, and the inefficiencies in project management process introduced by the lack of access control are significant.

Still, they can be dealt with by patience and clerical endurance, so to say. As long as clients pay their bills, agencies will take a near-arbitrary amount of abuse.

The biggest problem—one that simply cannot be ignored by any serious business—has to do with ownership of communication data. If your agency are guests in a customer's team chat, you're always a few hostile clicks away from losing all collaboration history.

The example scenario is simple: your agency spends a few months working on a project. You believe the resulting deliverable is according to spec. The client disagrees. The client refuses to pay, breaks off communication, and revokes your guest access from their team chat.

Time to sue!

You see where this is going: you have no access to the hours of chat transcripts and gigabytes of shared files proving your case. Your client may delete it all and plead ignorance.

The number of ways in which this turns ugly is endless.

No legal counsel would advise or sign off on a collaboration solution where your company does not own the communication record.

But We're Never Guests, They Are

What if you're always inviting clients to your team chat, and not vice versa?

There are two problems with this approach.

One, it can't continue forever: sooner or later you'll encounter a client in the know. Since they pay the piper, you won't have much choice but be a guest in their team chat.

Two, as Confucius once said, what you do not wish upon yourself, extend not to others.

How to Bridge the Gap Between Salesforce and the Rest of Your Company

By Jared McGriff

This is a quick post to explain how our sales team uses Sameroom to share Salesforce information with other teams.

This is important for our organization, as there are members of management and business teams who do not use Salesforce as a key component of their daily workflow. There are also members of the product team who do not have access to Salesforce.

However, there are data points within our instance of Salesforce—leads generated, opportunities instantiated, closed and lost—that should be seen by the rest of our organization. Since the rest of the organization lives in Slack and Fleep (we use two chat systems for redundancy), that's where those data point should be directed.

The question is—how?

One method would be to forward the daily Chatter digest to some company-wide email distribution list. This approach introduces key problems for our team:

  1. The Daily Chatter Digest contains a lot of information that is not pertinent to the entire org;

  2. We operate in a enterprise chat-first environment, wherein email is primarily used for external communication. Internal communication flows take place within our enterprise chat instances (Slack and Fleep);

  3. The Daily Digest is not real-time, so even if an forward is set up, important information may arrive nearly a day late.

While the first problem is more common with inter-disciplinary teams, the other problems are relevant from an efficiency standpoint, as email is a rather poor method of disseminating this type information.

With email, there is no way to confirm that the message was actually received (unlike with Fleep, for example, which has excellent read receipts), it is easily lost in the cruft of poor inbox hygiene, and there is no way to capture real-time reactions or feedback on any one piece of information contained within the Chatter Digest.

I found that the best way to share this information is to create a group in Chatter and use Sameroom to pipe updates from this group to a channel in Slack and a room in Fleep. This synchronization is almost like Dropbox for chatrooms.


To try this yourself, follow these steps:

  1. Create a Group within the Salesforce Chatter app

  2. Use the process builder to specify which information shows up in this Group’s feed

    • Ensure that only key information relevant to intended audiences shows up here, in my case it is Lead and Opportunity creation and disposition data is disseminated to this feed
  3. Create a channel within Slack that is dedicated to this Group

    • Give this channel a name that makes sense to the entire org (i.e. #sales-chatter)
  4. Connect the Salesforce Chatter Group and Slack channel via Sameroom

    • Go to and click on the Salesforce icon and sign in
    • For Side A, select Salesforce, then your group
    • For Side B, select Slack, then your channel
    • Optional: if you're using other chat applications within your org, you can repeat this process for each one

You will now see every Chatter group update in your Slack channel in real time. The integration is bi-directional, so if a Slack user types a question about a particular update into the Slack channel, the question will appear in the Salesforce group feed.

From Pivot to 140 Paying Customers in Ten Months

By Andrei Soroker

Table of Contents

Chapter 1: Beauty Pageant
Chapter 2: Segment for Chat
Chapter 3: Money and Pivot
Chapter 4: Build, Launch, LAUNCH
Chapter 5: Go-to-Market Strategies
Chapter 6: Go-to-Market Strategies: Results
Chapter 7: SEO and Startup Goldilocks Zone
Chapter 8: Zero to 140 Paying Customers In Ten Months
Chapter 9: Shifting Out of First Gear


Startups tend to operate in two parallel worlds. One is where they're crushing it, and the other one is reality. Sometimes they overlap, but that's pretty rare. Unless you're friends with the founders, true stories are few and far between.

2015 was a really interesting year for our startup. I think I'm going to go ahead and call it a good year. We pivoted, built a product from scratch, and are now teaching it how to walk. It's standing up and taking first steps. These are happy days!

While the days are happy, I want to share our story.

Chapter 1: Beauty Pageant

Almost a year ago, my co-founder Peter and I went on a few multi-hour walks in and around Palo Alto. We were coming to terms with the failure of our product and the need to pivot.

Our product was Kato—a direct Slack competitor. We spent two years and 1.6 million dollars building it. Our last-ditch effort—a SAML and SCIM-enabled enterprise version wasn't getting much interest, and we were running out of money.

After spending so much time trying to convince companies to use our chat service, we came to the realization that the world of chat is not moving toward unification. Instead, it's getting fragmented, and this fragmentation is accelerating.

Microsoft, Facebook, and Google all offer workspace chat services. Cisco now has two: Jabber and Spark. Atlassian (HipChat parent) is relatively small, but newly-public and poised to survive the apocalypse. Slack just announced a 80M fund.

That's just the visible tip of the iceberg.

Under the surface, there's a vicious battle for a piece of the remaining pie (and some fresh air—venture money) among the ever-increasing cadre of the small and unseen.

Symphony is actually building its own iceberg, nearby—it raised 160M in a bold effort to disrupt the Bloomberg Terminal (among other things).

Kato was a good—great, even—chat service, with a ton of unique and thoughtful features. It was reliable, fast, and to the point. But, it was a participant in a rigged, overcrowded beauty pageant. And to hell with that—we had to pivot.

It was Christmas, the sky was grey, light draught-drizzle was getting stuck in our beards. We were walking from Palo Alto to Atherton.

Chapter 2: Segment for Chat

"Let's build Segment for chat," one of us said, "no UI!"

We brainstormed for hours and eventually came up with a model that seemed workable.

Sameroom is a no-brainer of an idea. It just appears to be impossible to build.

And it is, almost.

The next day we met again, this time with a small whiteboard. We set it up on a park bench. Diagrams were drawn and photos taken. We had a plan.

Chapter 3: Money and Pivot

Having a plan is great, but we also needed money.

We asked Brad Feld, our lead investor, permission to pivot. Permission was granted, and we raised a 2M inside round to build Sameroom. Brad said: "you know how to build very complex technology that can stand up, while being very money-efficient. Let's give it another go."

Foundry Group is one of the best venture capital firms in the world and we're lucky, proud, and grateful to have their support.

We decided that Peter would start with the simplest possible task: connect a Slack channel and a Kato room, so that two teams can chat with each other without leaving their homebase. Once Peter got to work, he pivoted.

I still had to lay off two-thirds of the company.

This sucked, but it comes with the job. If you're a firefighter, sometimes you have to willingly enter a burning building. If you're a CEO, sometimes you have to fire two-thirds of your staff.

Chapter 4: Build, Launch, LAUNCH

We build quickly. Sameroom went into production six weeks following Peter's initial commits. Here they are (git log --reverse, so top is oldest):


On Sunday, March 1, we flipped the switch. Sameroom supported Kato, Slack, HipChat, IRC, and Campfire. Peter and I stood at a LAUNCH conference booth with this ridiculous poster:


The few people who stopped by were mostly confused. HipChat—the conference sponsor—was sluggish to the point of ruining our demos.

img Peter at our LAUNCH conference table on the day we launched Sameroom

On March 4, we ended up on Product Hunt—this was our initial wave of traffic and it brought our first paying customer: a development consultancy that signed up for three licenses (all still active!).

Once we launched, we had to figure out how to get people to try the product. Distribution is the hardest thing to crack. Most first-time founders don't have an instinctive understanding of this—it develops over many months of despair.

We started off by making two assumptions: First, we wouldn't be able to get press. Second, Slack, HipChat, and other "partners" would not tell their customers about us any time soon. Any press, marketing help from "partners", or successful growth hacks, were they to happen, would be treated as a bonus.

Chapter 5: Go-to-Market Strategies

We decided to try five go-to-market strategies simulaneously. (This was also when I finally understood the meaning of the term "go-to-market startegy".)

First, we opted to sponsor technical conferences. In exchange, we would ask conference organizers to offer a Sameroom Portal as a way for people to communicate for the duration of a conference. This way, we figured, conference attendees would discover Sameroom, and—hopefully—take it back home with them.

Second, we assumed that our most likely target audience will be the various agencies and consultancies—companies that have to deal with a fair amount of external communication. We planned on reaching out to them over email.

Third, we wanted to probe the co-working space market. Nearly all co-working spaces sell their "super awesome community" as a feature, so we figured we could help them structure communication in a simple way with Sameroom. We'd reach them over email as well.

Fourth, we decided to place ads on Twitter and Spiceworks.

Lastly, we planned on writing a blog post for every integration that was possible on our platform.

Chapter 6: Go-to-Market Strategies: Results

We ended up sponsoring five different conferences. All but one—NodeConf in New Zealand—were a failure, for a couple of reasons.

First, we couldn't get the organizers to fully understand what they had to do to support us, or how our system works. All we needed, it seemed, was five minutes of uniterrupted conversation with them, but those five minutes don't exist if you're putting together a conference.

Second, people don't actually want to instant-message at a conference. They socialize. They work. They're hungover. And some, I assume, are paying attention to the talks. We didn't land a single customer from this effort, but the experience was invaluable.

To reach agencies, we built a part-automated, part human-driven lead-mining machine. Over a four-month period, we sent about 9000 cold emails. It's difficult to put the magnitude of failure of this approach into words, as it approaches infinity: we had two signups and zero paying customers in the end.

We built a very similar lead-mining machine for co-working spaces, but on a much smaller scale. The intermediate results were way better than with agencies—great open and response rates, lots of calls. In the end, however, no signups or customers. Most co-working spaces operate on extremely low margins, buy virtually no software, and, in general, struggle along.

Paid advertising was a total flop (one confused signup, zero paying customers), but it lead us to a much deeper understanding of why paid advertising for something like Sameroom would never work.

Imagine, for a moment, that you have a startup that offers an on-demand emergency stain removal service.

Would low-budget paid advertising work? Of course not: very few (close to zero) people need emergency stain removal while browsing through Twitter, Facebook, or Spiceworks. But, there are definitely people who need an emergency stain removal service, now.

How would they find you in their time of need? They would search, for example, for "emergency stain removal san francisco". As long as you're well-represented in search results, they'll be calling. If there is exactly one on-demand emergency stain removal service in the world, you're golden.

This brings us to our final go-to-market strategy: blog posts and the mythical SEO.

Chapter 7: SEO and Startup Goldilocks Zone

As soon as we began publishing blog posts, we started seeing organic traffic. Not a lot, but incredibly targeted—we were catching all those looking for an emergency on-demand stain removal service. And we were the only game in town.

They'd search for a "slack hipchat integration" on Google, skim our blog, sign up, hit our limit, and subscribe.

Writing (and re-writing, constantly) these blog posts is painful, but the strategy totally works. Here's a graph or daily organic visits to from March 1 to now (December 17, 2015).


The increase in December followed Sameroom's appearance in the Slack AppStore and the associated bump in PageRank (this doubled signups).

Peter began describing Sameroom as a startup in a "Goldilocks SEO Zone". All we had to do to get to the (roughly) #1 spot on Google was to write a blog post. We didn't have to engage in a cashpile competition for keywords with other startups. Nobody else wants those keywords.

With each new integration, we add approximately N blog posts, where N is the number of services we support. To track our progress, we use this Google Spreadsheet:


I spent considerable time looking for writing help and trying out different writers, but in the end ended up writing almost everything myself.

Since nearly 100% of our revenue comes from organic signups, I consider writing our blog posts at the top of my list of priorities.

If you're a firefighter, sometimes you have to willingly enter a burning building. If you're a CEO, sometimes you have to write and re-write dozens of blog posts.

Chapter 8: Zero to 140 Paying Customers In Ten Months

140 is not a huge number, and it certainly doesn't translate to interesting recurring revenue, in our case.

But, I think it's kind of amazing that we got here fair and square. We built some technology from scratch for a market that didn't exist. Then followed a concerted effort of trying a variety of go-to-market strategies, identified one that seemed to work, and executed against it.


Our organic, self-serve customers unfortunately aren't going to turn Sameroom into a viable business—there's not enough time for that.

However, they've helped us battle-test the service and discover a very interesting new frontier: big companies where, for a combination of reasons, the abundance of chat services deployed simultaneously creates serious organizational challenges. We can help them.

Chapter 9: Shifting Out of First Gear

We're gaining steam. Our small engineering team is absolutely world-class. We have influenced the APIs of Slack, Intercom, HipChat, and Fleep. Instead of discovering new competitors, we're making new friends. We're getting better and faster at building new integrations.

This week, we released two new integrations: with Microsoft Lync 2013 (or Skype for Business) and Cisco Jabber. (They are so new, we haven't announced them yet.)

Both integrations mark the beginning of a new chapter for us, since they both require our customers to install an on-premise software package (the Sameroom Proxy). And we all know that only big companies install on-premise software packages.

The proxy connects on-premise chat services to Sameroom Cloud, which, in turn, connects them to cloud messengers or on-premise chat services behind other firewalls.

These new integrations and our Chatter gateway are uncovering a brave new world both for us and for chat interoperability in the enterprise.

We're excited to start 2016 not from scratch. We're excited for ongoing proof of concept projects with great companies. We're excited to be the sole participant in a beauty pageant with a tremendous audience.

Happy new year!

Using Slack as Your Team’s Universal Chat Client

By @abs

After years of forcing professional conversations into email chains and reply-alls, the modern workforce has begun a much-needed shift to communication via chat. Email loses to chat in so many ways—it allows too many messages to slip through the cracks, clutters up your digital space, and makes it easy for embarrassing errors to occur.

Slack, with its blindsiding success over the past couple of years, is the clearest signal yet that the email tide is turning. Slack’s model does a fantastic job of achieving organized, open communication across groups and departments, letting employees easily find any bit of organizational knowledge available. This is an absolute must for modern companies, especially as the adoption rate increases and email-only users find themselves unquestionably behind the curve.

Until now though, email has one-upped chat in a key area: With email, you’re able to receive and send messages securely regardless of which email service the other person is using. Vendors, partners, and clients can use their Hotmail address from the late 90s (we all remember ours) and still get the message to your inbox. But with chat, there hasn’t been a way to securely and easily talk to external people without keeping dozens of chat clients open at once. We’ve solved that problem at Sameroom by creating a tool that can make Slack your single chat client for all communication, both internal and external.

Achieving Workplace Zen with Sameroom

Let’s imagine your team works with a consultant who loves Hangouts for chatting, but you’re pushing for company-wide adoption of Slack. Within minutes, you can use Sameroom to bridge your own, dedicated Slack channel to a group on Hangouts.

If your team is working with another company that uses Slack, why not share a channel that both teams can access? This way, both teams get to keep working from their own cozy Slack setup.

With either of these scenarios, the biggest benefit is this: Each organization gets to use a single chat client of their choice, keeping a record of all communication data while controlling and allowing access to the channel as they see fit. Slack becomes your mission control center for two-way, real-time messaging across any major chat system, letting you work faster without losing important information.

At Brandfolder we deal with outside contractors. While its always great for our contractors to come in and use Slack, we would rather them stick to a tool they are used to. Sameroom allows us to continue using the Slack we love and allows contractors to use the tool they love.

Jason Waldrip, CTO

Lowering the Barrier to Slack Adoption

Friction of Slack adoption happens when a user needs to connect with an external party. Guest access only works to a certain extent, since the other party may already be committed to a tool (such as their own Slack, or Skype, or something else), or unwilling to forgo ownership of communication data (which email affords as a part of its standard operating procedure, since everyone always gets a copy). These limitations may force Slack users to switch between Slack and other chat applications. Worse, there may be a full-on email relapse.

I've been using Sameroom to push traffic from an IRC channel into Slack, where it's much easier to read, search and manage.

Jack Greenfield, Senior Staff Software Engineer

Sameroom + the Slack API: Making the Future Happen Now

Without Slack’s capable API, all of our big ideas at Sameroom would have remained squarely in pipe dream territory. Luckily, the Slack API is so good that creating our integration was a major success.

Sameroom lets you create “Tubes” between channels or private groups in your Slack and groups or contacts in a bunch of other platforms—even Freenode IRC channels and rooms in Campfire. We use the real-time API to listen to messages in channels you connect in Sameroom, and the web API to post messages to the other side.

Overall, the strategy works well—we preserve as much formatting as possible, and upload all shared files to your Slack team. Of all the chat systems we’ve explored, Slack is by far easiest to work with. As we continue to improve our integration, we expect it to be one of the top choices our customers make as they choose a universal chat client.

Responding to Customers from Slack

With our Sameroom Attend feature, it’s easy to connect your corporate Chatter, Facebook, Intercom, Skype, and Twitter accounts with your Slack team.

In this way, when a customer posts a question for your company in a service connected through Attend, anyone on your Slack team can either respond or get the attention of an expert.

Once we deployed this feature at our company, staff members who normally don’t use Facebook or Twitter, let alone have access to the corporate accounts, began engaging with our customers from Slack.

Sometimes, we respond without paying attention to the origin of a question—as it doesn’t seem to matter! And we think that’s pretty great, because we like bringing all our communication together in one place.

Sameroom helps me coordinate public chats across channels, so I don't have to worry about educating people about IRC, or about Slack. They can use their tool of choice.

Josh Simmons, Community Manager
O'Reilly Media