クリエイティブな才能を開花させよう

I’m submitting this as an accessibility issue, not a cosmetic preference. Recent UI changes in the internal agent web interface (Tickets / Help Desk / Conversations) introduced blue/teal text on a white background. This creates a health-related accessibility barrier, as it triggers migraines and significant eye strain and affects my ability to work safely for extended periods. Important context: System-level blue-light filters (e.g., Night Shift / Night Light) do not help and actually worsen eye strain by reducing clarity and increasing visual fatigue. The only effective solution for my light sensitivity and migraines is a true dark interface (black or near-black background with light text), which I use successfully across other tools. Text color itself is a major trigger — certain hues (including blue/teal on white) significantly increase eye strain. Mobile app dark mode is not a viable workaround due to high ticket volume and the need for full web-based workflows. Currently, the internal agent web UI does not offer: A dark mode or high-contrast theme User control over background color User control over text/letter color The ability to adjust contrast in a way that accommodates light sensitivity and migraine triggers This creates an accessibility barrier for agents with light sensitivity, migraines, and visual processing conditions. While contrast ratios may technically meet minimum guidelines, accessibility also includes user-adjustable presentation, especially when specific color combinations cause adverse physical effects. Request: Please add one or more of the following for the internal agent web interface (Tickets / Help Desk / Conversations): A true dark mode A high-contrast or low-glare theme User-controlled theming, including the ability to adjust: Background color Text/letter color Overall contrast Providing control over both background and text colors would allow agents with different accessibility needs to configure a workspace that does not cause physical harm or limit their ability to work. This would align HubSpot with modern accessibility practices and with other enterprise tools that support agents with light sensitivity and migraine-related accessibility needs. Thank you for considering this from an accessibility and health-impact perspective. ...その他を表示

Currently there is no way to make so that users opening tickets with you, find the answer to the tickets only in the Customer Portal. (below also the confirmation from HS support AI).  It would be very useful to have a way (channel?) that is only visible within the Customer Portal. This would mean that Customer X creates a ticket (inside the Customer Portal or via email). The answer that we create will be visible in the Customer Portal and the customer will only receive a notification of an update/answer to the ticket, available in the customer portal. This would create a reason for Customers to use the portal. It would create a reason for us users of Lumion to set the portal and promote it.  At current phase, other than reviewing ticket history, there is no real strong point for a customer to visit the Customer Portal vs using their email inbox.      ...その他を表示

I would like to see Hubspot bring back the ability to have a different  value for "Due in" between 1st Response and Time to Close SLAs.   Problem: 1st Response and Time to Close are fundementally different time scales.  1st Response is supposed to be quick.  Time to Close is a much lonwer time scale (from 5x to 15x typically).  But hubspot only offers a single "Due in" for both:   Because of this: 1. I need to cater the Due in to the 1st reseponse (I am not allowed to make it large enough to be reasonable for my Time to Close SLA) 2. I need to jump thru hops to create a workflow trigger 3. I have to compromise the time before notification.  Either resolution of 1 day (too long in some cases) or use the Due in (too short) 4. If I use the Due in, then I can't distinguish 1st Response from Time to Close in the notification   I have been all over the KB articles and HS support - I am pretty sure there are no simple/clean workarounds.   I hear the Legacy feature for inbox SLAs does allow for different Due in values but regretably we don't have that because have a brand spaking new Hubspot account.     @World, how are others handling this?  Any suggestions?   @hubspot team, can you please support distinct "Due in" for 1st Response and Time to Close? ...その他を表示

Currently, Load Balanced routing distributes tickets to the user with the fewest total open tickets. This rigid counting logic makes the feature impossible to use for teams that handle a mix of quick transactional tickets and long-term complex issues.   We have agents holding longstanding tickets that are effectively "parked" or require low daily effort (e.g., tickets waiting on a vendor or customer response). Yet, these still count against their total capacity. Consequently, the system incorrectly assumes the agent is "busy" and stops routing them new, quick-turnaround tickets, which overburdens other team members.   The Solution: To make Load Balancing viable for complex support teams, we need two specific enhancements that allow for true workload equity rather than just ticket-count equity:   Exclusion Criteria for Open Tickets: : We need the ability to define what counts towards an agent's capacity. For example, we should be able to exclude tickets in specific statuses or pipelines from the load balancing count. Ticket Effort Weighting: Not all tickets are equal. We need the ability to assign a weight or capacity cost to tickets based on their properties (e.g., a Tier 3 ticket counts as 3 capacity points, while a Tier 1 counts as 1 capacity point). ...その他を表示

Description: We need the ability to use conditional options on core ticket fields, specifically: • Pipeline • Ticket status (stage) Use case: • We have multiple ticket pipelines with strict rules about which Ticket Categories can enter which pipelines/statuses. • Today, conditional options only work on properties like Category, Resolution, Source, and custom dropdowns, not on Pipeline or Status. • This means agents can still select pipelines/statuses that are invalid for a given category, and we can only correct it with reactive workflows after the fact. Why this matters: • Tickets routed into the wrong pipeline or status break downstream SLAs, ownership rules, and reporting. • Workflows are a band aid: they correct bad data after it’s created but don’t prevent agents from making the wrong selection in the first place. • Allowing conditional options for Pipeline and Status, controlled by properties like Ticket Category, would let admins enforce process at the point of entry and avoid bad data entirely. Requested behavior: • Treat Pipeline and Ticket status like other enumeration properties for conditional options: o Let us set a controlling property (e.g., Ticket Category). o For each controlling value, choose which Pipeline/Status options should be visible/selectable. • Ideally support this both: o When creating/editing tickets in the CRM, and o Anywhere else users can set Pipeline/Status (e.g., inbox, board view). ...その他を表示

Currently it's only possible to create a maximum of 20 SLA goals in the Help Desk.   When you have different SLA  agreements for multiple customers, of which the SLA times also differs based on ticket priority and working hours, the limit of 20 is an issue.   Would be great if this limit can be removed, extended or if the SLA goals can get a smarter set-up so you can have for example 'priority differentation' SLA settings within 1 goal setup.     ...その他を表示

Just like there is a native property "Number of Associated Deals" or "Number of Associated Contacts" on the Company object, I am in dire need of expanding this to all objects and have an 'Associated' Property on all objects. Beginning with "number of associated Leads" on Company, Contact, and Deal. And on Leads: "number of associated Companies, Contacts, Deals, etc" But it should be everywhere: Any Ticket should have a Number of Associated "Fill in Object" for each object. Any Deal, any Lead, any Service, any... you name it. I have been building for several customers, and have to find all kinds of weird workarounds to be able to reference the fact that there is a related/associated record on a different object, when it should be there out of the box. It affects everything, from Workflows to Reporting to anything you want to build or do or connect. Associations are incredibly powerful in Hubspot, but if I can't use them, they are not useful. ...その他を表示

Idea The ability to create a comment in Help Desk Prior to any Conversation history exists against the ticket.  Who is this for?  Support/Service teams - particularly concerns anyone using Help Desk.  Goal? To add an internal comment to a newly created ticket in Help Desk which is yet to have any conversation history. (e.g. A support rep takes a call and then creates a ticket in Help Desk for a new order. They want to create an internal note to communicate order details to someone in accounts to generate the order post-call. However,  they are unable to leave an internal comment; this is simply a current limitation in Help Desk. Conversation history must first exist to leave an internal comment. See https://community.hubspot.com/t5/Tickets-Conversations/Unable-to-comment-in-Help-Desk-when-there-is-No-Conversation/m-p/1072347#M7617) Value Support/Service teams are enabled to leave comments and communicate important ticket information prior to any logged conversation history in help desk. Supports team collaboration and productivity.   Other Products that Have this Feature ZenDesk currently supports this feature, so clients who have migrated from ZenDesk to HubSpot may feel at a loss with regards to this specific function.  A ticket inside of Help Desk that has conversation history, and hence the comment option is present. A ticket inside of Help Desk with no conversation history, and hence the comment option is absent.   Current Workaround The current work around is to open the ticket record and leave the order information as a note and tag the accounts (or relevant) team member.  Matthew Thornett Solutions Technician at fileroom.com ...その他を表示

After briefly playing around with the open beta Help Desk funcationality, I wanted to submit an idea for a use case that neither the current Inbox nor the new Help Desk seem to work with.   Currently all of our internal communication that happens on a ticket happens via Notes on the ticket. These notes are only accessible when opening the ticket and going through the activity, or specifically the notes.   In the old Inbox, you can also add Comments, which our team also do. However, we have noticed that Comments and Notes seem to fulfil a similar purpose, but are at odds with one another. If I leave a comment on a conversation that is associated to a ticket, then I am not able to see that comment when viewing the ticket. Similarly, if I leave a note on the ticket, I am not able to see that note on the Inbox conversation.   I had hoped that the Help Desk might do something to unify this experience, as it seems to be being pushed as a way to manage the support process all in one place. However, this still seems to be an issue. I can't see Help Desk comments on a ticket, nor Ticket notes on a help desk conversation.   My idea to unify this would be to do one of two things: 1. Show Ticket Notes on Inbox/Help Desk Conversations, and Inbox/Help Desk Comments on Ticket Activity When a note is associated to a ticket, and that ticket is associated to a conversation, also show that note in the conversation at the same timestamp the note was created at. Note-comments (comments made on the ticket note) should also show in the conversation-comments, either as their own entries or like they currently do, under the note. Similarly, when a comment is made on a conversation, and a ticket is associated to that conversation, show that comment on the ticket activity as it's own entry at the timestamp it was made at. or 2. Unify Ticket Notes and Inbox/Help Desk Comments Instead of showing a note on a conversation, and a comment on a ticket, get rid of one (e.g. keep notes, get rid of comments) and have a single source that shows on all associated records. The UI look and feel could be the same, but now when I leave a "comment" on a conversation, that is actually a note that is associated to records that conversation is associated to. I can interact with that note on the conversation, or on the ticket, or the contact, or anything, and that interaction will sync across all records.   Who (what type of role or team) is the feature for? This would be aimed at the support teams who work closely with Tickets and the Inbox/Help Desk.   What is their goal? Communicate on tickets and have those communications be consistent and visible across HubSpot   What value will this add? This will allow the support team to stay in one place. Whether the Help Desk or the Ticket, the person will be able to see all commincations without needing to search around. This will also make Comments more visible, as currently the only way to see a comment on a conversation is to navigate to the Inbox/Help Desk and scroll to when the comment was made.   Are there examples of other places or products who have this feature? The notes on all HubSpot records work great for their purpose. They just fall short specifically on conversations, which is an issue when conversations and tickets are so closely linked together. ...その他を表示