Today, while co-working, someone (thanks, Mike) suggested an alternative integration, currently not available but potentially equally (or more) valuable. What if we link ClickUp (or other productivity platforms like JIRA) to Slack? The idea would be to create a Slack channel for any tickets that are in the OPEN state.

ClickUp <–> Slack

The user would start by linking up and authenticating with Slack. They would then need to authenticate with ClickUp (more integrations in the future). Once this is done, GiToLink can link the user’s ClickUp account with their Slack account.

When the user opens a new ticket (moving from TODO to any open state), GiToLink automatically creates a new Slack channel and adds the assignees. The channel description will be the ticket description, and any files will also be uploaded/linked to the channel. There will also be links back to the ClickUp ticket.

Any comments already on the ticket would be created in the Slack channel as messages attributed to the relevant user, where possible.

Once the channel has been created, any additional comments in ClickUp will be added as a message into Slack and vice versa.

All the messages in the Slack channel would be synchronised with the ticket in ClickUp. It could ease communication around the relevant tickets, increase visibility and improve productivity.

Challenges

Channel Proliferation

The biggest challenge is that everyone would end up with several more Slack channels. In an agile environment, each individual within a team should only have a handful of tickets that are relevant to them, and the team should be limited to 9 people. There should be one ticket each person is working on, and perhaps one or two they have handed off to another team member. The product owner might want visibility on all the tickets the team is working on, which in a large team could be (theoretically, at least) around nine.

Most people likely have around 15 channels (or fewer), and doubling that is problematic.

Invite only Owner + Assignee

One way to mitigate this is to invite only the Owner and the assignees of the ticket to the channel, and when assignees change, any new assignees are added to the channel.

The product owner will likely still get inundated with channels, assuming they create the majority of tickets.

Disable automatic channel inclusion

An option that lets them opt out of automatic channel inclusion may be enough. They can be manually invited into the channel if and when required. In this case, though, the person assigned to a ticket could end up in a channel alone.

Channel Sections

Slack allows you to have channel sections, mitigating the larger list of channels by separating the ClickUp channels into a specific section.

Value

Another challenge we have to address is whether such an integration adds enough value. Can we streamline communication enough to save time, money, and effort? Can we capture and store more relevant information in each ticket?

Streamline Interactions

If we can load up all the information from the ticket into the Slack channel, the person working on the ticket may no longer need to open up ClickUp in another window/tab/workspace. Fewer windows open mean fewer distractions and better focus.

If more information is needed or there is a question, you can pull the person into the channel to ask the question, making the process of chatting about a ticket easier.

We can provide some additional interaction buttons in the channel for changing the ticket status or re-assigning it to someone else, further reducing the requirement for having the ClickUp app open during the lifetime of a ticket.

If this tool proves its value, we could have an additional channel to track the current sprint, showing the highest priority tickets so that a user can pick up a new ticket on Slack. This channel could provide high-level updates from the sprint tickets.

Alternatively, when the user closes (or re-assigns) their only open ticket, it could automatically open and assign the next relevant ticket to the user. This automation might be one too far.

Communication Trail

Since a Slack channel is dedicated to each ticket/issue/task, this encourages each user to have conversations related to that ticket in its Slack channel rather than in direct messages. These interactions are now captured within the channel and in the ClickUp ticket for reference later. Having a single source of all communication related to that ticket is easier.

What’s Next

Overall, I think the value added by integrating ClickUp tickets into Slack channels is much higher than the risks posed by the challenges.

I still have questions about commercial viability which I will continue to explore alongside the exploration of the technical implementation.

In the meantime, I would also like to collect all feedback on issues, challenges, benefits and potential additional functionality. If you have any thoughts on this, please reach out to me — either on site or on LinkedIn

Updates

• 2025-03-01: GiToLink is now #muster

You don’t have to take my word for it. Kate Vitasek on Forbes talks about how widespread collaboration will make the world a better place including some excellent examples.

Personally, there are few things that bring me greater joy or a sense of fulfillment than being involved in something collaborative. It can be as simple as a tête-à-tête or as complex as a large scale project of some form. I love watching the efforts of a group of people come together into glorious fruition. Perhaps that’s why I ended up leading teams, often delivering incredibly difficult, apparently impossible challenges.

One severe burnout and several adventures later, I am at a place in my life where I am pondering next steps. Having run my own company for almost two decades, I have a personal style of working, which makes working in a corporate environment more challenging for me. I would like to start my own company again, perhaps on the basis of a product, either of my own, or in partnership with someone else.

Since I have little to no capital (I put almost all of it into buying a house, and the rest went into what we’ll call some poor investment choices), I figured to start with something small. Admittedly, I might run out of money before I get it completed, but I intend to give it a decent shot.

I believe in and follow Lean methodologies, BDD, TDD, DevOps, and most importantly on putting people first. In every job before, I have had to make compromises because the focus was so heavily on commercials. I am taking this opportunity to put my money where my mouth is and follow the methodologies with faith that the commercials will work itself out.

For the product itself, I decided to try and build something like Axolo. I used Axolo at my previous company and absolutely loved it. It is a great collaborative tool that really eases the peer review process. I have only one (but major) complaint about Axolo and that’s the price. $8 per user per month feels incredibly overpriced, particularly when you consider that GitHub charges $4 per month and Slack charge $7.25.

Most businesses consider how they can maximise revenue – how to exploit a marketplace. This is at odds with my people-first philosophy, and I want to turn it around. No exploitation of the market and no maximising of revenue. I want to know what you want – well, what my customers (hopefully, including you at some point) want. I want to consider what a fair fee for the service is – not “what it’s worth” (I am looking at you pharma companies). At its extreme, could the cost per seat be purely the running costs + a reasonable markup? Product development could be funded by an additional revenue stream where the interested users pay into the features they are interested in – essentially democratising the roadmap.

I also believe in transparency, so I will also aim to be as transparent about everything as possible. While I want this to work, with my limited capital, it is possible that I will run out of money before this starts to make enough money and I might have to go to plan B and find myself a contract or permanent role. At that point, it is possible that any updates here will quickly stop.

In that event, I will consider open sourcing whatever I have completed so that it can be put to good use.

On that note, I should probably introduce myself. I am Shri and I ran kraya, a digital technology company for 15+ years. I have extensive experience in leadership and tech, having played a huge range of roles within the digital sector including CEO, CTO, Technical Architect, Software Engineer, Systems Engineer, DevOps etc. etc. etc.

As I mentioned at the start, I love collaboration and feel that it’s my superpower – or at least my favourite power. I would love to hear your thoughts – please ping me a message on LinkedIn and I’ll do my best to respond.