HN user
100%, at much lower cost and accessible by SMBs on top of that. You can typically retrieve any data from your Intercom tickets, CRMs, Slack conversations, websites and documentation tools. We'll be also adding meeting transcripts but for now our customers build a custom sources and index these with our API.
Building back office tools is such a nightmare... Classic thing I had to build over and over when I freelanced, this would have helped a lot.
We've been using Forest for... 5 years? for our team, you created something special!
You take Notion as an example and I couldn't agree more.
We are their competitor and followed your exact line of thought trying and not releasing GPT in editor to avoid noise, and building ASK, an engine powered by semantic search, GPT (and a lot of other fun models for refinements), to answer all questions you could have on your knowledge base.
It's private, fast, works with real time edited documents, and it's already in production for thousands.
Check it out: slite.com/ask
We tackle this hard with slite.com, we just introduced slite.com/ask to find answer no matter how badly organised your documents are, and we offer document status to track outdated and up to date docs across your space (and we're still enhancing it, very much first version).
These among many others to help it not become a behemoth as you say.
We built the technology in house and don’t rely on chatgpt, but GPT alone, and services offer it in a similar way algolia or elastic offer search for instance, it keeps data private.
We just released a new feature for Slite, Ask, in private beta.
Slite is a team workspace that hosts all kinds of knowledge: wiki, docs, projects, discussions, and decisions. When we started playing with ChatGPT, we really wanted to offer a similar experience, by basing answers on your team documents.
It felt like a parallel change of paradigm: ChatGPT to get answers from the web, Ask to get answers from your internal knowledge.
The technology under the hood is of course different: It uses GPT3 and advanced semantic search, with special ponderation based on your team activity, document linkage and so on. And of course it respects privacy - its answers are only based on what you can access.
The interface is less conversational - for now. But it's already a massive upgrade from your classic search experience, and it goes beyond that. You can really ask it anything, even stuff that's not specifically documented. The engine will look at various sources and compile them to answer.
First testers love it, and we believe it can radically change the way we work with documentation in the future. Check it out!
We just released a new feature for Slite, Ask, in private beta.
Slite is a team workspace that hosts all kinds of knowledge: wiki, docs, projects, discussions, and decisions. When we started playing with ChatGPT, we really wanted to offer a similar experience, by basing answers on your team documents.
It felt like a parallel change of paradigm: ChatGPT to get answers from the web, Ask to get answers from your internal knowledge.
The technology under the hood is of course different: It uses GPT3 and advanced semantic search, with special ponderation based on your team activity, document linkage and so on. And of course it respects privacy - its answers are only based on what you can access.
The interface is less conversational - for now. But it's already a massive upgrade from your classic search experience, and it goes beyond that. You can really ask it anything, even stuff that's not specifically documented. The engine will look at various sources and compile them to answer.
First testers love it, and we believe it can radically change the way we work with documentation in the future. Check it out!
Slite
Super clear and useful!
The performance definitely is something we improved a lot, and indeed relational data - I guess you mean roll ups in database- is not something we allow at the moment, thanks for sharing again!
Thanks for sharing! What was inferior about Slite (and when did you use it)?
I’m working on it, would love to hear your takes, especially as in term of performance and speed we worked heavily this year and believe to have reached something superior to alternatives.
If you like performance and have a team usage, Slite should be an interesting choice to explore.
Disclaimer I'm the founder, hundreds of team come from notion every month for this reason. Our search is much more powerful and lightning fast, navigation and doc loading is super fast as well, we put extra care there.
Absolutely, we onboarded multiple junior folks over the year, but always put special care there, it needs a very different approach to any new remote teammate.
Founder of Slite here, your reply is spot on, we try to be as honest on the pros and cons of remote when we think internally of the future of this market, and when we share our research or insights outside.
It's not all pink, and our mission is very much to remove the roadblocks, so we need to acknowledge the issues that prevent remote from being seen as a no brainer by some teams today.
Slite.com (YCW18) serves exactly this purpose. Full disclaimer it's my company, but this is the core issue we are tackling.
2 classic pitfalls with knowledge are - what do you put in this word (for instance are meeting minutes "knowledge"?) - how static you think it should be
If you only envision knowledge as static processes, traditional wikis work. If you want all your team to contribute and for this knowledge base to be a daily used tool, with all the information that matter you need another setup and we are building Slite for this (happy to have feedback!).
Well the 'team' is actually defined in Slite, while google docs, paper or notion have rights granted on each folder / page / doc for a loose set of people.
The easy way to see that is by checking a Google Drive structure : you have "My Drive", then some folders, some shared, some not, and in parallel "Shared with me" gathering documents that can come from outside your team, and that you can also put in "my drive"... It's centered around individuals and weirdly works for them, but is absolutely not suited to organize and retrieve content as a team.
Slite actually creates a well defined private space for your team, which makes it possible to share by default. When I update our roadmap or our hiring process, I know all the relevant people can see the channel highlighted, and can get updated. In another tool, the authors would have to push a link by email or irc to get their team updated. And this mereley because they knew that else nobody would see it had changed and nobody could retrieve it in a shared folder structure.
Completely side but awesome job on Slate! We have spent a lot of time working on editors, and might switch to it at some point, so keep up the good work!
Hey!
We clearly have a lot in common with Quip. The main difference as of now is organization : Quip is organized exactly like a google Drive, with nested folders while Slite uses channels. It makes the content accessible, permissions easy to manage and actually shows your team important changes of the content.
The other thing really different that we're building is integrations: Quip focuses on in-editor integrations (which are great, we're working on those as well). But for the rest, unlike quip we keep a simple markdown-compliant (& thus universal) format, which let us fetch and push content to all your toolchain.
We have not pushed that on the homepage yet, but there will be a strong discount for NGOs and academic institutions actually!
Thanks ;) We're especially inspired by airtable & their "Universe" page
Hey there, totally legitimate concern, I'll just say without spoiling that we're really here for the long run ;)
This import is there to let you invite your team more easily after signup. You can absolutely login with email password if you want to avoid that but do note that it's just an helper, the app won't send emails by its own.
Thanks for the feedback !
For the differenciation with Slack, the similarity really stops with the channels pattern. Using Slite allows you to separate use cases: Slack or equivalent to communicate instantly, Slite to write and retrieve information.
As a back story, Slack did try something similar a few years back: they built Slack posts with a similar vision in mind. But having those burried in threads and writing in a constantly ringing place defeated their purpose. From talking to our users, it seems like really few people use posts as they were intended in the first place. At the end of the day, having to organize your content and handling collaborative edition is a job for a standalone product
For the wording indeed, a teammate just mentionned the same thing on "public" wording, we'll think of a better term, "team-wide" maybe.
As for the templating option it's clearly something we're thinking about, the challenge is to make the feature simple enough.
Sure, this is something a bit special : we clearly have an easy way to get into new companies, there is no friction on getting on Slite for them.
The thing is we solve way more issues for teams between 20-200 people, as they are the one struggling with process and knowledge sharing. The strategy we have to convince them is by integrating in their workflow : if Slite can solve their issues while requiring a low-cost setup by integrating in their toolchain, we think it can prove value quickly enough for those teams to adopt it. And clearly Skype or Office will be at some point included in those integrations.
As for the Exchange servers to be honest I have no idea and it will highly depend on our users' demand.
Super sorry for the experience this has been now fixed (it's actually a relicate, the issue can't happen on new teams)
Thanks for the feedback, that's one of the feature that is delicate to create in app without bringing too much complexity, but it's definitely the goal at some point, and our current templates are a poc of it.
I know a couple of apps that could have that for strategy so I completely understand the question ;)
We have absolutely no plan on doing that, even for anonymized data. The only use of this data is for the application's purposes and to be honest if we could bring the same value with End to end encryption, we would do it.
The reason for not doing it is simple : we have a much simpler business model, Slite actually provides way enough value for active teams to start paying and that's enough to focus on ;)
It's fixed, again sorry about that!
Short answer : absolutely not, you can have a look at our privacy policy here : https://slite.com/privacy.
On the why investors would fund us, I think the "note" aspect of it is misleading: it's simply giving an ease of use to our users, but the core of slite is the team aspect of it, and our will is to solve knowledge sharing in teams. While this is not solved, clearly investors will fund projects like Slite.
That's a super interesting point and I fully agree those examples are not well suited for all teams, especially not for larger ones.
I still think having all the information compartmentalized is a waste of time. The integrations that we are developing aim at solving this : Slite will integrate with your github documentation and your Greenhouse pipe so that the members that need the information but don't use the tool everyday (typical in an hiring process) can see the information while those whom it's the job will keep using it as usual.
Unfortunately not for now, while we clearly understand the need we can't afford that for now.