Once you've setup your account on Makerkit you'll be able to effectively collect feedback from your users. This feedback might be the feature requests, ideas, or bugs that your users think is important to them.
Keeping everything in place place means it's more organised, and it's easier for you to draw insight from feedback collected from multiple users, across different channels.
Your users will be able to vote on feedback that is public. This is key feature of Makerkit. Each item of feedback that is submitted shows the number of times it has been voted on. This gives you a good idea of how much demand there is for a particular feature. In turn this score can be used to prioritise which feature your company should build.
You'll be able to keep users in the loop on how their feedback is being actioned by using the roadmap. Once your product team has decided to work on a submitted feature, they can change it's status. When the status of a feedback is changed, it'll automatically appear in the roadmap, and anyone who's voted for it will be notified.
This becomes a effective way to acknowledge that you take customer feedback seriously, and makes managing the expectations of thousands of your users easy.
Lastly, when you've deployed a new product update, you can write a changelog post. This is like a a blog post where you can go into depth about the product change, and why it improves your product.
Having this public journal of product updates tells your users that you are continuously improving your product.
Head over to our tour of the Makerkit interface. We think it's lovely. It'll show you how the feedback portal looks from a user's perspective.
At the moment, you can collect feedback through a feedback portal, or via the Intercom integration.
When you create your account, a feedback portal is setup for you automatically. You can however have more than one feedback portal.
We make it super easy to make your portal look like it's part of your website.
When a feedback portal is created, it'll be hosted on projectname.public.makerkit.co subdomain, but you can change it to something like feedback.myapp.com.
By default we allow your users to submit feedback. However you can turn off public feedback creation, and restrict feedback creation to just your team mates.
This works well if you want to control the items on your roadmap, but still allow your users to vote, or comment.
Every comment, and feedback that is submitted by your users must be approved by one of your team members, this is done from the inbox page.
When you receive feedback through another channel - in person, over the phone, via a messaging app, you need make a note of it somewhere. We allow you to add a vote on behalf of a new user, or an existing user. [See our guide on voting on behalf of a user]
The roadmap is a core part of how you can loop your users into how you conduct your product development. It also gives them a sense that their input has been useful in guiding your product development.
Our guide on the roadmap goes over how to move a piece of feedback into the roadmap.
When you roll out new product updates, you want want to make sure your users know about it. It's one of the best ways to show that your product is always being improved, whether it's a small UI tweak or a large feature!
Here's our guide on using the changelog. It covers creating new posts, hosting the changelog on it's own domain, scheduling posts in the future and other things
If you need to allow other members of your team access to your account, you can invite them to your organisation within Makerkit. They'll be able to perform administrative duties.
We go over some of the things you should do to make your users more likely to interact with your feedback portal and provide feedback. Ultimately we want to make your users more engaged.
If you've got user accounts for your app, one of things that we recommend doing is to implemented SSO. This automatically logs your users into Makerkit, without them having to sign up again.
Our paid plan is based on "active users", here's a good overview of how we define an active user