Usually in many technical/product companies, customer support is divided into different levels: Level 1 (L1) is responsible for communication, Level 2 (L2) is responsible for investigation and Level 3 (L3) might finally fix it if the problem still exists. But what if all of that friction could be removed? For over three years, I've worked in a hybrid L1/L2 support role on google BigQuery based data products. I was often the first and last person to touch the issue: from the initial report to its resolution. And I strongly believe that this model offers huge value to both clients and engineering teams. Let me share why. What it means to be L1 and L2 at the same time? What it means to be L1 and L2 at the same time? At the company I currently work for, I was the main technical contact for incoming issues related to our data stored in google BigQuery. That meant: Receiving and triaging incoming support tickets directly from clients or internal users
Investigating issues using SQL, logs and metrics in BigQuery and Airflow
Writing small python scripts to automate some processes
Identifying and escalating true engineering issues connected with the underlying code
Building basic monitoring to proactively detect issues before clients reported them Receiving and triaging incoming support tickets directly from clients or internal users Investigating issues using SQL, logs and metrics in BigQuery and Airflow Writing small python scripts to automate some processes Identifying and escalating true engineering issues connected with the underlying code Building basic monitoring to proactively detect issues before clients reported them There was no call center, no scripted hand off, just engineering, connected directly to the people who were facing the issue. Why this helped clients? Why this helped clients? Clients got faster, more meaningful responses because I could: Immediately access and understand technical details (DAG failures, data anomalies, SQL errors)
Skip unnecessary triage steps because I was already the one who could resolve the issue
Recognise patterns and recutting bugs early thanks to hands on involvement Immediately access and understand technical details (DAG failures, data anomalies, SQL errors) Skip unnecessary triage steps because I was already the one who could resolve the issue Recognise patterns and recutting bugs early thanks to hands on involvement One practical example: a client reported inconsistent metrics. I've checked Airflow DAGs and found a delay. The issue has been fixed within 10 minutes. No escalations, no long explanations of what has happened. We followed up with a monitoring improvement to catch this in the future. Results and impact Results and impact This approach helped the company: Reduce time to resolution dramatically from multiple handoffs to one direct flow
Prevent future issues by giving feedback directly from support to other teams
Lower amount of tickets by proactively fixing root causes and improving monitoring Reduce time to resolution dramatically from multiple handoffs to one direct flow Prevent future issues by giving feedback directly from support to other teams Lower amount of tickets by proactively fixing root causes and improving monitoring Over time, I became the go to person for BigQuery related problems and client escalations not just within support but across product and engineering. Now, company decided to apply the same approach to new Snowlfake based products. Key points Key points Support is not just about fixing things, it's about understanding systems deeply
Technical ownership in support leads to better processes, better tools, and better customer experience
You do not need a large team to build real value. One person if placed in the right role can create significant impact Support is not just about fixing things, it's about understanding systems deeply Technical ownership in support leads to better processes, better tools, and better customer experience You do not need a large team to build real value. One person if placed in the right role can create significant impact Advice for others Advice for others If you are in support and want to go deeper technically: Develop your soft skills to master your communication
Do not afraid to take ownership of L2 investigation
Build your own monitoring even if it's basic. Alerts save hours
Share your findings, your experience can improve the product Develop your soft skills to master your communication Do not afraid to take ownership of L2 investigation Build your own monitoring even if it's basic. Alerts save hours Share your findings, your experience can improve the product In the result: Being both L1 and L2 helped me to grow faster as a technical professional and deliver better service to clients. It gave me a clear view or real product challenges and helped engineering teams close the loop. In the result: Technical support is not about outside engineering, it's where engineering meets reality. And sometimes the best way to solve a problem is to stay close to it from start to finish.

One Engineer, One Ticket, No Escalations: Rethinking the Support Model

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

We Lost Millions of Records: Here's How I Caught It, Fixed It, and Built a Monitoring System in One

We Lost Millions of Records: Here's How I Caught It, Fixed It, and Built a Monitoring System in One

For Best Results with LLMs, Use JSON Prompt Outputs

10 Minute Guide to Fixing Damaged SQL Databases - No Recovery Required!

10 Free Resources to Become a Health Data Scientist

We Lost Millions of Records: Here's How I Caught It, Fixed It, and Built a Monitoring System in One

We Lost Millions of Records: Here's How I Caught It, Fixed It, and Built a Monitoring System in One

For Best Results with LLMs, Use JSON Prompt Outputs

10 Minute Guide to Fixing Damaged SQL Databases - No Recovery Required!

10 Free Resources to Become a Health Data Scientist

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps