Hello Intercom Community! I’m Dulce, a Customer Support Manager here at Intercom 👋🏽 I also happen to be the newest addition to the NORAM manager crew based in the Chicago office. One of the things that has impressed me about our Support department is the partnership we have in place with the R&D team. As Support leaders, we know the bridge between R&D and Support is a critical one to maintain for many reasons…

• To ensure the product is evolving in a way that strives to meet customer demand

• To internally prepare for new product launches and equip our team with the knowledge & resources to enable customer success

• To enable Support to be an efficient link between the customer and R&D on bug identification and software maintenance

One of the recent projects I undertook was to do some “spring cleaning” in the bug management space. My 2 key objectives were to A) improve how we communicate with our customers on bug prioritisation & resolution time and B) provide clear guidance on how/where to internally follow-up on an existing bug.

While we had existing Macros in place to talk to customers about bugs, they were outdated and vague in expectation. Thus the improvement was to set up variations of the same macro, each of which share a different anticipated timeline to resolution, dictated by whatever prioritisation label has been set by R&D on that bug. 

Now you might be thinking, what is the benefit of having variations of the same macro? Why not simply inform ICs to change the timeline expectations in their message based on the priority label they see from R&D? By separating those macros, we can add Tags to each variation which will give insight to drill down into all conversations tagged with ‘macro variation A’, for example. This then enables comparison analysis on what customer sentiment looks like in response to macro A versus B. 

Thus the power of macros in this instance is to not only provide visibility into usage and reception, but also keep ICs aligned on the language used and clarity of expectations set with customers whenever bugs are reported.

This naturally gives way to the secondary piece of the puzzle i.e. once a bug is in our queue, how/when/where is it appropriate for an IC to follow-up or escalate that open issue? Untangling what the follow-up process should look like required collaboration with the R&D Enablement Team to understand their current workflow and bug management landscape. From there, I was able to uncover the knowledge and awareness gaps Support had and create content to demystify places where ICs could self-serve their inquiries. 

This then illuminated two remaining buckets of ambiguity to solve for A) what the path is when an IC is seeking more information on an open or recently closed bug and B) what path to take when advocating for an expedited resolution. The resulting guidance on these two areas improved the mental load and time required from ICs to manage bug conversations. It also decreased the lift required from R&D on the amount of re-education they had to do, instead focusing their efforts on the most impactful work.

While we’ve come a long way on the partnership between Support and R&D as a result of the work above, I am excited to continue finding places to improve. Leave a comment if you’re someone thinking about the relationship between these two departments at your company. I would love to chat more and answer any questions you may have!