What a data analyst does: from a business question to a decision

Someone says they need a dashboard. My first question would be what they intend to do differently once it exists. Change staffing? Adjust a process? Review unresolved support tickets? Their answer influences the data I need and whether a dashboard is the appropriate output in the first place. The requested object is the beginning of a conversation.

That is how I would explain the work of a data analyst. I use tools, but I also need to establish the question, inspect the evidence and guide the recipient through a result. A technically correct query can answer the wrong problem. An attractive chart that nobody understands or uses has a rather limited social life.

Below, I will work through an illustrative support-ticket task. The scenario, numbers and working day are synthetic. They do not describe a current job or a client engagement. My aim is to show the reasoning and the tangible outputs I would expect at each stage, including the parts that never appear in a screenshot of the final dashboard.

The role extends beyond charting software

Microsoft’s description of a data analyst includes data preparation, modelling, visualisation and collaboration with stakeholders. It is a useful map, written from a Microsoft tooling perspective. I would not treat it as a compulsory software shopping list for every person who wants to work with data in a different organisation.

The O*NET description of business intelligence analysts also includes maintaining reports, documenting requirements and communicating recommendations. When reading a vacancy, I would therefore look for concrete responsibilities. Two positions with the same title can divide their time very differently between exploratory work, recurring reporting and keeping an existing solution usable.

For my own planning, I would distinguish three outputs. A one-off analysis answers a defined question. A recurring report presents an agreed state at regular intervals. A self-service solution lets recipients answer some questions themselves. Each needs a different discussion about maintenance, documentation, checks and who will use it once the original author is elsewhere.

I would also avoid advertising one analyst as an entire data department. A larger solution may require collaboration with a data engineer, an administrator, a domain expert or someone responsible for deployment. An analyst should understand those dependencies and ask for help. Personally rescuing every layer of a system is not a necessary demonstration of professional commitment.

The first conversation: what does slow response mean?

In our scenario, a support leader says that the team responds too slowly. Before opening a dataset, I would ask where the observation came from. Is it a complaint, an isolated incident or a regular measurement? Does it concern the first reply, final resolution, or the time customers wait between later messages in a long conversation?

Next, I would establish the decision. If the leader is considering different opening hours, arrival and waiting patterns matter. If the question concerns training, arrival times alone will not answer it. These questions may use the same database, yet require different analyses and different conversations about what the available evidence can establish.

My proposed starting question would be how long tickets created in a selected week wait for their first human response. I would specify whether the clock includes calendar time or only staffed hours. An automatic acknowledgement would not qualify as a human response in this example. The recipient would need to agree that definition before we use it.

The conversation should leave a short agreement on scope, recipient and timing. I would also state what we are not resolving yet. The first version could describe response-time distributions without evaluating individual employees. That boundary makes it easier to manage additional requests when a task originally due tomorrow morning starts quietly acquiring six new objectives.

Inspect where the information comes from

I would ask for a field dictionary and the ability to trace a few tickets in the source system. We need a ticket identifier, creation time and response history with a distinction between response types. A column called handling time may already contain a calculation whose definition we do not understand. Renaming it does not establish that it measures what we need.

I would check the time zone and how updates are recorded. Are we receiving a full current state, a history of events, or only changes since the last import? Do deleted tickets disappear from exports? Those answers affect whether we can reproduce the same result later or merely inspect the current state of a changing source.

At this point, I would separate availability from usefulness. A table can contain thousands of rows and still lack the field that distinguishes automatic messages from human replies. Data volume cannot replace that distinction. If it is missing, I would explain the limitation and propose a narrower output instead of expecting a more complicated query to invent it.

Questions like these can move a task forward even when the recipient never sees them in the final chart. What they should receive is the consequence: what is measured, what is excluded, and why the evidence deserves a certain level of trust. I consider that part of the analytical output, rather than an optional technical appendix.

Prepare a table for one agreed question

Suppose the first table contains tickets and the second contains messages. A ticket can have many messages. If I simply join the tables and count rows, longer conversations gain more influence. Our unit is still the ticket, so we need one eligible first human response for each ticket rather than a measurement repeated for every message.

I would select the earliest human response that meets the agreed conditions. I would also retain tickets without an eligible response. Dropping them can produce a remarkably attractive report: the people who have waited longest disappear entirely. I explain this type of inspection further in checking bad data before analysis, including why missing information needs an explicit interpretation.

Separately, I would count tickets entering the population and those excluded by each rule. I would inspect cases near the week boundary, an unanswered ticket and a conversation that begins with an automated acknowledgement. This small sample helps us agree the logic. It does not replace checking the relevant full population before publishing the result.

The output at this stage would be a table suitable for the defined measurement and a readable description of its preparation. When someone challenges a number, I want a route back through ticket identifiers to the source. Reassuring them that the calculation is long and contains three nested expressions would not answer their actual concern.

Analysis needs more than a single average

Imagine five resolved observations with first-response times of 5, 10, 15, 20 and 100 minutes. The total is 150 minutes, so the mean is 30 minutes across five tickets. The median is 15 minutes, the middle observation in the ordered group. Both figures are correct, but they highlight different features of the same small sample.

I would show the extreme observation and the sample size too. I would not delete 100 minutes because it makes the chart inconvenient. I want to know whether it reflects a recording error, a different contact channel or genuine waiting. When a single case has a large influence on a small group, that deserves attention before we generalise.

Next, I would compare groups that relate to the decision, such as creation hour and channel. The EDA approach described by NIST encourages examining structure and anomalies before accepting a ready-made story. In our scenario, I would not begin by assuming that a particular team or a lack of training is responsible.

Every split also needs its group size. One excellent night-shift observation cannot support a broad comparison with a hundred daytime tickets. Ticket types matter as well. If complex complaints go to one queue and simple questions to another, different averages may describe the allocation of work. They do not, by themselves, establish differences in employee performance.

Findings and recommendations need boundaries

Suppose longer waits cluster among tickets created just after staffed hours end. I can describe that association. I cannot yet establish that hiring another person would solve it. We would need to understand demand, service expectations, shift organisation and the cases that can reasonably wait. Those considerations require a conversation with the people operating the service.

I would suggest a next step proportionate to the evidence: inspect the queue by hour and discuss a possible shift change with the leader. That is a recommendation arising from an observation, with an explicit need for further assessment. I would not label it proof that staffing must change. The chart does not make that decision for us.

In the final material, I would distinguish an observation, an interpretation and an action. The observation describes what the data shows. The interpretation proposes an explanation. The action identifies something the recipient could investigate or change. When all three are compressed into a single confident sentence, a plausible hypothesis can quietly become an alleged fact.

I would explain what could change my assessment. If human replies were incorrectly labelled automatic, the measurement needs correction. If the week included an exceptional outage, we should inspect a longer period. These are useful conditions for the recipient to understand. They indicate how durable the conclusion is and when it should be revisited rather than simply repeated.

How I would communicate the result

I would begin with the answer to the agreed question and the period definition. Then I would show one main chart, the population size and information about unresolved tickets. Technical detail would follow. The recipient should understand the finding without reading every transformation, while still having a way to inspect the preparation when they need to.

During the conversation, I would ask the leader to explain the chart back in their own words. If they interpret a mean of 30 minutes as everyone waiting half an hour, our five very different observations have been communicated poorly. Approval of the slide’s appearance is not the same as shared understanding of what the numbers mean.

I would not present every available breakdown simply because I managed to create it. The material should support the agreed decision. Additional views can help answer questions and explain limitations. Otherwise the recipient receives twenty tabs and a new task: guessing which tab the analyst wanted them to consider most important. More pages do not automatically create more clarity.

Afterwards, I would record the agreement: who takes the next step, what remains to be checked and when we will reassess the situation. Sometimes the decision is to make no immediate change. If we understand why and know which signals would prompt another review, the analysis can still be useful. A report does not need to produce a revolution.

What a day with this task could look like

In an illustrative working day, I would inspect the data update and answers to yesterday’s questions in the morning. A short conversation would settle the definition of a first response. A longer uninterrupted block would go towards preparing the table and examining cases. Later, I would discuss an initial result and finish by updating the definition and unresolved questions.

This is a planning example, rather than a timetable for the profession. Another analyst may spend more time on experiments, and another on maintaining reporting. Team practices differ too. Not everyone uses Scrum, and the existence of a daily meeting does not establish that an entire organisation operates that framework. I would ask how the team actually works.

What matters more than an ideal calendar is the task’s progress. After the conversation, we have an agreed definition. After preparation, we have a table and a population check. After analysis, we know which observations deserve investigation. After presentation, the recipient understands the next step. Each stage should leave something that another person can use or assess.

There are less glamorous duties too: describing a column, fixing a refresh and answering a user’s question. I would not consider them beneath the role. Useful reporting needs maintenance and understandable definitions. If maintenance consumes all available time, I would discuss responsibilities and priorities with the team rather than silently postponing analysis indefinitely and hoping the backlog repairs itself.

What remains after the handover

If the analysis becomes weekly reporting, I would agree who owns the refresh and responds to failures. The recipient also needs a way to recognise stale results. In our example, the latest import time should be visible. Yesterday’s evidence displayed under today’s viewing date can reassure a whole team for entirely the wrong reason.

I would check whether another person could take over while I am away. They need the source, population definition, location of the calculation and a contact for the source system. They do not need to learn every detail immediately. They should be able to establish whether the result is current and report a problem without tracking down the author privately.

A change to the first-response definition would require a decision about historical comparisons. If next month we count only staffed hours, the measure answers a slightly different question. I would identify the change date and agree whether earlier periods should be recalculated. Otherwise a better-looking trend might reflect only a change to the measurement clock.

I would also ask whether people still use the report. If they have stopped, has the decision changed, has confidence fallen, or is there now a better source? Maintaining an unnecessary solution consumes team capacity. An analyst can help simplify or retire it while preserving useful definitions and checking the dependencies that people still rely on.

For this task, I would assess my contribution through the recipient’s ability to act and explain the result. A tab count describes activity more readily than usefulness. After the initial handover, I would return to the leader and ask what they actually used and what remains missing. That conversation can reveal a more valuable next task than another unsolicited dashboard page.

Tools and a first independent project

A spreadsheet can be enough for a small, one-off task. SQL helps when information lives in a database. A BI tool can distribute a recurring view, while Python can support more involved preparation or analysis. I would choose according to the source, scale and intended use. A technology list on a CV does not explain someone’s analytical reasoning.

For a beginner, I would propose a project with a clear recipient and a manageable scope. Use the synthetic tickets from this article, then add an unanswered case and an automatic acknowledgement. Describe the population, show how the mean differs from the median, and finish with one finding plus one question that the dataset cannot resolve. Give the reader a reason to trust your choices.

Include a metric definition and a short explanation of how to reproduce the output. You do not need to build a complete support platform. I want to see why you retained unanswered tickets, what a row represents, and why five times cannot support an employee ranking. These questions reveal understanding that a screenshot of a polished dashboard cannot demonstrate on its own.

If you are considering a specialism, compare this scope with the data analyst career map. Then take one vacancy and write down the outputs it expects someone to own. That gives you a more concrete starting point than trying to learn every tool that happens to fit into a long job advertisement.