Hey all, in my company we’ve been having a lot of trouble with our first-line support team and I wanted to get some ideas how it works in other companies.

To give some context, I work in a Customer Team (L2-L3 Support) for a MSP, previously I belonged to the Internal Operations Team and they had a very negative view on the first-line team, with opinions like:

  • we don’t need them
  • they lack knowledge
  • management can’t create a good first-line team because they don’t want to invest

But I didn’t interact a lot with them before, but now, I have to interact with them on a daily basis, and I see some things that have started to make me worried about the team:

  • They ignore KB’s
  • They say that they don’t have access to certain servers, or that they don’t find the correct credentials and just pass the ticket for us to solve
  • They have people that lack knowledge in some basic support, I have had tickets passed on with notes like “I don’t know how to use Linux”

From my point of view and the team I belong now, we all think that management didn’t really verify the required knowledge for some members of that team, but they really have a few that are trying really hard to improve their skills.

We have started to try to help them, so that our job can also become easier:

  • Improve the language in legacy KB’s
  • Simplify the process in the monitoring platform with more directions
  • Automating some processes so that the first-line can execute fixes without having the required knowledge on the backend
  • Picking the best members of their team and promoting them to our team

That team also has some problems that I fully recognize:

  • Shit pay
  • Bad leadership, that team has had 6 different Team Leaders in a short time (I have been here for only 2 years)
  • Lacking interview and requirements for the position

Sorry for the long text, would love to have some feedback from your sides, or is this normal in a lot of companies?

  • jrest18n@lemm.ee
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    It is pretty typical in my experience for tier 1 to take a ticket and escalate.

    The first step in improving it with most organizations I’m at is helping get better information from tier 1.

    Once you put a form and policy in place you can go from the first example to the second which is very helpful. If the ticket templates can be pre-populated depending on the type of ticket for those tier 1 workers, you can also bake in troubleshooting for some of the common issues. If the issue isn’t well understood and requires out of the box troubleshooting, I don’t expect them to be able to deal with it.

    Original ticket: Ticket#23232 User states they cannot access Z drive. Reboot no avail.

    New ticket once we have a policy and form: Ticket#23232 Desktops --> Drive Access --> Existing access issue

    File path: User is attempting to access //company/hr/forms Username: user.name Hostname: hr-3423423-lt Can they access other shared drives?: Yes Are they in the proper group? (See KB2332 to confirm) Error message: error.png Confirm file path is being entered or mapped correctly(y/n): Y Rebooted system(y/n): Y Account locked(y/n): N Account expired(y/n): N Confirmed VPN connection(y/n) etc etc

    • StuffToWrite@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Yeah I think the problem with my company is that they want both things.

      That they can be able to solve easy issues following a KB and to just escalate tickets if they take a bit more time or knowledge to solve.

      We’re trying to solve the easier issues with Rundeck jobs that they can execute, but I think that will bring a new bag of issues:

      • If the Rundeck job fails, they will have to not only include the issue but also the error in the Rundeck Job
      • How can they check (or even have the knowledge) to know if the Rundeck Job worked like it should, to avoid situations where they said the issue is resolved, but then the client returns the ticket saying that nothing changed
      • If a Rundeck job needs some parameters, that may add a bigger level of knowledge for them to have, to avoid running the job on the wrong machine for example