I updated the ticket with a mockup of where the feedback widget is in the site footer, and the contact page design has been updated to reflect how we would like to receive feedback. Ideally, this page would be the same for all users.
From my point of view, we should have the following boards public:
💡Feature Request
📥 Feedback
🐛 Bug Report
🤔 Questions (New board I think we should make)
Boards with limited permission:
🗒️ Testing Feedback
🛠️ Maintenance
sshkolnikov
•
Aug 7, 2024
Good morning team,
We are aligned with this plan. We will pull together a training guide for CEDARS users on these boards. I know we demo’d this approach previously, but it’s been a hot minute since we did. Thoughts on either demo’ing this tomorrow at our established time or next Thursday, closer to release?
sshkolnikov
•
Jul 18, 2024
Additional questions: Under Roadmap tabs - what will be visible and what will not be visible to the user and the process for which this is managed and governed?
cedars team
Team•
Jul 17, 2024
This piece can be managed using Featurebase. Users must be authenticated before viewing and posting feedback and the roadmap.
Questions we have: Did we want an alternative path for “public” unauthenticated users? Should users have auto login with their CEDARS credentials? Do we want a button in the footer that links to Featurebase modules (Changelog, Feedback and Roadmap?
sshkolnikov
•
Jun 6, 2024
Hi Jenn, this is awesome! During the review of the intake form, Amy and the IOU's asked us to also capture a request for User Support that is similar or the same as the "Get in touch with Support". We incorporated this request into the form as well and I've set an automation within Monday to email you, me and Alison when a request comes in.
The advantage for sending the user to the form to "Get in touch with Support" is we can track and analyze the requests for human support, which groups or folks are reaching out the most and analyze the amount of time spent providing human support so that we can then make suggestions for training, plan sprints to allow for a certain amount of capacity for user support based upon previous findings etc.
So my suggestion is to eliminate the "Get in touch with Support" and the email completely OR keep both for the time being and if we receive an email communication...we can send the user to the form.
If we chose to keep them both - the email and the form, then we could plan for a transition away from one or the other depending upon how users respond.
Log in to comment and vote
Comments5
cedars team
Aug 7, 2024
Hey team,
I updated the ticket with a mockup of where the feedback widget is in the site footer, and the contact page design has been updated to reflect how we would like to receive feedback. Ideally, this page would be the same for all users.
From my point of view, we should have the following boards public:
💡Feature Request
📥 Feedback
🐛 Bug Report
🤔 Questions (New board I think we should make)
Boards with limited permission:
🗒️ Testing Feedback
🛠️ Maintenance
sshkolnikov
Aug 7, 2024
Good morning team,
We are aligned with this plan. We will pull together a training guide for CEDARS users on these boards.
I know we demo’d this approach previously, but it’s been a hot minute since we did. Thoughts on either demo’ing this tomorrow at our established time or next Thursday, closer to release?
sshkolnikov
Jul 18, 2024
Additional questions:
Under Roadmap tabs - what will be visible and what will not be visible to the user and the process for which this is managed and governed?
cedars team
Jul 17, 2024
This piece can be managed using Featurebase.
Users must be authenticated before viewing and posting feedback and the roadmap.
Questions we have:
Did we want an alternative path for “public” unauthenticated users?
Should users have auto login with their CEDARS credentials?
Do we want a button in the footer that links to Featurebase modules (Changelog, Feedback and Roadmap?
sshkolnikov
Jun 6, 2024
Hi Jenn, this is awesome!
During the review of the intake form, Amy and the IOU's asked us to also capture a request for User Support that is similar or the same as the "Get in touch with Support".
We incorporated this request into the form as well and I've set an automation within Monday to email you, me and Alison when a request comes in.
The advantage for sending the user to the form to "Get in touch with Support" is we can track and analyze the requests for human support, which groups or folks are reaching out the most and analyze the amount of time spent providing human support so that we can then make suggestions for training, plan sprints to allow for a certain amount of capacity for user support based upon previous findings etc.
So my suggestion is to eliminate the "Get in touch with Support" and the email completely OR keep both for the time being and if we receive an email communication...we can send the user to the form.
If we chose to keep them both - the email and the form, then we could plan for a transition away from one or the other depending upon how users respond.
Thoughts?