Customers are generally satisfied with both our service coming from Sales consultants (SCs) and our technical support from Support engineers (SEs). However it still happens from time to time we drop the ball on some cases and run into issues between teams which shouldn't happen
Our goal must always be a satisfied customer and that's the only proof that shows we're handling our business correctly and are doing our job well
Below are listed a few important things that you should already know, but please make sure to read them carefully again and implement them in all future cases:
- SCs job and responsibility is to forward customer emails who have technical questions/issues to the support team and follow up on the progress early and often to make sure a customer got all the answers and the help he needed
- SEs job and responsibility is to include corresponding SC in all conversations they have with the specific customer and to also let SCs know when the support job is done; although SCs won't participate in this "technical part", they will see the progress of the case and will be able to plan their future activities
- SC responsibility is to make sure a customer always gets what
he needs (a technical support, a quote, respond to a specific question,
etc.)
- SEs - during the business hours (M-F 8-5 US ET), we should acknowledge all emails within an hour, provide actionable response within 24 hours and have a resolution within 72 hours
-- If we get an email after business hours, SE on duty should ACK email, while the product owning SE should provide actionable response on the next business day
-- Here it is very important to know that if the SE on the job doesn't know the answer to some question or he is not sure about something, ignoring an email until he gets an answer *is not an option*; SE must reply (ACK email) and provide an ETA when more details will be provided
- SCs – during the business hours, we should acknowledge all emails within 15 mins and provide actionable response within an hour; if the assigned SC finished the shift and a customer sends an email, a colleague from the team should respond and provide all necessary details
- Not responding to customer emails and not following the rules above is not an option; we need to be responsive to our clients and honor the things we put on our website such as our availability and resolution times
-- If we don't honor our commitment it creates dissatisfaction for our clients that has already in several cases directly or indirectly influenced client's decision to purchase our products
- After the customers purchase our products our job is not done – we still need to care about their satisfaction and to make sure we solve all the problems they run into
-- If we can't solve a problem immediately we can at least be responsive to provide all the info and all the help that we can to at least workaround an issue or provide an ETA for full resolution
- When replying to customer's email, it's desirable to always have following guidelines on your mind:
-- Read every email twice very carefully, and then once again
-- Make sure to provide an answer to every question a customer asks
-- Reply inline and use a different color (except red)
-- If you don't have an immediate resolution, make sure to provide an ETA to the customer for the question or issue he/she has reported
-- Always provide an ETA for the next step if the ball is in our court; if we miss that ETA for whatever reason then follow-up to provide a new ETA without forcing customers to follow-up first
Saturday, February 3, 2018
Monday, January 22, 2018
Support engineer medior - Level 2
The path to Support engineer Level 1 or "SE certification" as we commonly call it is relatively straightforward:
a) Get to 100% unified metrics in at least 3 consecutive months:
-- ZIGS 100% - easy enough with majority of our products, just be as hard on them as possible
-- Writing 100% - this is the most challenging part as it requires constant learning and systematic weekly writing ideally without ups and downs
-- Support coverage divided between colleagues and following The Support Engineer’s Creed
b) Contribute to your team by helping them own all of the content
c) Contribute the team with product ownership - comp analysis
d) Cover the operational work of getting the products through the testing and out to production
When you have the metrics and both your team and internal customers provide good values feedback you are all set for Level 1 certification - on average this takes 9-12 months but we did have some cases (one of them only a few months back) of certifying in 6 months flat
SE Level 2 shares all of the requirements with SE Level 1 except that metric requirements are higher
However simply achieving higher SE metrics won't be enough to get certified for SE Level 2 as the standards for contributing to the team and the company are also higher - meeting those standards is a requirement for a positive Level 2 values review by stakeholders and internal customers
Standards
Here are some specific examples of higher standards expected from SE Level 2:
1) QA - as level description also says:
-- Provide real-world testing vs. just some easy to catch surface bugs or edge cases by pounding your mouse and keyboard until something breaks
-- Be an advocate for automation vs. allowing others to ask for test automation from your team
-- Plan your work and be meticulous with regression testing, never allow the same bug to resurface in production
-- Know your products performance, usability (UX especially) and quality and raise issues vigorously and frequently; don't allow customers or others within the company to do this for you
2) TQM - keep owning the content including everything you previously wrote and is available in production as it must be kept up-to-date
3) Earn the respect of your team:
-- DON'T keep quiet and allow for known issues to go unchallenged
-- DON'T be stubborn and insist on low-ROI fixes and changes
-- DO stand your ground when you know and have the facts that the issue you raised is valid and important to the customers
4) Lead or assist with company-wide initiatives
-- Update and create standards that affect multiple products
-- Raise issues with content and products owned by other teams
Time period
Expected time period to gain the necessary experience for SE Level 2 from day one on the job is at least 3 years
This depends on each person individually but if you started working without previous database administration / development industry experience then you can consider yourself a fast learner if you certify as soon as you hit this mark
No regression
More so with SEs than with other roles, regression is an automatic process based on metrics
This also means that you can't regress when it comes to values and contribution you had in order to achieve Level 1 and must keep hitting the high notes most of the time
Hard skills
This will come naturally with experience through the creation of new content, real-life use case testing, test automation, and other work
Being T-SQL guru or knowing secrets of SQL Server and cloud administration isn't the goal, but knowing your owned products well and related technologies is
Ultimate test
Success = results / time / stakeholder_time
Note the last variable in this equation: stakeholder time
Ask yourself how much time do you save to stakeholders?
a) Are you being reminded to update owned content (roadmaps, articles, videos)
b) Are others in the company raising endemics and red flags in your products
c) Do stakeholders have to invest much time in order to review your content (articles, release notes, F matrices, etc)
d) Are you being asked questions about the team status that catch you by surprise
e) Are you unable to answer a functional question related with the owned product
f) Are you unaware of a comp status or a melting iceberg affecting your team
g) Is your view of the product PUQ different from reality
h) Have you recently approached product development and design like a "coder" instead of a customer
If you've answered any of the above with a Yes then that is a potential blocker you need to remedy
a) Get to 100% unified metrics in at least 3 consecutive months:
-- ZIGS 100% - easy enough with majority of our products, just be as hard on them as possible
-- Writing 100% - this is the most challenging part as it requires constant learning and systematic weekly writing ideally without ups and downs
-- Support coverage divided between colleagues and following The Support Engineer’s Creed
b) Contribute to your team by helping them own all of the content
c) Contribute the team with product ownership - comp analysis
d) Cover the operational work of getting the products through the testing and out to production
When you have the metrics and both your team and internal customers provide good values feedback you are all set for Level 1 certification - on average this takes 9-12 months but we did have some cases (one of them only a few months back) of certifying in 6 months flat
SE Level 2 shares all of the requirements with SE Level 1 except that metric requirements are higher
However simply achieving higher SE metrics won't be enough to get certified for SE Level 2 as the standards for contributing to the team and the company are also higher - meeting those standards is a requirement for a positive Level 2 values review by stakeholders and internal customers
Standards
Here are some specific examples of higher standards expected from SE Level 2:
1) QA - as level description also says:
-- Provide real-world testing vs. just some easy to catch surface bugs or edge cases by pounding your mouse and keyboard until something breaks
-- Be an advocate for automation vs. allowing others to ask for test automation from your team
-- Plan your work and be meticulous with regression testing, never allow the same bug to resurface in production
-- Know your products performance, usability (UX especially) and quality and raise issues vigorously and frequently; don't allow customers or others within the company to do this for you
2) TQM - keep owning the content including everything you previously wrote and is available in production as it must be kept up-to-date
3) Earn the respect of your team:
-- DON'T keep quiet and allow for known issues to go unchallenged
-- DON'T be stubborn and insist on low-ROI fixes and changes
-- DO stand your ground when you know and have the facts that the issue you raised is valid and important to the customers
4) Lead or assist with company-wide initiatives
-- Update and create standards that affect multiple products
-- Raise issues with content and products owned by other teams
Time period
Expected time period to gain the necessary experience for SE Level 2 from day one on the job is at least 3 years
This depends on each person individually but if you started working without previous database administration / development industry experience then you can consider yourself a fast learner if you certify as soon as you hit this mark
No regression
More so with SEs than with other roles, regression is an automatic process based on metrics
This also means that you can't regress when it comes to values and contribution you had in order to achieve Level 1 and must keep hitting the high notes most of the time
Hard skills
This will come naturally with experience through the creation of new content, real-life use case testing, test automation, and other work
Being T-SQL guru or knowing secrets of SQL Server and cloud administration isn't the goal, but knowing your owned products well and related technologies is
Ultimate test
Success = results / time / stakeholder_time
Note the last variable in this equation: stakeholder time
Ask yourself how much time do you save to stakeholders?
a) Are you being reminded to update owned content (roadmaps, articles, videos)
b) Are others in the company raising endemics and red flags in your products
c) Do stakeholders have to invest much time in order to review your content (articles, release notes, F matrices, etc)
d) Are you being asked questions about the team status that catch you by surprise
e) Are you unable to answer a functional question related with the owned product
f) Are you unaware of a comp status or a melting iceberg affecting your team
g) Is your view of the product PUQ different from reality
h) Have you recently approached product development and design like a "coder" instead of a customer
If you've answered any of the above with a Yes then that is a potential blocker you need to remedy
Subscribe to:
Posts (Atom)