Requests / Ticketing Module

Summary Requesting the ability to modify ticket due dates either globally across the system or via integrations (webhooks/Zapier). This would allow for automatic adjustment of due dates based on business hours and custom rules. Current Limitation Currently, when a ticket is submitted, we cannot automatically set due dates that account for business hours and non-working days. This forces manual adjustments or results in unrealistic due dates that don't reflect our actual working schedule. Use Case When a client submits a ticket on Friday at 4 PM, we want the system to automatically calculate a due date of Tuesday at 4 PM (assuming 48 business hours and weekends off), rather than Sunday at 4 PM (48 clock hours). Requested Functionality Option 1: Global Business Hours Configuration Ability to define business hours/days in system settings Option to set "X business hours" rather than clock hours for SLAs Automatic exclusion of defined holidays and non-working days Support for different business hours across different departments/ticket types Option 2: Webhook/Zapier Integration Expose due date fields to external automation tools Allow external systems to calculate and update due dates based on custom logic Enable triggering of due date updates when specific ticket conditions change Support batch updates for multiple tickets simultaneously Benefits More realistic SLAs that align with actual business operations Reduced manual intervention to adjust unrealistic due dates Improved customer expectations through accurate time estimates Better workload management across teams Enhanced reporting accuracy for SLA compliance Priority Medium-High: This feature would significantly improve our workflow efficiency and customer communication accuracy. Additional Context Our team has received consistent feedback from both staff and clients about confusion related to due dates falling on non-business days. This creates unnecessary stress and sometimes leads to missed deadlines when staff are out of office.

I’d love a feature to schedule ticket updates to send during standard working hours (9 AM–5 PM). This would help when drafting updates working out of hours.

I love love love the new ability to start a timer from a ticket but to take it one step further, I'd like to be able to assign the ticket to a project so the timer entry maps to existing recurring invoices. At the moment, the timer entry doesn't belong to any projects.

Schedulers can require upfront payment. Requests should allow this as an option, too.

Allow administrators to configure which ticket types are available to each client. This feature would enable the customization of ticket options on a per-client basis, providing more granular control over the services that clients can request through the ticketing system.

Why can you only link requests (at the request screen) to opportunities and not projects? Would love to see the ability for both.

When viewing an Inbox Email give a quick "send to ticket" option that will convert the email into a ticket same as if you forwarded it to your internal ticketing address.

For teams who use private notes often in a ticket, have an option to toggle on private notes as the default.

Currently, after we respond to a ticket, we often face a dilemma: if we close the ticket immediately, clients may reopen it, wondering why it was closed prematurely. Conversely, if we leave it open, we must manually track and review these tickets to decide when it's appropriate to close them due to inactivity. To streamline this process and reduce manual overhead, I suggest implementing a feature that automatically closes tickets after a specified number of days (X days) of inactivity following our reply. This would allow us to maintain an organized system without inadvertently closing tickets prematurely or leaving them open indefinitely. This auto-close feature would specifically target scenarios where we've responded, but the client has not replied within the set timeframe—ensuring that pending questions or ongoing discussions remain active. By automating this aspect of ticket management, we can focus more on engaging with active queries and providing a higher level of service. I believe this enhancement will greatly benefit our operations by reducing manual workload and enhancing user satisfaction.

Issue: Admin ticket responses sent via email with no client portal notification. Fix: Add client portal notification in notification window for ticket responses as it does for admin in the Moxie portal. Background: Ticket responses deafault to email response only assuming the client is not "in the portal" Valid I guess, but there are cases where clients have the portal up looking around and then would have no idea that a ticket was responded to since there are currently no client notifications in their portal like there is for admin in the main moxie notifications for admin. In this case a client would have no idea for two hours that a responses was added to a ticket to the portal they were in until going back to their email. So, if a client is inside inside the portal and not even knowing something happened in the portal you were in seems to not make sense. I get the original idea but maybe should be an option for notification settings to allow clients the ability to get in portal ticket notifications. Browser push notifications would be great as well.