It's a neat idea and I'd like to see how this evolves over time! Keep up the great work!! :)
I do have notes/feedback based off of what I see in the demo site:
# SLA
The SLA stuff under the Admin panel needs to be way, way more robust if I were to ever use it. Many of the clients I work with have different SLA expectations based on the severity of an issue. They also might work in different time zones from Support staff, so calendars may need to be set to "countdown" in relation to either client local time, or support local time, depending on what is decided in the contract. In addition to time zone stuff, there's also issues with what constitutes a holiday; we may have holidays that they don't, or vice versa. Unless something is covered under a niche 24/7/365 contract and is marked as Critical, we wouldn't want the "countdown" to trigger until the next business day. This matters a lot, because many US holidays are on Friday, so tickets will go unanswered for 3 full days.
Here's an example of multiple, different SLA requirements for one client:
* A Critical should have a response within 1 hour (24/7 coverage), and a resolution within 12 hours (24/7 coverage).
* A Low should have a response within 5 business days, and a resolution within 30 business days.
Now imagine that, but multiplied by many, many clients. Instead of having however many SLAs for each situation per client, we like to have "compact" SLAs where there are clauses for different severity ratings of a ticket, and factoring in a bunch of other stuff, for individual clients. Client 1 paid for 24/7 for criticals, but not other stuff, so Client 1 SLA is (this). Client 2 paid for 24/7 for all things, so Client 2 SLA is (that). Client 3 paid for the most basic coverage, so Client 3 SLA is (the other).
We would need an SLA system that accounts for various factors and verbiage within a ticket received. Sometimes it also depends on who files the ticket with us. Is it the "problem child", or is the CEO?
# Time zone (as it relates to SLAs)
In the contract, it is usually formally agreed that if no support staff lives in the clients local time zone, then the SLA response time will not start counting until it applies to the support staffs local time zone. Exceptions are made if they pay for 24/7/365 coverage. So, even if support receives two different "important" tickets from two different clients, one may take priority over the other because the service coverage they have paid for.
## Example(s):
* Client 1 files a ticket at 2PM their time; no 24/7 coverage. It's 4AM for local Support. Support's response time doesn't "start the countdown" until 8AM in Support's time zone.
* Client 2 files a ticket at 11AM and is supposed to have a response time within 4 hours; no 24/7 coverage. The ticket is filed on July 4th (Independence Day in the US) for the Support staff. The 4 hour "countdown" doesn't start until 8AM on July 7th. (3 day weekend)
* Client 3 files a ticket at 2PM on July 4th; have 24/7 coverage. It's 4AM for local Support on July 4th. The "countdown" has started.
# Holiday
It would also be nice if the option for "New Holiday" adjusted automatically each year. We have a fair number of clients, and manually updating Holiday's consistently (and accurately) is not something I see people doing particularly well at the start of each year. It's kind of one of those things you end up catching around September, and realize all of your metrics for the last few quarters have been off.
# FRD and RD text?
In the conversation with Felix Morin, I see warning labels for "FRD Overdue" and "RD Overdue". What are those triggered by? I didn't see anything in the admin area that seemed to point to it. It would be good if, on hover, it would give a brief explanation of what the trigger is. Or is it something that the person who filed the ticket did, somehow?
Hey, thank you for taking time to write such a detailed feedback! Really appreciate this.
The automations are just for that, in automations admin tab you can create rules like email has text `@google.com`, `ceo@xyz.com`.
If true you can apply certain actions like set SLA, assign to a specific agent, etc.
You're right this SLA system is not flexible enough, I will work on improving this feature.
Regarding the "FRD Overdue" and "RD Overdue" labels, they show when the First Response Deadline or Resolution Deadline for a ticket has passed. Yes adding some hover text makes sense.
I do have notes/feedback based off of what I see in the demo site:
# SLA
The SLA stuff under the Admin panel needs to be way, way more robust if I were to ever use it. Many of the clients I work with have different SLA expectations based on the severity of an issue. They also might work in different time zones from Support staff, so calendars may need to be set to "countdown" in relation to either client local time, or support local time, depending on what is decided in the contract. In addition to time zone stuff, there's also issues with what constitutes a holiday; we may have holidays that they don't, or vice versa. Unless something is covered under a niche 24/7/365 contract and is marked as Critical, we wouldn't want the "countdown" to trigger until the next business day. This matters a lot, because many US holidays are on Friday, so tickets will go unanswered for 3 full days.
Here's an example of multiple, different SLA requirements for one client:
* A Critical should have a response within 1 hour (24/7 coverage), and a resolution within 12 hours (24/7 coverage).
* A Low should have a response within 5 business days, and a resolution within 30 business days.
Now imagine that, but multiplied by many, many clients. Instead of having however many SLAs for each situation per client, we like to have "compact" SLAs where there are clauses for different severity ratings of a ticket, and factoring in a bunch of other stuff, for individual clients. Client 1 paid for 24/7 for criticals, but not other stuff, so Client 1 SLA is (this). Client 2 paid for 24/7 for all things, so Client 2 SLA is (that). Client 3 paid for the most basic coverage, so Client 3 SLA is (the other).
We would need an SLA system that accounts for various factors and verbiage within a ticket received. Sometimes it also depends on who files the ticket with us. Is it the "problem child", or is the CEO?
# Time zone (as it relates to SLAs)
In the contract, it is usually formally agreed that if no support staff lives in the clients local time zone, then the SLA response time will not start counting until it applies to the support staffs local time zone. Exceptions are made if they pay for 24/7/365 coverage. So, even if support receives two different "important" tickets from two different clients, one may take priority over the other because the service coverage they have paid for.
## Example(s):
* Client 1 files a ticket at 2PM their time; no 24/7 coverage. It's 4AM for local Support. Support's response time doesn't "start the countdown" until 8AM in Support's time zone.
* Client 2 files a ticket at 11AM and is supposed to have a response time within 4 hours; no 24/7 coverage. The ticket is filed on July 4th (Independence Day in the US) for the Support staff. The 4 hour "countdown" doesn't start until 8AM on July 7th. (3 day weekend)
* Client 3 files a ticket at 2PM on July 4th; have 24/7 coverage. It's 4AM for local Support on July 4th. The "countdown" has started.
# Holiday
It would also be nice if the option for "New Holiday" adjusted automatically each year. We have a fair number of clients, and manually updating Holiday's consistently (and accurately) is not something I see people doing particularly well at the start of each year. It's kind of one of those things you end up catching around September, and realize all of your metrics for the last few quarters have been off.
# FRD and RD text?
In the conversation with Felix Morin, I see warning labels for "FRD Overdue" and "RD Overdue". What are those triggered by? I didn't see anything in the admin area that seemed to point to it. It would be good if, on hover, it would give a brief explanation of what the trigger is. Or is it something that the person who filed the ticket did, somehow?