With the most recent Osmosis Support Lab / Interchain Support Group gov prop failing onchain, I think it’s worth revisiting the entire Osmosis Support Ecosystem as a whole from a zoomed out perspective (not just wrt to the OSL/ISG coverage)
The goal of this post is simple > engage the Community, the OSL/ISG, OGP, and dev team to discuss the larger Osmosis Support Ecosystem (Both Dev and User facing)
- What is existing that needs improvement in either quality or efficiency, while also touching on what is ‘perfect’ and doesn’t need change.
- What is missing and needs to be created / implemented
All ideas should be left in the comments/reply section, leaving the high level post neutral.
Over the last 3 years, the support ecosystem (User & Dev facing) hasn’t had a focused discussion to zoom out and analyze everything full scope, actually this has never really happened. Hoping this can take place here!
A discussion like this would likely take 2-4 weeks to fully explore and likely 1-2 months to implement, which raises a pretty obvious question “what happens in the meantime with OSL support?”
- To address that, I think it’d be logical for OSL & OGP to discuss a shorter term 3 month funding at the rate the OSL has requested in this post Osmosis Support Lab Funding Round March 2025-2026 [Revised]
- This would be $69,000 roughly for 3 months and cover the time frame of exploration/solutions implementations with some time to spare.
- Given that the [Revised] proposal above is still not super clear in detail with the tradeoffs, I think the OGP <> OSL/ISG should iron out those tradeoffs.
- Robo on the OGP, having spent significant time on the OSL and being a ‘lead’ on it in the past should be pretty well equipped to dive into this with the OSL.
The short term funding would give the Ecosystem Support discussion breathing room, this isn’t something that should be time crunched into a few days and end with the weight of a year long funding proposal, while also potentially removing the ability to optimize and remove/add-in operations.
User Facing Support Discussions & Ideas
OGP & OSL should work out a short term 3 month bridge period
- more discussions can take place before locking in a larger & longer term operation.
Polaris Support Overlap
- eventually Polaris Support will exist (and how it exists, I’m not yet sure, that will largely be up to the Product team to implement) with that said, it doesn’t make sense to waste / duplicate efforts so the 3 month OGP<>OSL suggestion should give time to ensure implementations can be mutually used (if that direction ends up being logical)
Squid Support & Osmosis Support.
- The OSL/ISG also is paid by Squid to offer support services, it would be great if Squid & OSL/ISG could share the scope of work / compensation. There’s likely some overlap in actual work (as many Squid users would be using it for Osmosis) and definitely some overlap in useful support content or systems (ie, squid and Osmosis could co-fund a system that helps users navigate).
Governance route for Support funding
- This has never been ideal, this is a clear lesson over the last 3 years and with the most recent prop failing. It makes more sense for things to be flexible in an actively adaptable state and not annually. With the above proposed OGP<>OSL idea, it makes more sense to have OGP provide support funding and the OGP/OSL can actively work on new implementations together and the OGP can sign off on additional funding for those new endeavors (if any)
24/7 100% support, vs 24/7 availability
- This should be explored, as having active live 24/7 100% support is not efficient with the average 1 ticket being every 2 hours, resulting in $110 per ticket on average. That number should go down, response times do not need to be in seconds for all tickets, while hopefully still being able to address urgent matters in a timely manner.
- A 24/7 availability system would address the price inefficiency while still ensuring 24/7 support for urgent items (with a funnel allowing users to submit an ‘urgent’ request) , still paid but at a reduced rate, still 24/7 but not chair locked staring at a screen. This seems mutually beneficial as support providers also get more lifestyle freedom here, while being ‘on-call’ for urgent tickets. Of course there could be some flaws to this idea, such as users simply abusing the ‘urgent’ request service with non-urgent items. A new system like this would take some time to implement and get ‘right’, it’d be a useful to tinker on.
- Live hours could be dropped to the most active hours in 3 regions, Americas:Europe:Asia with a 6:3:3 hour ratio (or whatever is found to be ideal)
Support Content & Funneling
- I shared in another post how BestBuy does this, I encourage anyone to just go to bestbuy.com and click their support widget system. It’s pretty useful.
- The TLDR is, chats (Telegram, Email, Support Box) would present most common ticket requests and help the user triage their own issues while allowing the user to get hands on support if needed.
- If tickets take place during live hours, OSL/ISG members would still be able to view these tickets live, but not necessarily have to reply while the prompts help guide the user. A live agent could jump in at any time, as the prompts might not be perfect and would need tinkering over time.
Support Channels & Scam/Spam prevention
- The existing large Telegram chat with 11,000 members in it should NOT be used as the primary support channel. This needs to be deprecated as a support channel (not deleted, as community can still chat there)
- All support tickets should via closed communications, such as 1:1 Telegram dms, emails, or support box.
- The open channels are heavily prone to scammers (like all open channels), and given the spam this is also not a great UX for users either.
Dev Facing Support Discussions & Ideas
- Currently there exists an Osmosis Technical Community TG chat that is largely supported by MaxPower that is on the OSL/ISG. If it is largely supported by 1 person on the OSL, this shouldn’t be tied to the OSL. The work there should be itemized and compensated separately, whether that be by Governance, the OGP, or the Dev team.
- Osmosis Tech Community TG Chat, one way to improve this would be similar to the reply/prompts that I’ve suggested Osmosis User Support implement. A system of guides/responses that help guide a user/developer to the right answers.
On the OGP side, we’d be happy to own funding the ISG to provide ongoing support (subject to the review committee’s approval). I see what the ISG/OSL is doing as pretty essential to the user experience on Osmosis and is an area where Osmosis has consistently seen incredibly positive feedback, both from average retail users and from large (8-9 figure nw) users of the platform.
Re: a bridge period, I’d personally prefer the bridge funding to come from Osmosis governance under the terms outlined in the ISG’s latest proposal. This’ll give OGP and ISG enough time to figure out a commercial agreement that works for everyone without needing to worry about rushing a grant out the door to ensure support services are maintained in the short term.
But if governance would prefer not to go that route we can discuss a shorter (1-3 month) bridge grant while we work out the details of a longer-term grant.
2 Likes
I agree with @RoboMcGobo that the bridging period should come from the governance route. I also would say that we should agree on a slightly to long period (for example 4 months), to ensure we don’t need to go through governance again if we run short of time on this subject.
I can also trust the OSL to refund what is not used. We have seen that they operate fully on the plus side of Osmosis, so I am not afraid that they will run with the money.
Regarding the technical support mentioned by @aaronxkong; also agreed on that one. If @maxpower is virtually the liason, then that position should be exempted from the OSL and be created as a separate role if the need stays.
Regarding the main Telegram channel; how is moderation expected if we are aware that users will most likely see that as a main channel for a question? We should first and foremost make the preferred routes so obvious to make sure users don’t even think about going to Telegram for a support question. But it will still need moderation to remove spam and scam.
Another proper question is where we will expect the majority of questions later on when Polaris is live. Will the majority of users who need support use Polaris or will they still bother with a browser-based experience? That will also determine the need of support.
I think it is also a good idea to think about what we have vs what we need. In that sense I would like a competitor / market analysis, but that should not be the limit of our ideas. In the end it also matters what we want to be. If that is more than what the market currently offers, then we should still chase that dream. I would hate to be the mediocre project while we have the tools to be better.
1 Like
Yeah the tech chat is technically a separate item. I have not actively done hourly support shifts for quite some time now, but I still take $1k per month.
This is for covering this group as well as any other requests which the team will either forward to me or just ask my advice about. It also covers just general duties involved with running the org.
Admittedly it is not a lot, considering that second bit. Several others covered the majority of internal / administrative duties anyway as they were designated that responsibility.