Decentralize the Help Desk: Redefining Web3 Support | Mickey Negus - The Graph

[Music] hello everyone thanks for joining my talk today I am Mickey Nas I'm a senior engineering manager at Eden node which is a core developer of the graph protocol my topic today is decentralize the help desk redefining web 3 support so I intend to share some lessons learned from the graph in providing support for a decentralized protocol let's get into it all right so if you're unfamiliar with the graph this is a pretty simplified view of our protocol but ultimately the graph is a decentralized indexing solution so we're indexing blockchain data and then organizing the world's knowledge and information at a high level daps ultimately need blockchain data to display on their front ends and it's really arduous to do that themselves so what they can do instead is develop a subgraph which is an open API by developing their subgraph they're able to access blockchain data that indexers have already indexed and organized for them and then that way they can display the data directly on their website without doing the heavy lifting if you work for a web3 protocol and you're interested in providing support for a decentralized protocol you probably have similar roles in your ecosystem as well and providing support for multiple different user personas can be complicated so i' I'd love to share what the graph has learned so when we look at the current web3 support landscape there are a number of challenges in providing support for a decentralized protocol decentralization is our superpower but it does introduce a lot of challenges around coordination and communication common web 3 support frustrations include a lack of accountability often users don't even know who's responsible for providing support in the first place often times there's no source of Truth around documentation or troubleshooting information and when they do receive support a lot of times users see very very slow support response times and if they do receive support eventually often they're met with canned responses or protocols that overly rely on bots so the challenge is how do you provide timely world-class support across a decentralized protocol and we believe at the graph that for web 3 to reach its full potential we need to rethink how we support our users and their unique needs and how do we create systems and processes that are collaborative across a decentralized protocol but ultimately responsive to solving customer issues so in doing this it's actually quite natural to look at web 2 for inspiration but there are a number of existing flaws in web 2 support models so while there are some pros and cons um in leveraging web 2 support systems the pros being maybe there's tooling that's already already been vetted and proven to work at scale but the cons being often web two companies are centralized so they own the complete uh endtoend technical support hierarchy they own all of their tooling and everyone who provides support Works within one single centralized company which is just not the case for web 3 protocols so in a centralized web 2 support model the speed of response for customer issues and the quality of service provided are often constrained by the techn skill level of L1 support Engineers your first layer of support and also frankly by business hours so some web2 centralized companies offer Global 247365 support but a lot a lot of those companies also don't do that and we don't have an option in web 3 support needs to be on and available 247 365 or else if you only operate support against certain business hours you create a ton of bottlenecks for your users so web3 protocols can end should leverage the parts of web 2 support that make sense for them but ultimately we believe that providing world-class support in web 3 requires a revamped approach so let's look at the graph solution our goal is simple we want to keep users at the center of everything we do in providing support and we want to ensure that the support we're providing is as sharp and performant as the technology that we're building there are many contributors to the graph protocol and we have successfully set a gold standard for decentralized support in web 3 instead of keeping this internal we don't want to gatekeep it we want to share our lessons learned with other web3 protocols so that everyone can help level up the support ux across all of web 3 together so let's get into it I'll Now cover the graphs decentralized support Playbook so we've centered our support around three pillars people processes and tooling these three pillars have enabled us to provide worldclass support across a decentralized protocol let's look at Pillar one this is our people pillar so our level one L1 support Engineers are technical in a lot of cases uh the L1 support team at many companies are are actually non-technical and they often serve as just a router for copying and pasting user issues to another tier in the support hierarchy and we have done away with that our L1 support Engineers are extremely technical they are users of our protocol and they're able to resolve user issues much faster number two you need to be able to follow the sun distributed team as I mentioned before web 3 doesn't sleep there are no business hours in web 3 and so you need support engineers in major regions around the world to support your Global user base this one's kind of contentious but I believe we should provide no canned responses ever this is because when you have caned responses it drives a lot of back and forth between your L1 support engineer and a customer to even get to the root of their issue and by doing away with canned responses and providing bespoke messages to each customer we found that it's way faster for our L1 support team to identify an issue and resolve it next um borrowing this from Joo willings book on Extreme ownership but you should establish and reinforce a culture of extreme ownership on your team your L1 support Engineers should know that each customer issue is Theirs to own until they resolve it or escalate it to another tier in your support hierarchy and lastly we're at a hackathon here today if you're offering a bouny from your protocol your technical support team should know exactly when the the hackathon is occurring so they can resolve issues if your devs who are trying to go after your hackathon Bounty experience issues at a hackathon and they don't get timely support it impedes their ability to pursue your Bounty so your tech support team should also be plugged into to providing support during hackathons or other realtime events events all right jumping into pillar number two this is our process pillar so first we suggest you set a competitive time-to First Response or ttfr SLA whether you advertise this as a formal SLA publicly or just an internal ttfr Target this is very important in ensuring your team members know what the Baseline time is that they have to resp respond to customers within similarly if you're offering an uptime or quality of service or reliability SLA you need to look at all of your Upstream components software and services if your Upstream services offer a lower reliability SLA than you offer you're putting your ability to achieve that SLA at risk next you should enable different contributors across your decentralized ecosystem to participate in the support model an example being your L1 support team doesn't actually need to be your Discord Community moderators if you have let's say a Dow in your ecosystem you can put out a grant for the Dow to manage your Discord server and allow your L1 team to remain focused on resolving customer issues next you definitely need processes for uh writing RCA root cause analyses or post-mortems when you have major breaking issues this is a key process for you to have in place to ensure you are solving these major breaking issues at the root nothing drives customers crazier than dealing with major outages over and over and over again so this process is key in ensuring you don't have repeat issues arising and lastly you should be bringing support to where your users are if they're on your website they should get support there if they're in Discord they should get support there so ensure you have processes in place to bring your support team members and monitor and respond to customer issues across platforms all right lastly pillar three is around tooling so Bots are totally okay to use but you still need humans to but by using Bots you're able to Outsource uh responding to repeat low skill low technical issues and then again free up your L1 human support Engineers time to focus on more complex issues chat Bots that we like at the graph include PLO uh formerly awesome QA as well as qara and cookbook. deev those are all great options next you need data and metrics for us we rely on astronaut to provide us with sentiment analysis and different pattern insights as well as ttfr response time metrics I'll talk more about astronaut in a moment you should also Implement a ticketing system or similar tooling on your website so even if you're providing support primarily in Discord or telegram asking a user to churn off of your website and and go find your Discord server to get support just creates more friction for them and so offering a ticketing system directly on the website will help your users get more timely support next you'll want to develop an observability strategy to level up your monitoring and alerting so this includes building out dashboards using tools like metabase or grafana to give your tech support team insight into the health and wellness of your protocol and any services that might be failing and then surfacing metrics using grafana um and then Victoria metrics or Prometheus metrics and then creating alerts um is helpful in ensuring you're triggering a page for your on call engineer to respond to critical issues within a certain threshold and lastly I mentioned on the last slide you need to bring support to where your users are and so if you're providing crossplatform support like the graph you'll need additional tooling and plays to help your team manage that complexity an example is if you have hundreds of telegram chats with users you can use a service like 3rm to send out Mass messages is across multiple telegram chats all right so we talked about some of our guidelines that we wanted to share with you so what are the results of all of these changes so if we flash back to 2022 the uh support response times for users of the graph uh was roughly 1 to 7 days which is actually pretty typical for web 3 protocols even today we started identifying and fixing many inefficiencies in our support model we expanded our L1 support team at Eden node where I work we clarified roles and responsibilities with our ecosystem supporters across the protocol we implemented improved tooling and we onboarded our secret weapon astronaut for providing crossplatform support analytics and when we look at our results today we are able to say with high confidence that the L1 support team's median time-to first response is 3 minutes so by implementing the guidelines we covered today we've brought down our support response times from up to 7 Days down to 3 minutes median ttfr have our customers noticed absolutely here's a quote from Fabian founder and CEO of snapshot Labs no matter the time zone or issue the graph support is always available slack telegram Discord ticketing every channel is optimized for Speed with real-time guidance from experts who actually build on the protocol our users have definitely noticed an improvement I mentioned astronauts so in addition to our L1 support team an incredible team of mission aligned Engineers astronaut has been the other key to success for us astronaut's a platform that enables Enterprise grade customer support across multiple chat platforms and it has been crucial in our ability to track our median response times to users and know where our bottlenecks are and improve them so here's how it works you can easily integrate astronaut with just a few clicks you integrate astronaut with uh different channels on slack telegram or Discord astronaut offers conversation intelligence which is a really cool feature and it automatically identifies and connects related messages across busy group chats it offers intelligent tagging it's automatically identifying bugs support requests and other product feedback and it's offering us deep insights and amazing analytics around the question volume we receive from users our response times across platforms performance metrics Broken Out by team member different days of the week or times of day um IT services outliers so if we miss our response Target and have an outlier where it took us a very long time to respond to a user issue astronaut easily surfaces that to us so we're able to identify where we still have bottlenecks and solve them and lastly it identifies recurring issues or themes reported by customers uh quote from Iola John the co-founder and CEO of astronaut also in the audience here today the graph has set a new standard for web 3 customer experience before astronaut tracking response times across hundreds of telegram conversations was a manual nightmare we built our platform to help teams like theirs deliver world-class support while preserving web 3's open culture and this summarizes our experience very well it was a nightmare trying to even understand what our basine ttfr was let alone know how to improve it all right so what's next this has very much been an iterative Journey for the graph protocol we have been able to deliver worldclass support by continuously adapting learning from our customers and innovating ways to apply some web 2 Technologies as well as web 3 specific improvements by addressing the unique challenges that a decentralized ecosystem faces while prioritizing the ux of support we have been able to deliver fast efficient and responsive support for our users getting down to a median 3 minute ttfr so as web 3 continues to grow we encourage teams to remember that people processes and tooling are the foundation for excellence in providing worldclass support for web 3 we'll continue to listen to and adapt based on user needs but we wanted to share these guidelines with you in the hopes that we can level up the web 3 support experience so if you'd like to get in touch connect with us by going to the gra.com you can access support from the website as I mentioned you can review our docs and other information you can follow graph protocol on X if you'd like to get in touch with me I'm happy to chat about support anytime you can uh hit me up on telegram at Mickey corenas or email me at Mickey eden.com I'll also hang out here on the site after after my talk ends if you'd like to chat in real time at the event but with that again I'm hoping these guidelines have been helpful to you take whatever resonates leave behind what doesn't resonate with you and let's improve the support ux across web 3 together thank you