[HN Gopher] Launch HN: Fogbender (YC W22) - B2B support software...
___________________________________________________________________
Launch HN: Fogbender (YC W22) - B2B support software designed for
customer teams
Hi HN, my name is Andrei - I'm the founder of Fogbender
(https://fogbender.com) and I'm very happy to be here. We make
customer support software for B2B vendors that makes it easy for
you to work with customer teams, rather than just supporting each
user independently. B2B companies with team dashboards can embed
our messaging widget to offer off-the-shelf shared support channels
to their users. The problem that we solve is a painful one for
both B2B customers and vendors, so I'll describe it from each point
of view. A B2B customer buys a product and has an ever-changing
group of people using it over time. Those users receive customer
support as individuals, not as a team. This gets painful when the
vendor can't answer a question because part of the answer is only
known by somebody else at the customer. This delays solutions,
creates confusion, and hinders the spread of information. A B2B
vendor sells to teams and wants to support them effectively. But
existing customer support products don't do that--they only work
with users one-by-one. To get around this, many vendors open a
shared Slack channel with each customer team. Now they have two
problems, because not only is Slack too unstructured for processing
complex support requests, inevitably not everyone on the customer's
end knows about the Slack channel. The vendor ends up running two
separate support systems, neither of which fully works, and now has
the painful task of trying to synchronize the two. To sum that up:
support products don't work with teams, and team products don't
work for support. My first startup was a team messaging service
(launched on HN as LeChat in early 2013!
https://news.ycombinator.com/item?id=5202381), where we created a
shared support channel for every customer--this is how we found out
about the power of doing support this way. When competing against
Slack got too difficult in 2015, we pivoted to sameroom.io, which
bridges rooms/channels between different messaging systems. We got
acquired by 8x8 in 2017, then built their messaging infrastructure.
While at 8x8, my team began using Segment Analytics, and usage soon
spread to other departments. I struggled to keep the deployment
sane because I had no way of knowing which of our developers needed
help. Segment supported us with Zendesk, which was aggressively
unhelpful. I knew the problem was important when I started getting
emails from Segment Analytics with PDF attachments outlining how
much money we owed them in overage fees--that was literally my only
exposure to the work other developers were doing with our Segment
setup. A lot of money and people's time was getting flushed down
the drain, all thanks to improper tooling. I decided to start a
startup to address this because (a) I thought we had the technical
expertise to do it; (b) it feels like the market is enormous; (c)
it's clear who the buyer is, and the price point can be relatively
high, and (d) I really want to use it myself. Our product is
similar to Intercom or Drift in that our customer (the B2B vendor)
installs a messaging widget on _their_ customer dashboard. However,
if the dashboard is accessible to a team of end users, all users
see the same data in the widget. They can use it to talk to each
other and with the vendor, just like with shared channels. We also
make it easy to link these conversations to support tickets in
vendor's issue tracker. Fogbender uses a pubsub-inspired messaging
protocol (currently the only transport is websocket, but we may add
others), powered by Elixir and Postgres. The frontend is
TypeScript, React, SolidJS, and Tailwind. We're fans of monorepos
and prefer to add supervisors to our BEAM supervision tree instead
of spinning up microservices. Our philosophy regarding the
messaging product itself is closer to Telegram than Slack. We like
to have the ability to view multiple rooms at the same time, to be
able to forward contiguous blocks of messages between rooms, to
have replies instead of anonymous threads, and to be able to follow
#tags. We're still working out pricing, so you'll notice "TBD" on
our pricing page, but our basic strategy is clear: a free tier,
after which vendors pay only per user with write access to
customer-facing rooms. Everyone at the vendor gets free read access
to all messages, and everyone at the customer gets free read and
write access. This way we charge only when real value (actual
support) is being delivered, and we facilitate the spread of
information between vendor and customer and within the customer
team itself. You can try us out now at https://fogbender.com.
After creating an account, you'll be asked for a code, but just
enter "HN" and it should work! To see what it's like to receive
help as a team, invite a friend/colleague and ping us in support :)
I'd love to hear your thoughts on the subject of offering and
receiving team-level customer support (or team messaging products
in general). If you have any questions about Fogbender, I'll do my
best to answer in the comments!
Author : rekoros
Score : 54 points
Date : 2022-02-14 14:33 UTC (8 hours ago)
(HTM) web link (fogbender.com)
(TXT) w3m dump (fogbender.com)
| awinter-py wrote:
| > B2C support tools don't work for B2B
|
| yes this -- so many build-vs-buy decisions that end up at 'build'
| because the market doesn't provide multitenant products
|
| b2b2b / b2b2c is a bet on a software future of many mini
| platforms
| djbusby wrote:
| I basically had the same issue, got frustrated with same tools
| you mentioned. We built an internal tool (CIC) to manage/annotate
| client email/phone/chat in one spot, tickets assigned to Company
| rather (or in addition to) Contact.
|
| I too see this need in the space.
| rekoros wrote:
| Yes, I've talked to quite a few folks who've built their own
| solutions.
|
| Interestingly, AWS _almost_ does this, but you have to know
| (and remember) the identities of those who should be CCd when
| opening a ticket.
| mmettler wrote:
| Andrei and team are awesome. We were customers of a Fogbender
| ancestor (a chat app that became SameRoom) and are excited to be
| customers for Fogbender!
|
| For a growing customer success org, being able to generate
| tickets from these chats is super useful.
| [deleted]
| kolencherry wrote:
| Love this. We ran into a lot of these pain points while we were
| building and growing Flex @ Twilio. We ended up creating a
| "shadow" support org in the early days that provided 1:1
| (product-led!) support to our early customers via Slack. That did
| not scale.
|
| You are aware of and are trying to address many the issues we ran
| into as we grew our customer base (e.g. pass to tickets, getting
| new team members up to speed, etc.).
|
| I am very interested in how you are planning on addressing the
| tooling issue, from the _end-customer_ POV. We settled on shared
| Slack channels because the majority of our early customers used
| Slack for their own internal comms. Using shared channels was
| very low friction for onboarding folks and provided a solid
| experience (vs. having to push them into another tool to get
| support).
| rekoros wrote:
| Great question!
|
| Here is how I think about it - by doing support through Slack,
| you're pushing your users to another tool to get support, away
| from your own product :)
|
| We'd like to make it really easy to fuse a team dashboard (e.g.
| Twilio Flex) with team support experience, so your users would
| get the same level of care they get with Slack (possibly better
| - because instead of a single shared channel, they have what
| essentially is an entire _shared workspace_ ), but without
| having to _also_ sign into Slack and locate the support
| channel.
|
| That said, I do wonder how much pushback we'll see because end
| customers simply love getting support in Slack instead of
| inside the vendor's product.
| karjaluoto wrote:
| I'm happy to see this launch, Andrei! You all have dedicated so
| many years to working on chat for business. I'm excited to see
| this out there, and watch this next chapter in your story unfold!
| [deleted]
| cube2222 wrote:
| This looks great! Definitely looks useful and with no status quo
| solving it well right now.
|
| I'd love to see what else people are using right now for this,
| and what the cons of that are compared to this - the real-time,
| team-based support chat use case, with included support ticket
| tracking. A combination of Slack shared channels and
| ticket/feature-request tracking that is.
| rekoros wrote:
| Thank you!
|
| To the best of my knowledge, people are using Slack's shared
| channels plus an integration or two (custom or off-the-shelf).
| rekoros wrote:
| I recorded a brief video showing how the product works -
| https://www.loom.com/share/da9861a4526b424f90a08e54aa6e5fea
|
| (Pretending that Stripe is using Fogbender for customer support)
| codegeek wrote:
| Funny because we (B2B SAAS company) literally built an in house
| tool to manage customers at a "Company" level rather than
| Contacts/Users. However we decided to switch to Helpscout as we
| didn't wanna self host and it has been a bad experience with
| helpscout. They have no concept of "Company" and we are honestly
| considering switching back to our home grown tool. There
| definitely is need for tool like this.
|
| I will be happy to beta test if you are offering.
| gingerlime wrote:
| we're B2C and whilst I love helpscout, they seem to have
| stopped innovating or caring about solving some pain points (in
| our case multi-language support). I can kinda understand most
| of the time, but some things just feel a bit too tight fisted
| to me... They still seem to be better than zendesk and
| intercom, but I really wish they would push the envelope a bit
| more...
| rekoros wrote:
| HelpScout is a super competent team inbox solution, but yes -
| it's simply not designed for supporting an entire company.
|
| We would love for you to beta test! You can kick the tires by
| signing up and inviting a few colleagues (ping us in support to
| see what it feels like), or I can walk you through a demo.
| codegeek wrote:
| Thanks for replying. I will test it out and let you know. I
| would also encourage to really "disrupt" (Yes I used the word
| here) pricing for support tools. Per agent/user pricing
| (zendesk/freshdesk/helpscout etc) really adds up for a
| startup/smaller teams and I would encourage you to consider
| flat rate pricing with limits of different types.
| rekoros wrote:
| I know what you mean. We're doing a few things in terms of
| pricing that (I think) are unusual for support tools:
|
| - Unlimited read access to everyone at your company
| (because customer support conversations should be
| accessible to all team members). Say you have 15 people,
| but only 3 are customer-facing certified - if we charged
| $15/month, it would be $45/month for 15 people. (This also
| means unlimited write access in _internal_ rooms - think of
| it as free Slack;)
|
| - No charge for two customer-facing agents, which would
| cover most bootstrapped or pre-seed startups;
|
| - Off-the-bat SSO; not a part of enterprise plan.
| codegeek wrote:
| Nice. 1st and 3rd points are gold. I would say that for
| read only, at least allow internal team members to
| comment/note on customer issues and consider that read
| only as well. That way, we can have more team members be
| involved in internal notes etc for a customer but only
| charge if we are replying ? Or may be add role for agents
| as "commenter vs customer facing" . We ourselves offer
| SSO with our lower plans and that is very popular. The
| whole old school model of "SSO only available with
| Enterprise" needs to die soon.
| rekoros wrote:
| Yes, totally agree on the SSO part.
|
| The whole reader/writer part is pretty confusing. I made
| a brief video that explains a possible workflow: https://
| www.loom.com/share/7f644774c3114e65b779d13d1c6eda18
___________________________________________________________________
(page generated 2022-02-14 23:00 UTC)