1. Kayako Download customers: we will continue to develop and support Kayako Download beyond July 2017, alongside the new Kayako for existing customers.

    Find out more.

  2. The forum you are viewing relates to Kayako Classic. If you signed up or upgraded to the new Kayako (after the 4th July 2016), the information in this thread may not apply to you. You can visit the forums for the new Kayako here.

Drastically missing functionality

Discussion in 'Upgrading to the new Kayako' started by Phil R, Jul 5, 2016.

  1. Phil R

    Phil R Established Member

    So, yesterday was more of a rant. Today, I was looking at this from a feedback perspective and to analyse if or not thsi would fit within our model.

    What I have seen is not impressive and it is either missing functionality, or the "all the bells and whistles" trial you claim, sold me a lemon.

    A quick background on what we do. We do not operate in your normal "open product support" model. We are very much a closed support model, with paid tiers of enterprise support for a few ranges of enterprise platform software we provide.

    This operates with one department per product line, with some customers taking several products from us, which can include "support only". We then user User Groups for our tiers of support, such as Silver, Gold, Platinum (plus some groups split into timezones of GMT & PST).

    This then drives our SLA provides (all 450+ of them). This sets first response SLA, which is our only customer assured metric (we do however use metrics in many others areas internally for efficiency and team modelling). These SLAs are driven by our 4 priority levels.

    So an X department, Gold PST customer with a priority 1 ticket, will have a specific SLA profile assigned.

    Similar logic is then uses for notifications rules with each user group, department & priority group, driving three notification rules (one for new ticket, one for new customer reply & one for priority change). This is over 500+ notification rules, all used to drive Pagerduty.

    So let me talk about the good news. Either Webhooks or Zapier is going to solve a lot of our Pagerduty complications. Notification rules will become very minimal. Fantastic for the manageability.

    However, that is where things appear to drop from the cliff.

    The concept of departments has gone. The closest two things I can find are "Case forms" or "Case fields".

    There does not appear to be any concept of User Groups that I can find. There are Organisation Fields or User Fields that would could create to service this purpose, but to what value?

    These fields cannot be used in the SLA condition fields that I can see, so whilst I can pick "X department" as the value if I am using "Case forms", I cannot select the department as a value of a "Case field". More importantly, if I had a Organisation Field or User Field to signify User Group, I have no way to make "Gold PST" as a condition of the SLA Plan.

    SLA plans go out of the window and best case scenario, I can deliver departmental & priority plans.

    An alternative I can see is I designate the "Type" field for my User Groups. This means the following problems.

    1: The "All bells and whistles" trial does not let me edit type or priorities, so is not what is claimed on the tin.
    2: The type fields is clearly not designated for this purpose
    3: We use types in certain areas, this means we lose the type capabilities.

    The second major issue here, SLA plans do not allow me to associate a timezone with them?

    In v4, I could associate a time conditions to a SLA plan. This allowed me to drive the User Group to timezone mapping.

    There is no function for timezones at all in the new kayako. I can define a set of business hours to an agent, but that isn't any value at all. The people that work my tickets are not the customers, so one of my colleagues in China that answers a ticket does not dictate the opening hours associated with the ticket, the profile of the customer does.

    This has effectively removed our ability to enforce our "out of hours" time within SLA plans and makes it impossible for us to provide a differentiated product between our Silver and Platinum products.

    Next really big problem. Where do I find my list of users, list of organisations or list of users associated with an organisation?

    Seriously? This is completely missing from the product.

    So I see I can search for users or orgs, fine, happy with that. V4 provides that though.

    So quick intro to my demo setup. Mr "Test User" is associated with Organisation "Test Inc".

    I search for "Test in" (note the missing 'c' in the search) or even 'test i'. I get no results in the search. That is poor and a no no.

    I search 'test' or 'test inc' and I see the result. I select 'Test Inc'. What can I see / do here.

    Well, I can update the name of the org, I can update the org fields, I can add email domains / tags, I can even delete the org. However, where is my list of users associated? Where is the list of tickets associated? I thought this was meant to be a unified view of activities, I can literally do nothing other than edit the organisation itself, it served no other purpose at all.

    I search for my test user and load it up. Now I can see I have a sub-tab for user/org (not the tabs along the top itself), but where is the list of tickets? I can see the recent cases on the right, but no full list of cases.

    I see I really only have access to the user & org together when I view a case. However, this has the above problems, how do I see the history properly.

    Our customers have anything upto 10 contacts that they can associate with their organisation depending on their plan, or if they pay for more contacts. How can I see how many or who they are?

    How can I look at other cases from the user / organisation and look for repeat tickets and trends from this company?

    I can't do any of that.

    For user & organisation panels, so much space is given the notes / activities it's actually quite stupid.

    In v4, we have many organisations level fields, only one of these could be converted to a note on the org, but most need to be fields.

    These along with user field are no longer front and centre when a case loads. I have to browse over multiple tabs, just to get a full picture of the field values.

    The audit log / activities of a ticket are also poor. "Joe Bloggs updated Test Ticket a minute ago"?

    What did they update?

    I certainly can't see that somebody changed the priority from Urgent to Low. I can't see the transition between status either, so I can see the reply and that I have set the ticket as "Completed", but I cannot see when I moved to in progress, to other states or anything else.

    It also seems that I cannot operate in a closed support model like we do. Anybody and everybody can signup and I cannot close that it seems.

    These problems literally show on every type of workflow I try to do, so much so, that I really don't want to investigate any further, as I just know I am about to find out more.

    I know there is more coming, such as time tracking (critical blocker from us progressing).

    A minor item of feedback, I cannot create a case for a non-existent recipient. I have to go through the process of creating a user before I can do this. The create case field works in a obscure way for a non-existent user.

    I type fakeuser@ and then the box empties, before I type the rest of the email address. No feedback is provided, it just empties and leaves me wondering what is happening.
     
    nsti and Peter Kratky like this.
  2. Phil R

    Phil R Established Member

    Is it really only possible to assign Business hours to teams?

    This is a genuine question at this stage, but likely to be feedback (and a possible suggestion).

    We offer SLAs under Silver, Gold & Platinum offerings. For Silver & Gold, we offer it in a choice of GMT or PST timezones. This means there are five offerings.

    I have to create five teams as a result (plus other ancillary ones), plus five business hour profiles (2 GMT, 2PST and one 24/7, plus others which I really don't want to thing about yet). Obviously, mapping one business hour profile to one team.

    I then assign five SLA profiles that map one-to-one to each of the teams.

    Then overall, I need to add all team members to all five teams. As all people will be involved in all departments, that currently 17 members all added.

    Finally, triggers are setup such that a custom field on a Organisation have one of five values, mapping one-to-one to a team, so that cases are automatically assigned to a team and stay there, resulting use a users cases correctly pinning to the correct SLAs according to the correct times.

    So the question. Is that really the only way you can pin business hours?

    Whilst the above works, it's messy.

    I am now (and all other staff) in five teams. When I goto the Assignee box, I have to select via a team, just to pick myself or somebody else.

    If I search for mu name in the dropdown, then I see myself five times and have to select one. I really only need to see myself once in this instance (though the good news, I can select any, and the trigger correctly assigns it back team whilst leaving it as myself).

    I can envision occasions when a trigger may not exist for this and it incorrectly reports to the wrong team, because of a incorrect selection by somebody.

    I also don't appear to be able to set filters for when I can select a team, such as status is X, case form is Y, type is Z, only teams G, E or F can be picked from.

    The teams are also annoying in that every staff member needs to be in every team. This is a process that is going to have potential management overheads.

    Why can't this be subteams? So say add all staff to a primary team called support. Then add my other teams as a sub-team of this, in which I can check an option that says "Include all from parent team". This way I manage users into a single team, but they are automatically available for my SLA driven teams.

    For that matter, why can I not select Organisation form key / values as the conditions for a SLA plan? Why do I have to have the SLA condition set to a team and have a trigger pickup on the Organisation form setting the case to a team.

    Actions for triggers cannot set a Case to a specific SLA plan either, so I couldn't just have a single team and then have the trigger set the SLA for us (not that it would help, as business hours don't get set to anything other than teams anyway).
     
  3. Gary McGrath

    Gary McGrath Staff Member

    Hi Phil,

    I have merged your two threads as I think I can combine some answers here for you.

    One of the key things to understand is that we have removed departments in favour of using teams. You can still use teams to represent your old departments if you need to ( e.g. create a support team, sales team etc.. )

    The power of using the new teams over departments is that you are no longer limited by those departments. Let me give you an example, let’s say you have all your support cases in your support team view, but you also wanted to create another view which showed “critical” cases from all teams in it’s own view for mangers to keep an eye on. Using our new teams and the power of our case views, you can now create those kind of setups.

    Your staff will be able to find and see all the cases which are relevant to them, in a view which makes sense to them, to help them to get to work quicker.

    By the sounds of it, a lot of the routing you use for users is based around user groups. In the new Kayako you can use tags to achieve this, and it opens up much more powerful and meaningful interaction.

    We have taken all the separate rule areas, such as SLA, escalation, notification, email parser, workflows and combined them all into 1 single rules engine ( our automations ) This means you can link all these things together, in 1 rule, to perform all the actions you need, this should drastically reduce the amount of rules you need to create.

    When you create an SLA, you don’t need to set the criteria here for all cases. To take care of your regionalised users, you could create an automation trigger to say if the users timezone = Europe/London tag the case with EU. Then in your SLA plan, under the criteria you can use if case tag = EU, apply the SLA. In this way you can ensure your SLA per timezone is applied.

    If you tag a user for example with GroupA ,ProductA, ProductB, PaidSupport (these might not quite a relevant in your case, but hopefully it highlights how to use it ). You can then use our automations engine to say, If a user is has GroupA, and also has PaidSupport, tag the case with SLA123 to ensure the SLA applies to it. Now in your views you can create a view to show all cases which are tagged SLA123 and EU, or SLA123 and USA etc. This will ensure only staff which can help with that will be able to see that view and use it. You can then also use the power of our API/Zapier to send an SMS alert to those staff members, or maybe just an email.

    It will take a little bit of getting used to, but the new automations engine is at the core of Kayako, and it can bend and flex to achieve anything which was possible in v4, while opening up a whole new world of possibilities, simply as the all the rules throughout v4 have been unified into a single engine.

    I know I have not answered everything above, but I can see you are trying to get a working configuration, so wanted to point you in an easier direction.

    We will follow up more on the other points you raised.

    Gary
     
  4. Phil R

    Phil R Established Member

    Thanks Gary,

    I appreciate my two messages conflict somewhat, given that we have established at least one way to achieve our goal (although it's very untidy).

    Looking at your solution for tagged customers, I can see this gets the goal. However, this too is untidy and has a set if inherent problems. I even looked through triggers to see if they solve at least some of them, and this singing / dancing features doesn't!

    For example. The tagged logic implies that for example, "Timezone:pST" & "Timezone:pST" (and some of our other sillier items to come covering CEST) are mutually exclusive. If they are tagged with one, they cannot be tagged with another.

    Another variation / rule for this is that if they are tagged with one, they should only be substituted for another applicable tag (within grouped business rules or moved to no tag in said business rules).

    Why does this matter? Human error. Plain and simple.

    Knowledge diminishes over time and knowledge share only goes so far. Even knowledge base detail or best practice articles are written in the eye of the person that knows the process. They rarely convey every angle to ensure the knowledge train continues.

    Technically though. Tags on their own don't support this. They are just a collection of unique keywords in which you can have zero or more assigned, and any individual tag only only appear assigned once. There is nothing governing them as is that if X is assigned, Y cannot.

    Triggers offer me the ability to trigger when tags do / don't appear, but not in a mutually exclusive logic. This means I can see when any individual one tag is / isn't there, when all tags in a defined set are / are not assigned, or even when any one of a group of X:Y is missing.

    In other words, if I have Timezone:pST, Timezone:GMT, Timezone:CEST

    I could trigger the first condition for any individual one of them, for the second condition, I could trigger when ALL are assigned or none of assigned and the third condition, when zero of them are assigned (one, two or three do not trigger, but zero will).

    The best I can see is to do two tags.

    1: Trigger on condition three, when zero of them are assigned. Action, assign another tag, e.g. Timezone:UNKNOWN

    2: Trigger on tag Timezone:UNKNOWN. Action, email a team to report the assignment

    The two triggers would allow for reporting / searching on what has been allocated to the KNOWN easily.

    That doesn't solve what if two or three of three are assigned?

    How do I apply SLAs then?

    There is no SLA ordering like there is in V4, so creating five of them to match our rules (GMT / PST for Silver, GMT / PST for Gold, Platinum 2/4/7) will look at two fields.

    1: Organisation field named "Support Plan"
    2: Organisation tag "Timezone:*" (n/a for platinum)

    Take Gold for example. What if GMT & PST tags have been assigned to "ACME Co."?
    Which SLA plan gets assigned here, as two plans will not match any case raised by "ACME Co."

    I appreciate the question of "Which would you prioritise, GMT or PST?". This is a question of our business rules (and I could not answer it, but the question would go into our design process), but even with an answer, I don't know how Kayako will react, or make Kayako enforce the business rule we decided.

    Regarding teams and departments. I am still not sure I follow the logic behind what you have provided.

    Teams are an entirely internal concept to Kayako as far as I can see.

    We have 12 Departments right now, 10 of them customer selectable, each one presenting each product we provide. The two remaining are deployment departments for the two core areas those 10 products represent. Customers can reply, but they are not customer selectable.

    As far as I can see, Case Forms represent that the most. Customer selects to raise a case and if offered a selection of departments.

    The alternative is a Case Filed to offer them this selection capability. However, Case Forms favour this, as the Case Fields can be defined to be attributed to a Case Form, the same way as Customer Fields can be to a Department in V4.

    I don't see how Teams would service the Department in this capacity in our use case. In yours maybe, were sales, support are the few departments you have.

    Given we have 10 core support departments, that would mean 50 teams. One of each for GMT & PST for gold & silver, plus a generic platinum. If we add more colours (and trust me, I wouldn't put it past our sales teams) or decide to offer more native timezones, this expands rapidly. These all them come with the same complications we have with managing our current SLA plans or notifications.

    All these teams are required, because the business hours is applied to the team.

    The Teams stuff does seem backwards, because it's almost as if you have taken User Groups and Staff Teams and done very odd things to them, merging parts of them that don't make sense in the context of the other.

    The Custom Roles & Permissions, I cannot see and trial, so I cannot comment if other portions have been moved there. However that doesn't solve the context issues.
     
  5. Gary McGrath

    Gary McGrath Staff Member

    Hi Phil,

    RE tags, the automations engine can prevent double tags from being added:

    Screen Shot 2016-07-06 at 12.11.45.png

    The automations can even roll back field changes being made, e.g. if status = abc and custom field A = option B, prevent custom field B from being changed to option C

    So you could program in selections which were not valid to ensure there were no conflicts.

    but let's take the case where 2 SLA's apply. The first SLA to be applied will be the highest SLA in the list. ( if you hover your mouse over the left hand side of the SLA's, you can click and drag them into the appropriate order )

    For teams / case forms, these are not linked by default, but you can do this

    Case forms are really for asking the customer for extra information, you could base them on "support" and "sales", but you could also easily base them on "Order new equipment" and "Apply for ID card" ( e.g. department or type of request )

    Then using the automations engine, you can create a trigger to say, if a new case is created via the help center, and it's case form was "support", assign it to our support team. But at the same time, you could also add to that same trigger, If the case form was "support" or "order new equipment", then assign it to support team. Example:

    Screen Shot 2016-07-06 at 12.25.53.png

    This lets you mimic the design of using departments, but leverage the fact you are not stuck with them. you can create several custom case forms, or real life requests coming from customers, and then assign those to whichever team is needed to help the customer.

    Does that make it a little clearer?

    Gary
     
  6. Phil R

    Phil R Established Member

    Hmm.

    Ok, I see where that is going with the tags. But that seems to force us into making use of tags for purposes that we didn't otherwise want to within the case level.

    We utilise case tagging for "Reasons" for support.

    We could use a milti-select case field now that must be set before completion / reply, but that that would be a stupidly long list. No other field allows multi-select. This is why tags suit it.

    Now we would end up with tag pollution and as I noted, risk of human error that may impact triggers that has implications.

    As for Case Forms versus Teams, we will be using Case Forms specific to a product.

    For one product it might be a field for the version, for another it might be a characteristic of the way it is setup. The fields presented are product specific. Generically we might have a field that asked what contact method is preferred (Phone, Webex, GotoMeeting, Email).

    This would tie us into using Case Fields for Departments.
     
  7. Gary McGrath

    Gary McGrath Staff Member

    We are certainly open to feedback on thing we could improve. If we added the ability to base SLA's directly on custom fields, as well as tags, would that work better?

    Gary
     
    Jonathan Forrester likes this.
  8. Phil R

    Phil R Established Member

    Quite possibly.

    Though don't take it as the end of this train of throught. I need to examine if there alternative samples to our flow, and see if there are suggestions that spring out.

    Absolutely, set SLA based on a specific Organisation Field would do that out of the box.

    This has the bonus for us in that business rules are enforced, as only one selection on the Org Field can be made (if the correct field type us used). This doesn't remove human error from a change to this, but I do like the idea of a Trigger sending an email if this Field is changed, which creates a workflow all if its own (veto, authorise, feedback).

    This however still leaves the multiple team scenario. Whilst we can get the SLA Plan rules to pick the correct rule, the SLA plan itself does not contain the Business hours.

    I could assign the same SLA Plan to two cases, in which the Plan has a 12 hour response time on all priorities and the time applies to business hours.

    However assigning it to "Agent X" in one team that has business hours of 6am to 8pm based on GMT means it would go overdue the same day, whilst assigning to the same "Agent X" in another team, may see business hours at 9am to 5pm based on PST (If my system setting is set to GMT, then my PST team is just an offset, so I pick 5pm to 2am GMT in the business hours).

    Now my triggers can be used to set the Team correctly, it can even be used to enforce the team in the event of change (using a trigger on org field, combined to changing from a relevant team).

    But as noted, I have 17 users that are effectively one team. All answer all product questions. Yes, we have tiers of support, but even at all tiers, all users could response at level one.

    So the "Assignee" field becomes a little odd.

    Yes, I could pick "Agent X" from any team in that list and my trigger will ensure the correct team stays in place. But it looks odd when doing the selection.

    It also still has the management problem in that I have to select all users into all teams.

    I am wondering if the thought of sub-teams had been explored, in which we could elect to say sub-teams contain all users in the parent team (possibly by a checkbox on the sub-team), and if not an all user sub-team, only allowing users that are members of the parent team.

    I can then have as many teams as I want, yet only manage members in one or a subset of teams.
     
  9. This is a really good idea for our company's work flow! Hope it goes through! :)
     
    Jamie Edwards likes this.

Share This Page