Let’s Have a Conversation: The Future of Omnichannel Service in HubSpot

This is Apollo Control. At 102 hours into the flight of Apollo 11, it's growing quite quiet here at Mission Control. A few moments ago, Flight Director Gene Kranz requested that everyone sit down, get prepared for events that are coming. And he closed with a remark. Good luck to all of you. 12 minutes now until ignition for power descent. Everything's still looking very good at this point. Okay, offline controllers, go now. Go for powered descent. Retro. Go. Fido. Go. Guidance. Go. Control. Go. Telecom. Go. Gen Safe. Go. Ecom. Go. Surrogate. Go. Capcom or Go for power. Decent. We're off to a good start. Play it cool. Okay, I'll fly controllers. I'm going around the horn. Okay. Retro. Go. Final Go. Gun. Go. G. Surgeon. Go. Retro. No. Lino Kaiser. No. Patrol downtown. No. Gnc. No. Acon. No Surrogate. No. Capcom. We're go for landing. Okay, everybody, let's hang tight and look for landing.

Radar.

75Ft down and half. Level two alarm. 60 seconds. We're going half flight. We're going. That alarm 30ft down two and a half. If it does reoccur when we go. 30 seconds. Okay, we're done. We've had shutdown. Tranquility Base here. The Eagle has landed.

Okay.

It foreign.

Welcome to the last DHUG event this year and this time something special. The future of omnichannel service in HubSpot. So if you're working with communications from all over the place, this is the event for you. And as you have seen, we have two amazing speakers, Eric Hirsch and Nick Drain from HubSpot. And our agenda will be. Yeah, very simple. So a quick introduction, then the main part with Eric and Nick. And then we will have time for Q and A. So if you have questions, drop them in the chat and we will answer them in the Q and A session. So therefore, Eric, welcome to the stage.

Hey everybody. How's it going today? I'm so excited to talk about this with all of you. I've been loosely following along with all the developer content this year and all the more of the technical themes. What's been going with HubSpot. And one of the big things has been customization in the form of user interface extensions and really bringing your world into HubSpot and having just the full power of not just a backend, but a front experience for your software, some other integration. And then historically there's been all sorts of things like HubSpot standard object models, you learn how to work with contacts or tickets, and then we introduce things like custom objects or custom events. This is something that's different, I think. I have this theory that people know a little less about Service Hub because it's kind of a newer hub and customer support and it's been maturing over the years and it's a really strong offering now, but therefore people maybe know less about the functionality and less about the technology behind it. Nick and I are the product manager and technical lead of two APIs that relate to Service Hub, the Custom Channels API and the Conversations API. And the interesting thing about them is that they aren't like object APIs. It's not like this is a ticket, you create, write tickets. They're a use case API because they can get into a whole system of HubSpot around communication. That's something that's been really important for Service Hub for the past years because we've heard from our customers time and time again that it's important to them. It's something that also hasn't been open to the ecosystem until now. So I'm really excited to not just talk to you, but implore you to build here and do really exciting things. Let's get into the details of this. I'm going to talk about Omnichannel, which is one of those buzzwords like transformation and AI. Talk about what that really means from a customer perspective. Give a little demo of this API in action because I think what you can do with it is the more interesting thing to talk about than just how you use it from a technical perspective. I want to demystify some of the concepts around this part of HubSpot because I think people are less familiar with them than deals and tickets and things like that. And I want to use that to help you be more confident as you architect and build solutions here. Then we'll do a little deeper dive of the demo where we're talking about how to use the API along the way. And like Anton said, hopefully there'll be time for questions and answers. This is just the obligatory legal slide that I have to do because this is an API in public beta, which means it's not live yet, which means I'll talk about stuff it does now and I might even talk about plans we have for it. But of course these things are subject to change and you shouldn't buy HubSpot because of something I say today, says our lawyers. So there's that, there's that out of the way. Just talk a bit. I'm going to do non technical stuff for a minute. So put on your like business owner hat you are dev consultancy or you're an app partner, or you're a solutions partner with a technical integrations wing. And you've heard things from your customers about channels and omnichannel. Some of our industry and customer research is really obvious, but here's some slides about it anyway. Like, people all over the world use messaging. They use all sorts of different platforms to communicate with each other as individuals. It's increased since the pandemic because of the time where we were all home. And also customers want to talk to businesses on those same channels. If I'm familiar with my phone and familiar with texting, it might just be easier than having to go on their website and fill out some convoluted form. So there's lots of trends about that. Even though email, chat and calling are still very often standard, usually used business channels, all those other ones that we use, like social channels, are becoming used by businesses as well. And we all know this as consumers, we love good customer support and we hate bad customer support. And there's a lot of ways that customer support looks bad, like you have to repeat yourself or you get tossed from tier to tier of agents, or you have a chat with somebody about a shipping problem that you're having and then when you follow up over the email, they're like, what are you talking about? And that's because that company's probably not used some sort of service tool that has all their sources of data, all their communication communications channels unified in one place. So I think you can see where I'm going with this because HubSpot is always talking about being the smart CRM with unified data to run your entire business, sales market and service. HubSpot has channels in our sales and service offerings. So this is where the more of that one to one messaging is. Instead of like broadcasting a marketing campaign to many people, we own and maintain eight channels and here they all are. But obviously there are more than eight channels in the entire world and customers still want to use those and they want to use those with service hub. HubSpot itself isn't primarily a channel solution. There's a whole category called connected communication platform as a service. We're not that what we are is we want our strategy of anything you see here, like all the features that people love about HubSpot, like the data and then using those business hubs to activate on them to achieve business goals and enhancing it with AI. And then all of us here on the ecosystem and our communities, all that working together channel is really just like a dimension that cuts through that Email works really well across HubSpot. Calling is maturing a lot but there's so many channels in our strategy. We want any possible channel to work equally well with all these things because that's what our customers and our businesses expect. So I mentioned those eight channels that HubSpot does do. There's a whole bunch of channels out there that we haven't built and we likely won't because we're an ecosystem company. There's so many opportunities for people who are experts at other things to build here. There's a few categories where I've heard lots of demand. I don't have a slide about it but I have like ideas posts with upvotes, tons and tons of emails and slacks from account manager that's like my customer would like to integrate Apple business chat with HubSpot. Is that possible? Like there is HubSpot customer demand for this. You can see it in a few different categories like international. The Asia Pacific region has been really helpful during our private bet and it's not surprising that they feel underserved by HubSpot's current offer because things like Line and Telegram and WeChat really dominate even business correspondence in in certain Asian countries. So those are kind of things that might could be connected to HubSpot. Some sort of vertical could be connected there. A lot of software companies do support over Slack with like Slack connect channels. And then there's I've talked to companies that do property management so they want to use their property management platform for support but right now they have to have it pulled up in a separate tab. They've got HubSpot over here and then the property management thing over here. So they've siloed their data, they've siloed their efficiency. There's even customers that have maybe we'll just call it truly custom like a custom object being just for your business. There's companies I've talked to that are a SaaS company and they have like something inside their app around communicating with service people and maybe for some reason HubSpot's web chat so like a front end JavaScript method is not the way they want to have messaging. They want it to be, you know, headless or backend. These are all opportunities for building up two way messaging in the support use case with HubSpot. Come on, slide. I've set this up. Partners and developers can do some really great stuff here but historically we haven't given you the best things to work with. I've seen people making the best they can out of timeline activities like notes or even there's something called the Communication API and there's a communication object and you can do stuff with that. And some people have said, hey, this is missing certain properties of communication. Other people go full custom and do a Serum card or UI extension, but then you lose all the HubSpot native things like reporting and automation. And also people have been wanting specifically to get into the Inbox For a long time. We've known that people want their channel in the inbox instead of on a single object record. So here's the until now, this is the big exciting reveal. Like this is a thing. There's actually two APIs, there's a calling channel connection API which I won't talk about today. I'm going to talk about the custom Channels API which lets you connect any text based messaging channel to Help Desk and Inbox. So I've now introduced this thing, Help Desk and I'm going to talk more about Help Desk and Inbox in a little bit. But the whole point for a service team or anybody who reacts to incoming inquiries from customers is they want all their channels. So Omni channel in one place, in one organized system, a CRM with some business use case on top. Because that's the thing that's going to make them able to efficiently tackle all those support tickets. Give quality service at scale, not get drowning in tickets. They need a good workspace with all that data connected together. This is the opportunity for any developer out there to do that. Let me do a quick demo of seeing this in action just to make this more tangible and then we can get back into some of the technical details. We're also going to take a drink. Pardon? So you might have seen or played around with inbox in HubSpot, which is the thing where you can connect different channels and then you can have a list of conversations here and you can organize them and filter them and view them and message back and you know, there's kind of a conversational interface, but then over on the right are other things like the associated contact or the associated ticket. This has been with HubSpot a long time. A lot of people use it for a lot of different reasons. Most people use it for support because it's kind of a good place to have like a catch all, you know, support at company or your live chat, wherever kind of coming into one place. But other people use it in sort of like this general inbox way. They might hook up like a general catch all email address or they might put their marketing qualification chat connected to here. In the last year, Specifically this spring, HubSpot launched something called Help Desk. And it is what it sounds like. It is a workspace that is tailor made for support teams. So the difference about it is like support means tickets. Tickets is its own object. What people have been doing before all this is they've been having the inbox open in one tab and the ticket list or a ticket pipeline from HubSpot open another tab. So it's still that same two tabs problem. Help Desk is something that combines all that into one workspace. It's still evolving with people's feedback. This is a list of tickets, not a list of conversations that all come to one place. You can filter them and view them and organize your teams and when you click into an individual ticket, the ticket has a conversation. There's all sorts of great ticket automation and routing and assignment like all the things that a support team needs are just all in this one place. You never should have to navigate away to a contact record or ticket record or anything like that. I won't give a big deep demo about Help Desk and we've got the Academy course about it there for Service Hub and Help Desk if you want to learn more. But the reason I mentioned this to you is that if you're building for conversational things in general, think Inbox. But if you have some solution that you're trying to pitch your customers around customer support, it would be wise of you to learn more about Help Desk, learn how to position Help Desk and learn how to build for it. The good thing is that under the hood, at least from a conversational perspective, Inbox and Help Desk are the same thing. You can see that they look the same. There's just different features surrounding it. And I'll get more into that a little bit too. So I can connect my HubSpot channels. HubSpot owns channels to help desk like Chat or HubSpot. You know our email integrations with Google or HubSpot calling. But if I go to click connect a channel, there's this thing here called Huddle Hub. And that's not a HubSpot owned channel. That is an app for our own team has built like an internal test app. So we have an app called Huddle Hub. And what Huddle Hub does is it uses the custom channels API to add a channel that HubSpot hasn't built. Things. When I see that I can connect it to my Help Desk or Inbox and then once it's connected with certain kinds of settings around routing or notifications and things like that. I can use it. We'll actually try and do this live here and send in a message in our just internal test messaging client where we used to test things out. I've now sent an incoming message across the API and I'll go back to Help Desk and see how long it takes for that to come across. Oh, there it is right now. Right. Or actually that might be the one from 20 minutes ago when I was doing the same testing thing. Right, testing at 153. Yeah, we're at 2:18. So these tickets kind of come in across this and they look. The thing is it looks just like any other conversation in Help Desk. It feels like it. You get notifications the same way you can do reporting. All that's the same. It's just that this view of messages happening in and out. Oh yeah, there's my current message. I didn't start a new ticket. I was using the same contact, so it kind of added to this one. I'll say I can help you. Here I am like in the native reply editor, not something that you have to build with UI extensions. I can send something back and it comes back. So, you know, pretend this is Telegram or Slack or whatever. So really any channel can be connected to Help Desk and Inbox and all the native HubSpot functionality with it, like AI and reporting, all just works as long as you're sending messages and receiving messages back and all this kind of stuff. So just so many exciting options and that's going to be great for your support teams because it looks and feels just like everything else they've used in email and chat. Let's talk a little bit about how to build with this. And I'm going to do this with like some conceptual stuff first before. I think that's probably more helpful, at least in my experience now, like consulting with certain partners and people. The harder part is like how do I map the thing I want to integrate onto HubSpot, which I guess probably common of all integrations, like how do I take those concepts and map it to HubSpot's APIs. So too with channels like if you are an expert at Slack or Telegram or WeChat or your own thing, you need to figure out how that is modeled and how to map it to HubSpot. So I want to talk about that because those things are not things that we've trained on as much and this is a great opportunity to do that in a pseudo technical way. There's basically four steps to using this API. One thing you do once and then everything else happens in a cycle. You create a channel and then for anyone who's going to install it, they install their instance of your channel, their portal, and then you just send messages in. And we'll give you web hooks for messages. When you know I pressed send in Help Desk and it goes out, we'll give you that web hook and then it's your job to go send that somewhere. That's really it. There's no also needing to make a timeline activity. There's no needing to do anything with front end. And the reason that's the case is because all these great, I keep mentioning all these great things that come for free, not that it's publicly facing or that it's some branded thing, but there is a communication platform that is a part of Service Hub that underpins all of our channels. The HubSpot built ones are abstracted into this general communication platform. So too are our custom channels APIs and conversations APIs. The reason that everything works the same is because this is the same and that consistency is a real win for everyone. It speeds up your time to market. It lets you have working software sooner. So it's actually probably more helpful to talk about some of the concepts here than to name an endpoint. You've seen them before. If you ever have read the Getting Started guide to the Conversations API, it goes through what is an inbox? What is a channel, what is a thread? Those are the things I'm talking about and those are the same things in the Customs Channels API. It's just the difference is that I have a slide for this I can add in here later. The Conversations API is more about like administrative tasks, like getting conversational data out or enhancing a messaging experience. The Custom Channels API is very specifically about creating and then owning a two way messaging channel and being responsible for the sending receiving of messages across that channel. So I wanted to take the time to take this prose documentation and do it a little more visually and conceptually. Here's this communication platform piece of HubSpot that really just deals with messaging. It's connected to Help Desk, it's connected to Inbox, they're powered by that same model. And it's also connected to the CRM most directly. Like the concept of threads inside the platform relates to other objects that might show up in filter views like Conversations or on the timeline like Communication. It kind of stinks that all those words are both interchangeable and separate technical concepts. And that's why I want to take the time to try and Dispel some of those things. So at the highest level you might have heard words like portal or account. Like an instance of HubSpot, any an instance of HubSpot and a HubSpot account can have one Conversations inbox. If you're Pro plus, you can make many conversations inbox and if it's service hub Pro plus it can have a help desk. So that thing that's a help desk or a conversations inbox, those are all the same entity in the API. They're all called inboxes, lowercase I. They have an inbox id. So that's what I mean when I say that these things are really the same. To make that less confusing, if you ever to use the conversations API to get inboxes, there's a very helpful property now that very specifically tells you is it an inbox or is it a help desk? Because technically both can have different friendly names. Like here's this is how you say help desk in French. But you know, what if somebody did something else or what if they named in the box something? So this type indicator is very helpful. It doesn't change anything you do about how you use either API. It's more like it's just helpful information to you to know what other features a user has available to them. If they're in the inbox, it's more of this generic thing if they're in help actually doing a lot of stuff with tickets. So inboxes have channel accounts. That makes sense. A channel account is like infoompany.com and supportompany.com those are two channel accounts of the type of channel called email. Channel is this thing that exists outside of any portal. It's just a concept in HubSpot, email phone, WhatsApp your channel. But a channel account connected to an inbox connected to a portal, that's a channel account. That that whole string of like this is this person. You know, it's like this is my phone, it has a phone number. So that's those concepts. And then if we get into actual messaging, you saw the screen before. This is like this list of things in inbox it's a list of threads because it's just more of this conversational thing. In help Desk, this is a list of tickets because it's more of a ticket based workspace. But no matter what, the middle pane is always the thread. The technical word is thread can also call it a conversation. And that, you know, that maps onto what we feel like a conversation is it's people taking turns going back and Forth talking to each other. And each of those turn taking things is a message. So a thread has many messages. Not surprising. It's pretty universal, right? And a message, a single message has a sender and a recipient. And a single message has a direction that's indicated in the ui. Traditionally, the way we orient is that incoming, because this is for support instead of for just like general, like social media, something like that. Incoming basically means your customer's customer into the support team. Not going generally means the like the support people are sending a message back out. So it's all relative. That's just the orientation that we've chosen. Messages have content, messages have attachments, recipients and senders. That's just like an idea, you know, just like a letter you get in the mail. Further, each of those has some kind of identifier. Like, and there's three types. There's email, phone and other. Those are the not technical words for them. The technical other one is called channels Opaque id. But conceptually those are the things. So you know, an email address, a phone number or just something. And when you're building your integration, your channel will tell you which ones of those to use. With HubSpot, like if you're doing an SMS integration, you're probably gonna be using a phone number delivery identifier type. If you're doing Instagram, it's probably the, you know, the other. And the one thing I want to mention here that becomes important when you're starting to build integrations is that note that like when you're sending in messages or sending back messages, you aren't giving us HubSpot contact IDs, and that's not what we're giving you back. You're just giving you the thing that the channel cares about. So there's like a layer between who is this person really, this contact, this prospect, this customer, and just the fact that people are messaging that's on purpose. Because especially in reactive support, there's lots of what you see in HubSpot called Unknown Visitors. A lot of people you've never heard of that aren't in your database yet are messaging you, asking you questions. And you get to choose even if you want to put them in your database or not. That's why this is centered around these delivery identifier type things. Service Hub itself, the communications platform, that's the thing that handles associating to contacts. There's manual options for support reps to do it. They can click buttons and say, you know, I want to add this conversation to this contact. And there's also some automatic association, especially on email and we're also kind of iterating on our phone number automatic contact association. So those are the things about messaging. That's how we model messaging in HubSpot there's more little kind of features, but that's the core stuff. And when I've been like advising people who want to build apps around this, they've more had questions for me of like how to think about channels versus channel accounts and how to understand the messaging concepts. So I hope this little visual thing is something that people can come back to over time when they're thinking about it. And the reason that all that is important is because you're trying to make it be an intuitive experience for those users and HubSpot. And the more you can find the best way to map onto our standard model all of our HubSpot features key off of this standard model. That's the really exciting part. I haven't yet talked about this thing called channel capabilities, but what's really fun is this editor down here is dynamic. If you specify to HubSpot that your channel is SMS, like not even MMS, all this stuff will be hidden because there's no rich text formatting in sms, there's no attachments in sms. That's what we mean by like. When you conform to our standard model, we'll help your users have the best experience so that they don't shoot themselves in their foot or cause things with errors. That's kind of the general promise of this whole thing. The model might not fit your use case and in which case we'll take your feedback. But the upswing I hope is more valuable. What I wanted to do now because I'm seeing that my wonderful developer relationships are kind of helping answer questions questions quickly as they come. Or maybe you guys can help with what? What are the top ones to do in order when we get to Q A? Because probably only got another, you know, like 10ish minutes of like preset content. Because I want to do that same walkthrough I did, but this time talk about the API calls and things that are happening as they go. And for that, and just in case for color commentary, I do want to bring on my good friend Nick Drain to say things with me, especially if I get something wrong. If I'm talking about an endpoint in a certain way to keep me honest. The very first thing that happens, like I mentioned, is that you register your channel. You make a channel like you're literally getting to be in our database as a channel alongside HubSpot's other things and that happens outside the context of a customer portal. Like you do it in your developer account with an app. So your app kind of owns a channel. Like informally we use this term channel owner. So that means you authenticate with your developer API key. That's kind of the only not portal kind of authentication. I just kind of copied something here from own documentation. But thankfully you can create and then update your channel. But it's something you want to think carefully about like what is it called and where is. Where should I. Where should HubSpot dump all my outgoing messages? And I mentioned this thing just a second ago. Capabilities like we have a whole list, you should check our documentation. They all exist because some feature in HubSpot does business logic based off of these. So it'd be good to read the documentation and figure out which ones make sense for you. I just mentioned the example of SMS for which allow inline images would definitely be false. That's just not a thing in sms. It is in MMS or RCS and all sorts of things like that. The other important one is delivery identifier type or maybe types like if it's sms you're probably going to say my channel uses phone number. If it's email you're going to say email. If it's something else, you'll pick something else. You tell that us to upfront and then anytime someone connects an account of your channel to HubSpot that way we kind of know what to do. So that's more or less like a one time thing but of course you can update it if you need to adjust it. And then there's the thing where we start to get into like what admins are doing. And there are two ways to do channel account connection. One is really simple. I'm not going to show it because it's just documentation about it and it's really good. In the case of you're just making a custom channel integration for yourself or like you're a solution partner doing like a one off for one customer. It's basically like a way to just like directly force a channel account connection. It means you need to have certain access to that portal. It means you need to have access to like whatever credentials you need about that channel, but you can just make it happen. But the one that is really exciting for anyone who wants to make an app that they give to multiple customers or especially people or app developers who want to be in the marketplace. We have a really cool experience that you can run and it's both a front and back end experience and I want to like demo that. But talk about some of the things that are happening under the hood which again then I'd also refer you to the documentation to read more about the actual details of. So here again is that connect to channel screen. Remember I mentioned before that this is for admins. This is more self service. They install your app which means they'll see it in connected apps and then when someone comes into Inbox or help desk and clicks connect a channel. Provided you've done some certain things correctly and configured some certain things that are documented, your app will show up here as something that they can click on. This is still a HubSpot screen so we're kind of giving them a like this is what you want to do, is that sure. And when they say continue with huddle hub a window pops up. This is going to be your window. So there is a property of a channel that is. What is this URL that you want people to come to? I think it's about like a 600 pixel window. I forget the exact name and I won't estimate.

I guess the channel account connection redirect.

Your so long but like it's accurate. That is what it is. This is not what yours would look like. This is our like testing that just kind of shows the properties that we hand to you in the query string. They're relevant properties like what channels this customer want, what Inbox is this customer saying they want to connect to. What is the user of the person doing all that kind of stuff and there's information that you can have them send back in some kind of form. Your form wouldn't look like this but it was probably gonna be some kind of like friendly name they give the channel. Just like you know I think one way to think about it is like in email world we talk about a sender address. Like what is the like brand, what is the identity on that channel. I think an easy example here is say you're an SMS app partner and a company has phone numbers with you that use for different things. You might do a pick list of phone numbers and say this is the phone number from their account that is going to now be like the channel account phone number that connects to help desk. You probably wouldn't expose these two things directly to your users. These are things you're going to hard code under the hood. That's just kind of some of the stuff you do. So I'm just going to put in some nonsense and you kick back to us with some certain parameters because we've given you a URL that you need to redirect to. If you've done that successfully with the parameters from the front end successfully, you have basically hit the custom channel API with some channel account creation. Is that true? Nick, it's not a backend API call. To create a channel, you're doing things on the front end that hit our service.

No, your front end app is going to need to hit your own server and then your server is going to talk to us and actually translate what we call the staging token into an actual channel account.

Yes. I didn't mention that concept and I should have. This is why product managers should not explain APIs entirely on their own.

You did a good job.

Yeah, I get like a B plus. My safety is read the docs. Read the docs to be sure. Because even I'm. Exactly. And so this is HubSpot after here. Now we're back in HubSpot land. The account, you haven't seen it just a B. I can take a B, I'll take a B. We'll grade on a curve and I'll still do fine at the end of the semester. So now we're back in HubSpot land. Your part of this is done. The admin now is just going to do some different stuff. They can set up routing on this channel, they can set up some ticket properties. Like hey, when it, when a new conversation comes in from this channel, what are some of the ticket things that should be automatically set? That's all that happens. And it is connected and they get a success screen. Sure enough, there are my nonsense connected channels. That's great. You can imagine that this just makes sense for an app marketplace because everything set up needs to be self serviceable. Instead of you personally somehow accessing a portal and somehow receiving certain channel specific credentials from a developer, this way you can have a front end experience that joins all those things together. Cool. Now I'm going to go back to my other screen and we'll talk about once it's connected, there's messaging. No, that's settings. Present, Share, screen. Say what you're doing out loud. This one. Cool. Thanks, Dennis. So yeah, our channels are connected and yeah, this is. Now there's really just two things left. One is the post incoming messages API call. And that's essentially what's happening here in our own internal test environment. Let me put in my email address, I have a contact with that. Your message is going to say, hey, it's this person. It's this delivery identifier. It's this portal is this channel instance like that is the specific pipe over which to send this message. And I can say, I have a question. And you post that message and at some speed it comes in. Well, it should come in. We've been having some problems with our test Huddlehub app. Ah, there it is. So that's cool. I didn't even have to set up notifications. They just worked because it's that same communication platform so that tickets come in. And there it is. The capabilities of this channel do have rich text, so I can put in rich text. Our interface doesn't have it, but if I do something here and send a message, that'll be a web hook to you with a bunch of information and you read the documentation about that and then you deliver it back here. We've delivered that back to this ui. That's it. That's the whole API. But the exciting part about it is it focuses on messaging and just tailing your channel to HubSpot so that all those HubSpot features can take place around it. It'll be really interesting to see what people build here and when they bring specific channels and specific use cases, what's working, what's not working. That's why we're so excited for people to adopt and work with us during this public beta period. That is the end of my content. We're generally going to make this live next year, depending on, you know, we want feedback about this public beta. We're working with at Marketplace people to have some turnkey integrations. We will also get the sister Conversations API to live. It's just because we're working on this first. So all these things are really kind of coming to fruition in 2025. But right now we're in this period where the more people can build us and do things with us, the more feedback we can get, the more we can improve the documentation, the better for everyone. That is really the end of my content. And wow, we are just here at Q and A. Oh, you know what? I should mention it's important for you to be aware of the packaging of the Custom Channels API. The word custom has heritage with objects and events for a reason. Those are things we think of as being enterprise features. The way it's packaged, is that at least how it works now? If you want to build something with the Custom Channels API and you're going to use it, it works with public apps, not private apps. Right now, the way it works is the customer needs to be on sales or Service Hub Enterprise, especially with the way we're repackaging around seats. Those types of things are number one more attainable financially. Number two, this just has competitive precedence with a lot of other people are doing. And it's also a boon for anyone who is trying to get people to mature and to become sticky with HubSpot. What we haven't implemented yet, but we'll try and figure out is that if the Customs Channels API is being used by a Marketplace app, we want to make those turnkey integrations more broadly available. Turnkey integration Pro plus we've not really seen many use cases for this type of sophistication at Starter. That's why we're choosing to package in this way. So like if it's just for you, it's enterprise. If it's for more people, it's pro is kind of the simplest way to think about that. The reason I want to say that is I don't want anyone to think that you can use this with HubSpot free and then you kind of get bent out of shape about it. So this is part of our strategy. This is part of who uses Service Hub which are tend to be more sophisticated companies than people who kind of start with marketing Hub. So that all kind of matches up. So there's that information which is also documented and now we've got lots of learning more links, blog posts, devrel content. Now I'm just happy to do Q and A and kind of do live questions and go through any ones we we missed.

Eric, I, I, I, I'm gonna take it back. I think that B is a solid A. I think you really just nailed it and I'm very proud of you. Really just thank you.

You know what, it's funny, it actually is exam season. Like if we were under we would be freaking out right now about funds. That's true. It's true.

And I want to just lead with this because I think John's said it. Simple to implement, incredibly powerful. I think that is the message, the motto and I think he will sell that to you for a low cost. Okay, I want to go to the Q A questions. If anyone else out there has any questions, please throw them in the chat and I'll try to get to it. But looks like Johan Sebastian Cortez Marquez, who has maybe the best name I've ever heard in my life, has all the questions presently. Let's start with one which is a two, two sections here, question here. If anyone can help when customers send a message via post to HubSpot Custom Channels, it returns a thread ID. They're planning to associate that conversation to a ticket, but to do so they need conversation ID rather than thread id. What would be the the way here? Rather create a ticket off that conversation. So no association needs to be done. I am going to let Nick handle that one real quickly.

Yeah, you know, the TLDR is. It's not something that we support at the moment. It's not that we definitely want to support it, but at the moment it's not possible to manage associations. It's technically possible to manage associations for conversations, but it's not something that we have, you know, sat down and invested effort and to make, you know, seamless yet.

But mention these questions I think is really important and these are the things that Eric and Nick like to hear so they can take it back to the team.

And I want to put a strategic lens on it, which is that in the specific case of conversations and our platform, that's really complicated and powerful and so too is the CRM itself. I know there's such a deep and rich community around people from the outside the ecosystem doing really clever things and directly managing associations in a way that makes sense to them. Where we're starting out with service, because this is about very specifically the reactive support use case. This API would not. For a variety of reasons, this isn't a good fit for sales because a salesperson's not going to want to be in like a shared inbox with all their other friends. You know, they want their own cordoned off prospects. Like that's just not how this is built. This is good fit for support and bad fit for everything else. The whole premise of Help Desk, I'm going to lean into Help Desk a little more than the conversations inbox for. People are used to hacking things and being clever with workflows is Help Desk itself does all the associations for you. Like we'd rather you not have to worry about that. I know that developers still want to do it anyway and there's always valid use cases, why people want to directly manage certain associations. But at least with Help Desk it does the conversation to contact and the conversation to ticket association automatically on its own. That's what I mean by like you just have to send in the message with the right delivery identifier we'll pick up the rest. So in a way it's less work for you. And I think that's going to work like Pareto's principle, like hopefully 80% of the time and then it's going to be 20% of people trying to do wacky awesome stuff. And that's where this feedback kind of is totally relevant. And we're going to say not focusing.

On that now, but I totally hear you, Johan. Followed up here. So need to be a different API call because we also need to be able to retrieve the ticket ID by the post or webhook that are exchanged in integrations.

Correct?

Yeah. Okay. But we have good news here. It hadn't announced it, but you can now. When you read a thread id, you can find out the associated ticket ID with is in the endpoint documentation. We just haven't put that in the change log. We know that's been one of people's biggest bugabears, especially because what Nick's pointing to is the thread in the communication platform isn't the conversation object. You've seen conversation and communication. You go, what's those? They're not the same thing. You'd think they would be, but they're not. We'll go into a whole different story about that. But since they're not, we can at least when you retrieve threads, tell you the ticket ID so you can start to string things together. That's the endpoint documentation. I can send the link for that. Your turn, Nick.

Now, I was just going to add some additional detail and then we're also looking to support the inverse in short time so that you can take a ticket ID and search for the threads associated with it.

I'm also putting the chat real quickly. There is a custom channels beta channel and the developer Slack, which I highly recommend if you have questions, thoughts, feedback, etc. Throw it in there because I know Eric, Nick, both they, they check that on the regular to make sure they're keeping up with it.

Yeah, this tenor of conversation is perfect for that. Also, yeah, we just did that thing like in Marvel interviews where like Tom Hiddleston like accidentally leaks something coming up, but like it was totally scripted. We're working on a search endpoint in the Conversations API. Just heard it.

All right, moving on. Johan, there's one more question here and if anyone else has one, please put in the chat. I'll get to it. I also have more of a curious question given that now we can trigger workflows based on webhooks. Could Operations Hub, CCAS or WebEx work as the middleware that picks and delivers messages? Interesting.

As someone who personally hasn't directly used OP hubs and workflows, which I know are rather powerful, I think I can only say you could try it probably gets into scale. I think we internally kind of know what sort of messaging volume we tend to expect on our own channels. And I don't know if that kind of matches up with what you can reasonably do with workflows versus what's a terrible idea to do with workflows. So I can't give enough, you know, I can't give an official thing. That's a really fascinating idea. This is why I love our developer community.

I think this is an assignment for Johan to get back to us and reporting that the developer slack how that works out. Okay, I do not see any other questions. With that said, I will once again say developer Slack things in there. The feedback is very, very important. This is again our last developer hug of the year. I want to thank Eric and Nick both for doing this for us and the community. I expect to see them again next year because there's a lot going on in the space and it's pretty freaking exciting. So thanks y'.

All.

Happy holidays everyone.

With that awkward pause, I'm going to end the stream and talk to you all soon.

Bye. Bye.