Feature Requests

## Feature Overview Allow users to change the widget button icon. Current mobile "pencil" icon can be swapped for other icons or a custom image. ## Use Case Some users find the pencil icon confusing and don’t recognize it as a feedback button. Letting people choose their own icon would make the button clearer for their audience.

Feature Overview Add targeting settings directly in the Marker.io app for the reporting widget. Options could include: - Show only on desktop, tablet, or mobile. - Hide on specific URL patterns or page types (e.g., checkout or confirmation pages). Use Case Right now, you can control this behavior with custom JavaScript (e.g., if screen size > x, show marker.io ), but this requires coding. Having these options built into the app would make it easy for non-technical users to control where and when the widget appears. This would help teams avoid showing the reporting button where it might distract users or isn’t needed, like on sensitive or transactional pages.

Always monitor your website to surface issues before your customer do. A few use cases: When critical issues occur on the website (like broken cart), I want automatic detection and flagging so that we know before customers report it. When website performance degrades or errors occur, I want proactive issue creation so that customer service doesn't waste time reporting known problems. When monitoring website health, I want automatic issue detection so that we catch problems before they impact customers.

Allow users to customize the label of a field on the Marker.io widget independently from the field name in the connected tool (e.g., ClickUp, Azure DevOps). Feature Overview Customizable Field Labels : Provide the option to rename the label of a field displayed on the widget without changing the actual field name in the integrated tool. Tool-Specific Flexibility : Ensure this customization works for all integrations, including but not limited to ClickUp and Azure DevOps. Use Case In ClickUp, users might have a field named "Submitted by" but prefer the widget to display this as "Your email" for clarity to external submitters. For Azure DevOps, users may want to rename "Repro Steps" to "Description" on the widget to better align with their workflow or make it more intuitive for their team. Benefits Makes the widget easier to use and understand for external contributors or team members unfamiliar with the field names in the connected tool. Provides greater flexibility to adapt Marker.io to match the specific language and needs of different teams or use cases. Reduces confusion by letting users tailor the experience to their audience, improving overall usability.

Speech-to-text integration to dictate the description would be amazing.

Right now, some users need to log into Marker.io to see the widget on a website. We want to remove this requirement and let teams decide exactly who gets access. How It Could Work Teams could choose who sees the widget, without requiring a Marker.io login. Options might include: Everyone Only internal team members Only logged-in users on the website Only people with a special invite link Only visitors from a specific country or region Only on certain pages etc

The ability to set a predefined "Title" and hide this from the form so that each title would for example have the naming convention of "<ticket-number--word-or-phrase>". By allowing for this, those providing feedback can focus on providing a full description without having to summarise the whole feedback request.

Ability to see past feedback directly in widget. This will help avoid duplicates and would create this feeling of "drop a pin comments" feedback on the site

Build a Mobile SDK that allows Marker.io to be embedded inside native mobile apps. Support for frameworks like React Native, Flutter, Capacitor, Ionic, and Angular. Allow teams to collect in-app feedback and bug reports directly from iOS and Android apps.

Feature Overview Allow users to change the text on the submit form button. Right now, it shows default text like “Submit Issue” or “Send Work Item.” We’d like to let you choose your own wording—like “Send Feedback” or something that fits your tone better. ## Use Case Different teams and use cases might need different button text. For example, a design team might prefer “Send Feedback,” while a dev team might want “Log Bug.” Being able to customize the button helps the form feel more personal and clear to your users.