Decentralize the Help Desk: Redefining Web3 Support
Let's be honest—Web2 support just doesn't cut it in a web3 world. When you're supporting a decentralized protocol, having users wait on hold or bounce between support tiers feels about as outdated as dial-up internet.
The problem isn't just about slow response times or canned replies–it's about trying to force old-school, centralized support methods into a space built on decentralization and 24/7 global operations.
For web3 to reach its full potential, we need to completely rethink how we support users, creating systems that are as open, responsive, and empowering as the technology we build. So, how do decentralized systems handle the help desk? The Graph, a decentralized ecosystem, is going beyond simply maintaining the status quo–it’s delivering best-in-class customer support to its users.
“No matter the time zone or issue, The Graph’s 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.” - , founder and CEO, Snapshot Labs
Why Traditional Web2 Support Fails Web3 Protocols
To fully appreciate how The Graph’s teams consistently surpass expectations in web3, it’s important to understand that the traditional Web2 support model is limiting.
The Web2 support model is designed for centralized systems and walled gardens and not the open landscape of web3. In Web2, customer support is built on centralized processes: ticketing systems, call centers, and scripts or canned responses–all of which are controlled by a single corporation.
These systems can be effective in some cases but ultimately funnel users into predefined solutions, escalating issues through hierarchical layers that become increasingly more technical as a user climbs the support hierarchy. While this works for centralized Web2 organizations, it’s completely out of sync with how decentralized protocols function and interact with users.
In a centralized support model, the speed of response and quality of service are constrained by the technical skill level of support engineers and their company’s business hours.
When demand spikes, especially in time zones far from a company’s operating hours, users experience long wait times and receive canned responses from bots without giving users a way to reach a human support engineer. This bottlenecked approach can’t keep pace with the needs of a distributed user base because, in short, web3 never sleeps.
Web3 protocols require a fresh solution to support, one that is decentralized, responsive, and truly reflects the core values of web3.
The Graph’s Solution: A Decentralized Support Playbook
Unlike Web2, web3 support faces the challenge of navigating the distributed nature of decentralized protocols.
Web3 ecosystems have to manage a patchwork of support platforms that vary widely in reliability and effectiveness. They rely heavily on third party contributors or protocol developers to provide ad hoc support out of goodwill and in their spare time. Perhaps even more daunting, web3 protocols are highly technical and require a deep understanding of blockchains or other technologies to resolve user issues. The learning curve is often steep.
Despite these challenges, The Graph has successfully set a gold standard of decentralized support in web3. Instead of keeping its lessons learned about technical support coordination internal, The Graph community wants to share its support methodology so that others can level up the support UX across all of web3.
The Graph’s goal is simple: to keep users at the center while ensuring that the support delivered is as sharp and performant as the technology being built.
The Graph’s Three Pillars for Optimal Support
The Graph delivers exceptional support by centering the ecosystem's philosophy around three pillars: people, processes, and tooling. There is no universal system that will work for all protocols. The rules below serve as educational guidelines, and we encourage other decentralized protocols to choose the items that resonate with them when building out their own support systems.
Pillar 1: People
Rule 1. L1 support engineers ARE technical. Upskill your L1 support engineers to reduce the number of support layers users need to move through to receive help. This takes pressure off your L2/L3 engineers by giving them fewer disruptions or on-call pages. Equip your L1 with runbooks and make sure they’re empowered to page other support layer personnel at the company or across the protocol as needed. Your L1 teams shouldn’t be merely copy-pasting messages into triage channels, but rather actively resolving technical issues.
Rule 2. Build a “follow the sun” distributed team. Hire people in multiple time zones in a “follow the sun” model to ensure web3 users across the world always have a support engineer online. This unlocks 24/7/365 support for your protocol’s users regardless of time zone. Set up an L1 and L2 (and sometimes L3) on-call rotation for the specific needs of your protocol.
Rule 3. No scripts or canned responses. Ever. Support engineers should write unique, tailored messages to users that ensure their needs are met. These messages should give users confidence that the L1 engineer has prioritized resolving their unique issue. If needed, provide writing training for your engineers.
Rule 4. Establish and reinforce a culture of extreme ownership. Give your L1 engineers guidance and unblock them as needed. However, emphasize that they alone are responsible for resolving a user’s issue until they either fix it, hand it off to another support engineer, or escalate it to L2 or L3 teams. The problem is theirs to own until resolution or handoff.
Rule 5. Prepare the tech support team for hackathons. Hackathon devs get frustrated when they face issues or outages with your protocol that impact their ability to pursue your bounty successfully. Your tech support team should be prepared to provide remote, async, or (if you have budget) on-site support during hackathons.
Pillar 2: Processes
Rule 6. Set a competitive time-to-first-response (TTFR) Service Level Agreement (SLA). You should communicate your first response SLAs to all engineers providing response and support. These targets should be competitive and realistic to make sure you set the team up for success. Do not make time-to-resolution (TTR) guarantees because resolution is unpredictable and based on numerous factors out of your control (e.g., disruption with an RPC provider, cloud provider, etc.).
Rule 7. Know the services that impact your Quality of Service (QoS) or SLAs. Your team should identify and understand upstream components, software, and services that may impact any QoS or reliability SLAs you offer. Any customer-facing guarantees you make should be backed by upstream services with SLAs that equal or exceed your own.
Rule 8. Enable different contributors in the decentralized ecosystem to own parts of the support model. Work with contributors to design a support workflow (define where users report issues, who is responsible for responding, etc.), and make sure duties are well understood across each faction.
Rule 9. Write root cause analyses (RCAs) and postmortems. Drive down the number of repeat issues by solving them at the root. Conducting RCAs and postmortems ensures dev and infra teams are allocating time to permanently resolve these issues. Don’t leave your users hanging–set a reminder to circle back with them when systemic solutions are implemented.
Rule 10. Bring support to where your users are. Don’t force unnecessary changes to user behavior. Given the complex nature of providing support across multiple channels (Slack, TG, Discord), enabling users to communicate through their preferred channel will improve the support UX.
Pillar 3: Tooling
Rule 11. Bots are okay sometimes. But you need humans, too. Use bots to handle the repeat, low-skill, low-effort questions and free up response engineers for the more complex issues. Examples of chatbots include Pluno, Katara, Peeranha, and Cookbook.dev. Ensure the chatbot learns from “trusted sources” and has a reinforcement mechanism or confidence threshold. If you are in need of a Discord bot as well as a website chatbot, source a provider who does both trained on the same sources.
Rule 12. Get data and metrics. Use tools like Astronaut to gather support performance data and measure the success of your support team. Also using a tool like Astronaut gives you a sentiment analysis service to gauge user perceptions of support quality and identify recurring themes for your product and dev teams. Additionally, continuously update docs based on feedback from “the field”.
Rule 13. Implement a ticketing system on your protocol’s website. A ticketing system is effective for non-urgent issues and questions raised by non-technical and technical supporters of your protocol. Make sure you also link to all support-related resources and platforms from the same spot.
Rule 14. Develop an observability strategy to level up your monitoring and alerting. An observability strategy should seek to provide your L1 team with dashboards to understand performance issues that are affecting users. Instrument and surface metrics (Victoria Metrics, Prometheus Metrics, etc.), develop dashboards (Grafana, Metabase, etc.), and set up automated alerts (Grafana and Opsgenie or PagerDuty, etc.). Automated alerting reduces repeat manual tasks and toil and also aids in improving TTFR metrics.
Rule 15. Offer multiple ways for users to receive support. Create and publicize a public system health or alerting page such as Statuspage from Atlassian. Ensure your support team is in all platforms or chats where users expect to receive support from your protocol: Discord, Telegram, Slack, and a ticketing system (e.g., Zendesk) via a support CTA on your website. If you intend to send out mass support messages or other notifications to a large volume of unique Telegram chats, rely on a service such as 3RM to reduce manual toil.
By focusing on the people, processes, and tooling that empower support teams, decentralized protocols can provide more effective solutions and reduce the challenges faced by users. The Graph’s support team is constantly iterating and adapting new ways to meet web3 users’ needs.
The Graph Slashes Support Time to 3 Minutes, Powered by Astronaut
Two years ago, users of The Graph waited up to a week for support. Today, users get answers in just 3 minutes, setting a new industry standard for customer support in web3.
Like many web3 protocols, The Graph's support is split across Discord, Telegram, and Slack. With questions scattered across platforms, the support team couldn't even measure response times, let alone improve them. This led to long delays and missed opportunities to help builders when they needed it most.
Edge & Node, The Graph's core developer, transformed delivery of support with four key strategies:
- Expanding L1 support team
- Establishing clear roles for ecosystem partners
- Automating common questions via a Discord bot
- Using Astronaut to track support response times in real-time
The results were dramatic. The support team’s median response time dropped from 1 - 7 days to just 3 minutes. With real-time visibility across platforms, the team could finally spot and fix support bottlenecks as they happened.
This transformation is in large part thanks to the mission-aligned, dedicated team of tech support engineers and Astronaut's unified platform for tracking support across Discord, Telegram, and Slack.
Why does this matter? Ayoola John, Cofounder and CEO of Astronaut, explains: "The Graph has set a new standard for web3 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 web3’s open culture."
This transformation proves that exceptional customer support is possible in web3. By combining dedicated support teams with tools like , The Graph shows that decentralized protocols can and should deliver the seamless experience users expect.
What's Next: How to Reach Out and Get Support
The journey to deliver top-tier web3 support has been marked by continuous learning, adaptation, and innovation. By tackling the unique challenges of decentralized ecosystems while prioritizing user experience, The Graph successfully delivered fast, efficient, and responsive support.
As web3 continues to grow, teams should remember that people, processes, and tooling are the foundation for excellence.
The Graph will continue to listen, evolve, and respond to user needs in an ever-changing landscape. Want to experience industry-leading support firsthand?
Simply log into your or account and connect with our skilled Support team by clicking the Support button. This handy feature allows you to engage our Discord community and or gives you the option to submit a help ticket. For general information, channel is a great resource.
If you have a specific question that is either non-technical or technical, support is just a message away on . Additionally, high-volume users and chain partners can enjoy dedicated support contacts in Telegram chats or Slack channels. To learn more about this option, reach out to us via or any platform linked above.
The ecosystem is here to empower you at every turn. For any additional support or to chat about decentralized support for web3, contact Mickey directly on Telegram (@mickey_negus), , , or .
Web3’s strength lies in the community driving its process. Let’s keep innovating and advancing web3 together–The Graph is here to support you in this journey.
About The Graph
is the source of data and information for the decentralized internet. As the original decentralized data marketplace that introduced and standardized subgraphs, The Graph has become web3’s method of indexing and accessing blockchain data. Since its launch in 2018, tens of thousands of developers have for dapps across 90+ blockchains - including Ethereum, Solana, Arbitrum, Optimism, Base, Polygon, Celo, Fantom, Gnosis, and Avalanche.
Discover more about how The Graph is shaping the future of decentralized physical infrastructure networks (DePIN) and stay connected with the community. Follow The Graph on , , , , , and . Join the community on The Graph’s , join technical discussions on The Graph’s .
oversees The Graph Network. The Graph Foundation is overseen by the . , , , , , and are seven of the many organizations within The Graph ecosystem.
