Automating the Analyst Workflow: What to Script First

Automate in payback order: frequency times minutes per run times error-proneness. For most analysts that puts the environment health check first, then test data setup, a daily reconciliation query, contract validation in CI, and evidence gathering for support tickets. Automate the check, never the judgment.

The right first automation for an analyst is not the most technically interesting one, it is the one with the highest payback score: how often you do it, multiplied by how many minutes it takes, multiplied by how easy it is to get wrong by hand. Score your repeated tasks that way and the same five rise to the top for almost every analyst on a delivery team: the environment health check, test data setup, a daily reconciliation query, contract validation wired into the build, and evidence gathering when a support ticket lands. All five are checks. None of them make a decision.

The reason I am insistent about the ordering is that I have watched analysts spend three weeks building an elegant automated report nobody reads, while continuing to spend twenty minutes every single morning manually poking a test environment to find out whether it is up. The second task is worth roughly 80 hours a year and the first is worth nothing. Automation is a payback exercise, not a craft exhibition. If you need the scripting foundation first, scripting checks in Python is the prerequisite, and the wider technical base is mapped in The Technical Skills Guide for BAs.

How do you decide what to automate?

Score every repeated task on three factors and multiply.

Frequency. Runs per week. Daily beats quarterly by a factor of twenty, which is why the unglamorous morning check wins.

Minutes. How long the manual version takes, honestly measured including the context switching, not the optimistic version.

Error-proneness. How often the manual version goes wrong or gets skipped. A five-minute task you skip under pressure and that causes a bad test result when skipped scores higher than its five minutes suggest.

Here is the ranking that comes out for a typical analyst on a payments delivery team:

Task	Frequency	Minutes	Error-prone	Score
Environment health check	Daily	15	High	Highest
Test data setup for a scenario	3 per week	25	High	High
Daily reconciliation count check	Daily	10	Medium	High
Contract validation after a release	Weekly	20	High	Medium
Evidence gathering for a ticket	4 per week	12	Medium	Medium
Status report assembly	Weekly	30	Low	Low
Quarterly metrics pack	Quarterly	180	Low	Lowest

Notice the status report near the bottom. It feels automatable and it is, but weekly times thirty minutes with low error risk is a fraction of the payback of the daily check, and it is the one people reach for first because the output is visible to management. Resist that.

Automation 1: The environment health check

The task: every morning, before anyone raises “the environment is broken,” you determine whether it actually is. By hand that means calling three endpoints, checking two queue depths, querying whether last night’s batch loaded, and confirming the downstream stub is responding.

The script does the same sequence and prints one screen of pass and fail lines. Ten to twenty minutes becomes fifteen seconds, and the output is something you can paste into the team channel at 8:45 so four other people do not each rediscover the outage independently.

import requests, psycopg2

CHECKS = []

def check(name, fn):
    try:
        ok, detail = fn()
    except Exception as e:
        ok, detail = False, f"{type(e).__name__}: {e}"
    CHECKS.append((name, ok, detail))

def api_up():
    r = requests.get(f"{BASE}/health", timeout=5)
    return r.status_code == 200, f"HTTP {r.status_code}"

def batch_loaded():
    cur.execute("""
        select count(*) from payments
        where created_at >= current_date
    """)
    n = cur.fetchone()[0]
    return n > 0, f"{n} rows today"

check("payments api", api_up)
check("overnight batch", batch_loaded)

for name, ok, detail in CHECKS:
    print(f"[{'PASS' if ok else 'FAIL'}] {name}: {detail}")

Two design points worth copying. Every check is wrapped so one failure does not abort the rest, because a health check that stops at the first problem hides the other three. And every check prints its detail even when it passes, because “PASS, 0 rows today” is exactly the kind of result a bare green tick would let you miss.

Automation 2: Test data setup

The task: before running a scenario you need the system in a specific state. A customer exists, with a specific limit, holding a specific balance, with one payment already in REPAIR status. Building that by hand through a user interface takes twenty five minutes and is where half of all “the test failed” reports actually come from.

Script it as a setup function per scenario, calling the same APIs a user would, returning the identifiers it created. Then your test starts from a known state every time, and a failed test means a real defect instead of a data mistake.

def setup_repair_scenario():
    customer = post("/customers", {"name": "TEST_REPAIR_01",
                                   "limit": 50000})
    payment = post("/payments", {"customer": customer["id"],
                                 "amount": 1200,
                                 "creditor_iban": "INVALID"})
    wait_for_status(payment["id"], "REPAIR", timeout=30)
    return {"customer": customer["id"], "payment": payment["id"]}

The wait_for_status helper matters more than it looks. Asynchronous systems reach the state you need some unpredictable number of seconds later, and the alternative that analysts default to, a fixed sleep, is the single largest source of flaky test results I have seen. Poll for the state with a timeout, and your setup is deterministic. The full pattern for validating asynchronous event flows this way is what I documented in Automate Kafka Validation with Postman, and the conceptual background is in synchronous vs asynchronous.

Automation 3: The daily reconciliation check

The task: confirm two systems still agree. Count and sum what the payment engine says settled yesterday, count and sum what the ledger recorded, and report the difference.

This one is a ten-minute query pair you run every morning until the day you get busy and stop, which is reliably the week a break appears and goes unnoticed for nine days. Automated, it takes a second and it never gets skipped.

select 'engine' as source, count(*) as n, sum(amount) as total
from engine_settlements where value_date = current_date - 1
union all
select 'ledger', count(*), sum(amount)
from ledger_entries where value_date = current_date - 1
  and entry_type = 'SETTLEMENT';

The critical rule, and the one I would put on a wall: the script reports the break, it does not judge the break. Materiality is a business decision with accounting and regulatory weight. A script that decides a 3 cent difference is immaterial and suppresses it will eventually suppress a 3 million difference caused by a unit error, and the analyst who wrote the suppression rule owns that. Detect, report, escalate to a human. The design principles behind a reconciliation that is actually provable are in reconciliation design.

Automation 4: Contract validation in the build

The task: catch the moment a provider changes a contract in a way that breaks your consumer, before it reaches an environment.

This is the automation with the best ratio of effort to avoided pain, because the failure it prevents is the expensive kind: a breaking change discovered in integration testing, three weeks after it shipped, by a tester who spends two days proving it is not their fault. A validation step in continuous integration that fetches the provider’s current specification and asserts the fields and enumerations your consumer depends on still exist turns that into a red build on the day of the change.

The step is small. Fetch the specification, assert the presence and type of the elements you consume, assert the enumeration values you switch on, and fail the build with a readable message naming the field that moved. What makes it work is that it runs without a human deciding to run it. The collection and runner side of this, whether you keep your requests in Bruno or Postman, is compared in Bruno vs Postman for analysts. The discipline behind it is contract testing, and reading the specifications well enough to know what to assert is reading an API contract. If the documentation side of that is your gap, API Documentation from Scratch covers it.

Automation 5: Evidence gathering for a support ticket

The task: a ticket arrives referencing one transaction. You need the payment record, its status history, the events published, the log lines from three services, and the downstream response. By hand it is twelve minutes of copying between four tools, done four times a week, under time pressure, which is exactly the combination that produces incomplete tickets.

Script it as a single function taking a transaction reference and printing a bundle: the database rows, the status transitions in order, the matching log lines, and the outbound message. One command, one paste into the ticket, complete evidence every time.

This also composes neatly with AI. The bundle is grounded, machine-generated evidence, which is precisely what a language model needs to produce a first-draft timeline narrative. That pairing, deterministic script for the evidence and a model for the summary, is the most useful AI plus automation combination I use, and it is one of the flows in the AI-augmented analyst workflow. The manual investigation skill underneath it stays mandatory, because it is how you notice when the summary is wrong: see how a technical BA investigates a failed payment.

What should analysts never automate?

The boundary is simple and it holds everywhere: automate the check, never the judgment.

Automate detection, evidence gathering, comparison, setup, and reporting. Do not automate materiality assessment, approval, prioritization, closing an incident, resolving conflicting requirements, or anything that writes to production data. The asymmetry is what justifies the rule. A detection script that is wrong costs you a false alarm and five minutes. A judgment script that is wrong hides a real problem for as long as the team trusts it, which is usually until an auditor or a customer finds it instead.

How do you keep automation from rotting?

Every script needs three things, and the third is the one people skip.

An owner. A named human who fixes it when it breaks. Unowned automation becomes unmaintained automation within one team reorganization.

A loud failure mode. The worst outcome in this entire article is a health check that broke two weeks ago, has been printing PASS on an empty result set ever since, and has quietly replaced the manual check the team used to do. Make scripts fail visibly, and make a check that cannot reach its source report ERROR rather than PASS.

Readable output. A colleague who has never seen the code should understand the result. Label every line, print the detail, and state what was checked. Output nobody can interpret is output nobody will act on.

The tracker side of this list deserves its own mention, because generating a traceability matrix or publishing a status page straight from the Jira and Confluence REST APIs is the one write-capable automation most analysts end up wanting: the working scripts and the safety rules are in automating Jira and Confluence with the REST API.

Keep them in version control next to your notes, with a short README per script saying what it checks and, importantly, what it does not check. That last line prevents the most common misuse: a colleague assuming the health check covers a system it never looked at. Version control, README, and owner together are why git for analysts is not an optional skill once you start automating.

The takeaway

Rank your repeated tasks by frequency times minutes times error-proneness, and automate from the top. For most analysts that order is environment health check, test data setup, daily reconciliation count, contract validation in the build, and evidence gathering for tickets. Every one is a check, every one reports to a human, and none of them make a judgment call.

Pick the daily one, spend an afternoon, and keep the script in git with your name on it. If you want the scripting and validation patterns with real payments examples, they are in Automate Kafka Validation with Postman and The Technical Skills Guide for BAs, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Automation, Python, Software Testing, Productivity