How to Best Support Your API Ecosystem feat. Andrei Soroker of Fogbender

Show Notes

This week on the API Intersection podcast, we spoke with Andrei Soroker, CEO at Fogbender, a B2b customer support tool for API-first companies. We often discuss how to secure the right development tools and scale your API program from there, but we often don't talk enough about supporting the thing when it's out in the wild. Supporting APIs is innately complex, and Andrei shared his perspective on the matter. 

_____
To subscribe to the podcast, visit https://stoplight.io/podcast

--- API Intersection Podcast listeners are invited to sign up for Stoplight and save up to $650! Use code INTERSECTION10 to get 10% off a new subscription to Stoplight Platform Starter or Pro.

Offer good for annual or monthly payment option for first-time subscribers. 10% off an annual plan ($650 savings for Pro and $94.80 for Starter) or 10% off your first month ($9.99 for Starter and $39 for Pro).

What is API Intersection?

Building a successful API requires more than just coding.

It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.

In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.

Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.

They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.

They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.

Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.

Welcome back to API Intersection.

So there's a thing
that, you know, with building API programs

and launching APIs
and all this stuff, you know,

we're so worried about
getting the design right and you know,

are we really fulfilling the right use
case? And,

you know, do we have all the right
development tools and all that stuff?

But I think in a lot of ways
the thing that we don't talk about enough

is how do we actually support this thing
when it's out in the wild?

And supporting APIs is innately hard.

So I'm super interested to chat
with today's guest Andrei Soroker

from Fogbender.

That's really what they're kind
of focused on and targeting on.

And I'm hoping we can learn some stuff
for the community here on

what Andrei is working on.

So Andre, tell us a little bit
about yourself and Fogbender.

Thanks, Jason. Good to be here.

Fogbender is a customer support platform
for API-first companies.

These could be SDK first companies.

We're really looking at firms that

sell something

that developers use primarily
as their main product,

and we've discovered
that often the vendors, these companies

that sell a contract,
they just don't know who their users are.

So you'll you know, you get an API key
that's being used by 25 developers,

but as the vendor of the API,
it's really hard to determine

the identities of these folks

who the best users are.

And we're seeing a bunch of stuff
being done in the space,

but none of it is kind of a

particularly

targeted toward solving this problem.

So you have a combination of community,

you know, discord or slack environments.

You've got all kinds of stuff.

But in general,
there don't seem to be a great solution

for sort of supporting
many teams of developers,

growing teams of developers
in some sort of a sensible, scalable way.

And that's the that's what we're looking

Yeah, the the product and

product guy and me have my ears ringing
from like Keith Casey

talking about how much you can learn from
the way people are using your API.

But I guess before we go down that track,

like what do you
you know, you're describing

something here about this kind of chat
expectation, right?

Messaging expectation.

But like what's unique
about supporting developers

in your view?

Well,

teams of developers,
I think the difference is, you know,

plenty plenty of products are used
sort of by developers individually.

You know, I don't know if it's an editor
or a compiler or something,

but when you're talking
about a complex product,

like an API that is integrated
into another complex product

and it's, you know, driving business,
inevitably you're going to be dealing with

an ever changing

team of very technical people
who are touching

the their own product.

And the API
kind of on this continuous basis

and I'm focusing on the word team.

And so in my mind, I've for many years
I believed in

what I kind of call team to team support,
where you've got the vendors team

and you've got the customer's team.

And the goal is to make sure that

a, there's kind of some succession
and continuity between these teams

as the relationship ages
because, you know, a couple of years

go, go by and then no one is around
from when the initial deal was was struck.

And how do you make sure that people don't
keep relearning the stuff from scratch?

How do you make sure that

that these two developers
who work on different continents

and happen to be relatively new quickly
find each other and understand

that they're both both actually working
on the same product using the same API?

That's actually
a very difficult problem to solve,

and I think it's solved by team
to team support where you're able

to maintain and keep building
those relationships over time.

So I think something like shared channels
does it really well in Slack where

everybody knows that this channel exists
and this is where the

this particular vendor's
team congregates, But

I don't think it scales particularly well.

And it's also not something
that's there by default.

It's not in the path of least resistance,
because that's shared

channel is not going to be on
on the vendors dashboard.

You're not going to be signing in
looking for the support section and then

discovering like that messaging experience
there.

You're going to be probably
filling out a contact form

or maybe, you know, seeing
an email address, support at or something.

But then you also need to know or discover

somehow that there exists this better team
to team experience as well.

But it's rarely the official sort of thing
that's out there.

So we're trying to solve the problem of
how do we make that that experience

on the path of least resistance,

something?

Yeah, Yeah.

I mean,

having been on both sides of this equation
quite a few times, I can definitely

it resonates that integration is a
is a team affair, right.

It's not like there's individuals

what's like a real and

or contrived example of what this kind of,

you know, looks like in reality.

Sure. So.

Well, I'll give you an example.

So we are relatively early, but we finally
have customers using our product and

how one of these customers
is one of our vendors.

So we're kind of mutual.
We're mutual customers.

And this company is called X Kit,

and they're actually

they're a CRM.

They're kind of a
I know you can say plaid for CRM.

Essentially they expose a single API
to work with things

like HubSpot and Salesforce
and other systems.

So you have to build the same
thing multiple times. So,

you know,

the way we talk to them
is they have got a dashboard,

we've got our team inside
of their sort of dashboard.

As new developers join our team, we
add them to to the exit, our exit account

and whenever you know

there is a support button,
you click on that support button

and you can just kind of see

it's more of a kind of a shared workspace
because it's got multiple

all the open issues
that are currently there.

Each one is essentially
kind of a chat room

and it's not a contrived example.

I think it's a very,
very simple example, really.

But essentially
their entire team is in there.

Our entire team is in there as well.

And no, I mean, if five years goes by,
someone could join either

one of our companies and potentially
go back and discover what happened,

figure out who the experts are.

That's really what it is.

But the key thing is we don't need to

know about some special place
for that support to exist.

We don't need to know
that there is a shared channel, right?

We need to join or open is just there.

It's if you have a question about exit
and you're working on my team,

there's no way for you not to discover

a place where I will see your question.

And that's really the the crux,
I think, of the solution at it.

Okay.

So digging into that a bit on,

you know,
kind of said like Slack or Discord

or these sort of things
just don't really scale well,

which I think this is, you know, for me
and kind of I think the listeners here

like this is the
the lesson that we can learn is but

what's going to break for you
in the future.

Right.

But reading into that, that story
you told there,

it sounds like the kind of
blend of like ticketing and

and just free discussion.

Yeah. Yeah.

So that's interesting because I mean,
it's like you hit this point where, yeah,

you can just have open kind of chit chat,
but at some point

you got to put more structure around it

and you end up,
you know, having your ticketing system

that you have to refer folks to
and then you kind of lose that connection,

but you get this durable record
of all the things, right?

And now you can build metrics
and all that stuff.

So it sounds like you guys are trying
to kind of blend that experience.

Exactly. Yeah.

There is this moment when

just a conversation
becomes something actionable, something.

I was like, Oh,
this is a feature that we got to build.

You know what?

What do you do?

And this is when I say Slack, it's
hard to scale.

That's where it sort of stops scaling.

Okay, we've got to thread, you know,
a couple of people know about this thread

and you know, this is a complex features
going to take two months to build

and maybe some other companies
are going to want it to.

And then you
you just kind of start losing these ends.

You start,
I think, losing the connections.

And in our world, there's a moment
where you say, okay, this is a feature,

let's mark, let's create a feature
and let's send that feature to JIRA

so that there's a ticket
that we can work into our sprint.

But we will continue to have this
dedicated not a threat, but a dedicated,

named, persistent, searchable channel

that anyone will see
once they enter the support experience.

You don't have to read through
unnamed threads

where you're not a member,
so you don't get notifications.

Yeah.

And so we're we're I mean, this is early,
but we're trying to understand

what's what's the easiest way
for us to create that

transition from like, triage, like, yeah,
we think there's something there.

We got to either fix a bug
or create a feature or maybe just

this is this merits its own

conversation that we think
other people will be interested in,

you know,

and how do we actually work
that into the product,

how we tie it into systems
like JIRA or song or ticketing system,

you know, where you they exist for you
to be responsible and not not your job.

The ball, that's that's the challenge

that we're trying to tackle now for sure.

And the other
the other part of this challenge is like,

what if the customer actually
wants to live in Slack?

Or what if the customer
wants to live in Microsoft teams?

You know,
they really don't care if you can

how you manage those conversations.

It's on you.

It's on the vendor.

You have to make sure
that the ball doesn't get drop,

the customer doesn't care.

They know about this thread.
They're going to remember.

They don't have to deal with 200 other,
you know, channels and unnamed threads.

So so we're also trying to come up
with a way to integrate

with things like Slack and teams
so that end users don't have to,

you know, be somewhere where they don't
necessarily

want to be or, you know, we're trying
to come up with a way for these end users

to get support, even if they're, you know,
not necessarily going to your website,

but they assume
that it's going to be Microsoft teams.

Yeah, yeah, yeah. It's interesting.

So, you know,
SOC vendors in a very new thing.

And I think what's interesting is
you kind of your background and story

of how you got here in that
it seems like you've kind of, you know,

been in this sort of messaging space
for quite some time

that kind of led you to this this notion.

So tell us a little bit more
about kind of how you got here. Sure.

Well, so in

2012, I decided that there needed to be

a proper team messaging system
because it just didn't exist.

The closest thing was hip chat.

And we

I just remember, you know, using it
and someone in Europe wouldn't

be able to, not because it was blocks
or whatever, just wouldn't connect.

Most of the time.

It was this gaping
sort of need for, for, for,

for a professional,
you know, messaging system.

And yeah, so that's essentially

how I started building messaging products.

Unfortunately, that product ended up
it was called Live Chat

and it ended up competing with Slack.

We kind of were building things
at the same time

The Slack team actually signed up for
for the chat and used it.

We and the way we met them
is we accidentally created

what is now known as shared channels.

We we had our very first customer

created a room and we had a
bug in our code and that room was visible

to us.

It's like the worst possible thing
you can imagine in terms of security.

And we were like, Whoa, this is so bad,
but we ended up

creating a feature out of that.

So so

we essentially started
making one of those rooms

for each one of our customers sign up.

And this is how I discovered Team
two team support.

I mean, some of those folks
ended up using a product

for like three years
until we shut it down.

And I remember just thinking, whoa,
like not a single

one of these people was there
when we first started using the product.

But I remember, you know,
I know how we met them all.

They joined this company
and there was a wonderful experience.

So I started thinking about

product sizing
something like this almost ten years ago.

And then we ended up we, we ended up
pivoting to a product called Same Room.

And, you know, one of the things we heard
while building WeChat was,

oh, like we someone's using WhatsApp
where Telegram or Slack showed up or

there were there were maybe 25,
30 different tools at the time.

And so we thought, let's see if we can.

Clearly there's no common protocol,
no one's exempt is gone.

But let's see if we can just sort of brute
force an integration.

You know, it's sort of some some sort of a

integration
that would be invisible to the end user.

And so we built same room,

which is an under the hood product
that just I mean, we reverse engineered

Skype and reverse engineer hangouts
where you could connect

a hangout to escape group
and chat as if you know nothing

interesting is happening

while with one team, as in Hangouts
and other teams and Skype.

And you know, that was a really,
really interesting project.

It wasn't particularly interesting
financially, but

the way I

narrowed in on on the fog bender.

So I think the thing to understand is

I sort of believe that
messaging really solves a lot of problems.

And I think that removing

communication silos,
so essentially making sure

that everyone can see
or at least have access to not necessarily

be, you know, pinged,
but have access to communication is

is the right thing to do.

It's sort of it's the way to scale.

Large organizations
hiding information is the way

to make larger organizations struggle.

So it's a very sort of idealistic thing
that I believe in.

But when we got acquired,
when CRM got acquired,

I joined a large company
that became like mid-level management,

product management, and immediately
started building a new product

where we I needed segment analytics and

we brought
that in and it started spreading

like wildfire
within this larger organization that had

I didn't even know how many offices,
but many across multiple continents,

you know, and most of these developers
who were

building against now,
you know, segment analytics,

they never got to travel,
They never knew each other.

They didn't know that their colleagues
existed at all.

Like there was no real sensible
way to know that.

And new new developers
would show up all the time right.

And I sort of watched this very nice

kind of simple deployment of segment just

it just fall apart.

You know, completely.

And I kept asking myself,
and then how I knew it fell apart

is because I was I was on the receiving
end of overage PDFs.

You know, this is like when you start
using a product too much, they start

sending you these PDFs, just emailing
you like, Oh, you owe us 20 $500

because you hit like 3.5 more million
monthly active users last month.

And I'm like, Well,
you know, that's way more than we have.

Users Like that would be fantastic.

But you know, these users aren't real now.

Like, yeah,
we don't know how that happened.

That's, that's on you
And eventually you reach out to support

they say yeah we really don't know
but we have this other like

tier where we can bump you up to
and then, you know, maybe so.

So it's sorted because I'm like,
How did this happen?

What's going on?

I realized that all these developers
that were on my team whom I didn't know,

they would reach out to segment over email
or some sort of system

that is inherently designed
to support individuals, receive

some kind of feedback,
some kind of recommendations that were

you know I've
been doesn't know our data model there.

Now we have 15 different IDs for a
for a user segment would never know

which one is the correct one
to use in a 35 year old company.

You know, that makes that happens. Yeah.

And yeah so I thought you know what?

If only we had some form
of a collaborative support experience

where
if a new employee in Romania needed help,

they would have no other way
but to talk to us.

You know, as a sort of a community
and working on this thing together,

that was it.

I just thought this needs to be there
on segments website, on their dashboard.

Once they sign
in, I want to see a support button.

And if I click that button,
I want to see everybody,

all the tickets that are currently open,

all the current conversations,
they're ongoing.

And so that these misguided,

you know, silos would be

would just not be needed or even possible.

So that's that's
kind of where it came from.

But but again, like it's
rooted in my belief that team to team

messaging is sort of the magic that makes

these sorts of interactions scale.

It's funny over the years,

you know, even from kind of the soap era
and all these sorts of things,

it's just like the notion
of integrating something,

you know, affects go like, Well,
what's that all about?

You know, it's like it's a very messy
personal business. Yes.

At the end of the day,
like it's, you know, in

some ways kind of a toe to toe affair
in terms of actually making things happen.

And and I know certainly over the years,
so many times, you know,

individual developers trying
to consume some API and just says, I can

I just talked to the dev who built this

so I can understand
how they were thinking about it.

Yeah.

So, you know,
I've certainly heard that many times.

I guess it's interesting to think about,
you know,

how you make those things scale

and that's very intriguing on like

within a company.

And I think that sort of behavioral
tracking like you're talking about

with something like a segment
is a great example. Like

it may not be one team that's integrating
with your API in a given company.

It could be dozens
or in a very large company, hundreds.

And how do you support that on a team?

By team basis?

I think that's an intriguing facet of

supporting APIs that folks
maybe don't think about as much

and think about it as this sort of
there is one way to support things.

Yeah, I think truly, you know,
these big successful companies,

they want to touch every department
in an organization, you know,

and they try to often,
yeah, this is how you end up

with different product
teams, different different pyramids,

using the same vendors

API and not necessarily being able
to tap into each other's knowledge.

You know, the other interesting thing
is one way to solve

this is through community support,
which sometimes works quite well.

And I think one of the best examples
was Stripe's IAC channel on Freenode.

I mean it was like

a and I think

there's this guy, right?

And I think he didn't work at Stripe,
but he appeared to be a full time

like incredibly knowledgeable
stripe engineer.

I think eventually maybe hired him.

There's a Hacker News story on this
for many years ago, but it was one of the

best ways to get highly technical support,
except you couldn't.

And this is a problem with community
support, is if you're working on something

that you can't

necessarily reveal to the outside
world, you've got competitors can't show

stack trace because someone will know
which what you're using.

I don't know.

Then this this kind of

sets up these boundaries around
what you can really do.

And I think the other problem with that is

true, like excellent

community support really depends
on the community providing support.

And you know, some companies
never get there.

They just don't have the community.

You need to become a country
really for there to be enough.

So certainly if you are and they can't
start with that, you can't cover that.

Yeah. Yeah.

So you see, you know, one of the problems
I see

with with Community Discord or Slack's
is that

folks think, well, we must have one,
but they don't necessarily

have the community, they're not a country,
they're not big enough.

And they don't have the time to sit there

and and be that person

whose only job is to dig
into other people's

technical problems
because they've got other things to do.

You know,

they've got other customers to support,
they've got code to write, whatever.

So so actually, you know,

we've been doing a lot of integrations
at Fogg Bender

and I see I'm often trying to find like,
well, how you get how do I get a list

of all of all of these repositories
from GitHub?

It's a, it's
a, it's a amazingly non-trivial problem.

And it's like, you know,

you end up joining these different

support

channels and often,
you know, they're kind of

maybe there's going to be
a bunch of people who are wondering

how to do certain things,
but not necessarily

the folks who have the time to respond.

So so that's that's
kind of another interesting angle

that I'm seeing right now where, you know,
it's a fine line between accessibility

to knowledge,
but also kind of the mandatory secrecy

of information that, you know. Yeah.

So, you know, it's
two very interesting points.

One is, you know,

there is often a very real sort of

business confidentiality
in some of these discussions about,

you know, you're integrating something

that no one knows about yet
and it's important that they don't.

Yeah, including your identity.

You may not you may not want people
to know that your company is using this

vendor name, which by the way, means often

these support, community support

workspaces or channels are filled
with folks who whose names you don't.

You'll never know
because they're using pseudonyms,

you know, And ideally
you would know who they are as a vendor.

You kind of want to know who they are.

Yeah, yeah, yeah, yeah.

And I think it's true up
and down the size of company scale, too.

I mean, I think everybody knows

the still startup thing
and all this kind of stuff, but

I mean I think of
some of the bigger places I've worked

where there were like,
you know, code named projects

that are need to know, right?

Yeah, because it's like a huge marketing
deal and they don't want it leaked.

So I can totally appreciate that.

I think the other facet there was like

how to scale that sort of

the, the mix of

sort of knowledge, expertise
kind of developer, you know, wherewithal

and be able to scale that across
many teams who were integrating.

And I hear from your stat

like you're trying to sort of provide
a solution to do that.

But I'm curious, you know, like

what's your take on a way
to make that reasonably efficient?

Because I mean, I got to be honest.

Like, you know, the

the business game is going like this
all sounds really expensive and I'm going

to have to put really skilled developers
on support channels all the time.

Like, Oh yeah, I have and you know,

might be true.

So I look at it

and I try,
I try to simplify these scalability

issues too, some actionable problems
that I see all the time.

So one huge problem
is that if you're a large enough company,

it doesn't

need to be a large enough company,
but you very often will end up multiple

customers asking for the same thing
or roughly the same thing.

And, you know, just managing that

simple sounding thing
is actually quite tricky.

How many tickets
should you have in your developer feet

and your internal issue tracker,
one or one per customer, you know?

Well what kind of either
one might be problematic, right?

Either solution.

So where proposing this notion

where we're sort of separating
the communication space.

So essentially let's just say that
there is a room or a channel per customer

for discussing this particular issue,
but there's only one,

you know, issue and GitLab or JIRA
for that particular issue.

And you can have you can keep adding these
these rooms per customer.

But they all tie back into the issue.

And so one of the one of the
biggest like I think product

epiphanies I've had was

when I used I used Intercom

you, you know, to segment users
and to communicate with users.

And it's an incredibly
it's really an incredible product.

And the problem with Intercom though
is that it's really designed again

for segmenting individuals
and not necessarily teams.

So what we're trying to do is say,
okay, let's borrow from intercom

idea of segmenting your customers,
but let's segment teams.

Let's say that we have 200

customers and let's say that 50 of them
have asked for this feature.

So let's create over
time, create the segment for 50 teams.

And these teams are changing over time.

Remember, they're not static, right?

Like new developers
come, all developers go

and let's come up with some kind of a way
to communicate with these 50 teams

at the same time, in a way
where you could do this in.

Intercom Right.

You can, you can sort of send
this broadcast message to everybody who,

you know, is interested
in this particular thing

and ask them, for example,
to try like a data version

where we were building
or we've kind of built a similar thing

for teams where you can say, Hey,
you know what, I've got this question for

everyone who wants this thing
or has complained about this thing,

and let's send a broadcast
into this kind of a public broadcast

to every one of these 50 rooms
where we know there are, you know, 50

teams sitting there waiting for us
to implement this thing for them.

And actually, I think that's
maybe how it scales is where you

you learn how to segment,

but not individuals, because that's
that's the thing that doesn't work.

You segment your teams, you're
putting your customer teams into,

you know, folks who need this
or need that or have complained about that

or have had this problem or have paid you
this much money,

you know, and then you start kind of

paying attention
maybe based on certain criteria,

or you start broadcast messages
based on certain criteria.

I think that's how it scales.

And I think it does scale.

And I think if you look at

the most successful API, first ring
API driven company in the world,

you know, they're not going to have
millions of customers.

It's never millions.

It's it's

maybe tens of thousands, you know, maybe,
you know, there could be millions.

But in terms of those that pay, it's
often a much smaller community.

Yeah, well, that's true.

But but when you're looking at again
deals signed right these deals

you're generally dealing on the order of
I mean very successful.

I think Optus has like
10,000 customers or something.

I mean it's a relatively small amount

and this
is sort of where we run into this problem,

I think with support tools, all of them,
all of the existing support

tools are designed for scale,
they're designed for Adidas,

you know, and Adidas has, I don't know, 2
billion customers or something, right?

I'm just But look, TurboTax,
I don't know, millions of customers.

And so that scale ends up, I think,

really taking up all the product effort
of, you know, a Zendesk

or an intercom or a front, and they just
don't have the time to do that.

If you look at Zendesk
organizational features,

you know, these are features
dedicated to supporting organizations.

They really have.

Nothing's happened there.

And like,
I don't know, like ten years because,

because there just aren't that,
there's just not much that much traffic

coming from those companies
and what what Zendesk doesn't know

that that this customer pays
$1,000,000 a year, not 12.

Right.

That's kind of the difference.

Yeah.

I think there's a couple of bits
that I'd call out that are,

that are lessons in here.

And I think the first is like

the support experiences often

has to be either super integrated
or super fragmented.

Your choice in the sense that

sort of identifying
how often do you have support

issues around
the same kind of thing can be hard.

Yeah, especially when you're going
from sort of a messaging environment

to some form of ticketing system,
which then,

as we all know, turns into some kind of,
you know, developer oriented issue,

which is often a different thing
than the support tool itself.

So I think that's an interesting
insight of like, you know, stitching

all that together and getting to something
that especially for product managers,

that you can look and clearly understand
where your priorities should lie.

Yeah, it's hard.

And then I think the second bit is

I think you're recognizing

that this sort of bottoms up adoption
within organizations,

the idea that it's, you know, sure,
there may be an individual who's

trying something, but if you really have,
you know, someone inside of a company

using your product
and then suddenly you have

two or three or 50 teams
using it, at some point,

there's there's kind of a you know,
that's where you can really engage

and get those bigger deals
with the organization as a whole.

But mapping out the organization
as part of that, I think a lot of people

underestimate the value of that
as it's not just saying,

you know, we see 20 people
in your organization using this,

but the we're actually able

to map out there's 20 different teams
and it's these individuals

who are using it can actually have
a much greater weight and sort

of, you know, bringing them to the table
on a bigger deal.

I think the movement that's trying to
product movement is trying to capture

this is called product
like growth, where you you're right. Yes,

it's a
marketing term, but it's really trying to

to sort of formalize
some some of the dynamics around.

But bottom up

adoption as opposed to what I kind of call
steak dinner adoption, Right.

Where you you have a bunch of nice
steak dinners and then the contract,

the sign of them,
the implementation phase begins.

And that's becoming rare
just for all kinds of reasons.

And I think one of the dangers

is for a vendor

who's whose product is being adopted

bottom up is to miss the point
where, like a big deal is on the table.

They may not understand that
this is like an old school

publicly traded company
that's using their stuff digital.

They've never seen it before. They've
never seen the name. They don't care.

And I think that's happened to us
actually with segment leaders

just going to they didn't
really understand the opportunity

that was on the table
and because it was really used

by just such a small team initially
and then they kind of missed the spread.

Yeah, I think it's funny, You know,
I said at the beginning that,

you know, this support stuff is something
that I think for a lot of API programs,

sometimes we don't put enough thought into
and like we just rattled through

how it can inform your product team
on, you know, where things are hurting.

It can inform your sales organization
on how this sort of land and expand

bottom up adoption is going

as well as just,

you know, sort of foster a better
relationship on a team and individual

basis that leads up to that point
that you may have kind of, you know,

a bigger
enterprise level deal on your hands.

Yeah.

So fascinating stuff.

So, you know, it's funny
because we so often we think

how do we make sure
that this isn't going to be too expensive

and that we're going to have enough
documentation.

Right? Right, Right.

Yes, absolutely.

You know, the other super
interesting thing just too, is knowing

when when your your good users leave,
when you know, again,

if you're selling an API first product
into a large organization,

you want to know
when your best technical champion departs.

And that's a signal that, by the way,
they never reach out and support

because they know everything
better than your own team, you know,

and just getting that signal
that this person

went to work somewhere else is important
for two reasons.

One is you should go
and sell your thing to this next company.

They're going

and to you know, you may not be able
to renew your deal with the old company

because all of a sudden
the champion is gone.

So just just knowing that is

automatically

without spending human hours,
you know, like, yeah, that is super true.

That one resonates for me all along.

Trust me.

Yeah.

Well, Andre, I really appreciate you
sharing all this with us.

I think it's

I think it gives our our listeners here
a lot of things to chew on that

you know, support is more than just,
you know, having the docs

and opening tickets
and that sort of thing.

There's really a lot to unpack and sort
of messaging integration of it all.

It's super interesting
what you guys are doing.

Thank you. This is great.