Send personalized bulk emails through Outlook without touching SMTP, credentials, or any third-party API. One HTML file. One Python script. Done.

The Problem

Every few weeks, my team needs to send personalized reports to dozens of recipients — coders, clients, ops contacts. The data lives in Excel. The emails need to be personalized per row. And IT won't let us touch external SMTP relays.

PowerShell scripts felt fragile. Outlook mail-merge is clunky. Paid tools require subscriptions and data sharing agreements nobody wants to sign.

So I built my own: a single-file HTML tool that reads an Excel/CSV, lets you map columns, compose a templated email, and then generates a ready-to-run Python script that drives Classic Outlook via COM automation — no credentials, no API keys, no third-party services.

What It Does

The tool walks you through 5 steps:

1. Upload your Excel or CSV file (.xlsx, .xls, .csv)

2. Set the header row — click any row in the preview to mark it

3. Map columns — pick which column is "To", which are "CC", "BCC", and which data columns to include

4. Compose the email — subject, body, signature, with {ColumnName} placeholder support

5. Preview & Send — download a Python script, run it, and Outlook does the rest

The Tech Stack (Surprisingly Minimal)

The entire frontend is one self-contained HTML file. No build step, no bundler, no React. It runs locally in any browser.

The Core Idea: Generate, Don't Send

The browser cannot send emails directly — and honestly, you wouldn't want it to. Instead, the tool generates a Python script that:

1. Decodes a base64-encoded JSON blob embedded inside it (containing all email data)

2. Connects to Classic Outlook via win32com.client

3. Loops through each email item, builds the message, optionally attaches files, and either .Display()s it for review or .Send()s it automatically

ol = win32com.client.Dispatch("Outlook.Application")
mail = ol.CreateItem(0)   # 0 = olMailItem
mail.To = itm['to']
mail.Subject = itm['subj']
mail.HTMLBody = itm['html']
mail.Attachments.Add(tmp_path)
mail.Display(False)   # or mail.Send()

This means no SMTP credentials, no OAuth tokens, no app passwords. Outlook is already signed in — we just drive it programmatically.

Template Variables

One of my favorite features: {ColumnName} placeholders anywhere in the subject or body.

If your spreadsheet has columns like FirstName, Department, ReportMonth, you can write:

Subject: Your {ReportMonth} Report, {FirstName}

Body:
Dear {FirstName},

Please find your {Department} performance summary below.

Each email is personalized per row — zero manual copy-paste.

The replacement logic is dead simple:

function tmpl(tpl, row) {
  return tpl.replace(/\{([^}]+)\}/g, (_, key) => {
    const idx = headers.findIndex(h => h.toLowerCase() === key.toLowerCase());
    return idx >= 0 ? String(row[idx] ?? '') : '{' + key + '}';
  });
}

Case-insensitive matching so {firstName} and {FirstName} both work.

Handling Duplicate Recipients

When the same email address appears in multiple rows, the tool detects it and asks you how to handle it:

• Group by recipient — combine all their rows into one email with a multi-row table

• Send separate — one email per row, even if the address repeats

This was a real pain point in older scripts. A finance analyst might appear 3 times in a report (different projects) — do they get 3 emails or 1? Now the user decides.

Attachment Formats

The tool supports 6 delivery formats:

For Excel attachments, openpyxl handles the formatting — navy headers, alternating row fills, auto-fitted column widths (capped at 50 chars).

Two Send Modes

Before running the script, you pick a mode:

Display in Outlook — opens each compose window for your review. You click Send yourself. Great for the first run.

Auto-Send — fires everything automatically. Use this after you've verified the output with a test email.

There's also a Test Email button that generates a separate test_email.py script using only the first data row, sent to a test address of your choice.

Setup (One-Time)

pip install pywin32 openpyxl
python -m pywin32_postinstall -install

That's it. After that, every use is:

1. Open the HTML file in your browser

2. Upload your spreadsheet

3. Configure and compose

4. Download the .py script

5. Run python send_emails.py

What I'd Add Next

• Sheet selector — currently uses the first sheet; a dropdown for multi-sheet workbooks would help

• Scheduling — integrate with Windows Task Scheduler or a simple delay mechanism

• Preview pane — render a live HTML preview of the generated email inside the browser before downloading

• Progress UI — the Python script logs to console; a GUI progress bar (even a simple tkinter one) would be nicer for non-technical users

Final Thoughts

This tool started as a weekend script and became something my whole operations team now uses. The key insight was: don't fight the constraints. Classic Outlook is already there, already authenticated, already trusted by IT. COM automation is old but rock-solid. Lean into it.

The entire UI in one HTML file means zero deployment headaches. Drop it on a shared drive and anyone on Windows with Python installed can use it.

If you're in ops, reporting, or any role that sends personalized bulk emails from spreadsheet data, give it a try.

Built with SheetJS, pywin32, and openpyxl. Runs on Windows with Classic Outlook.

Tags: python automation excel outlook productivity no-code

What the Dashboard Needed to Show

Before touching Power BI, I listed out exactly what the team needed to see each day:

1. Each coder's CPH for the day — compared against their individual target

2. Which coders are above, at, or below target — at a glance, no scrolling

3. Total team productivity — rolled up to a single number for management

4. Client-level breakdown — which clients are producing well, which are lagging

5. Trend over the past 30 days — to separate a bad day from a bad pattern

Every visual and every measure I built traces back to one of those five needs.

Data Sources

The dashboard pulls from three main sources:

The target lookup table is the most critical piece. Without it, you can show activity but you cannot show performance. I maintain this as a separate table in the data model with defined relationships.

Data Model Structure

The model follows a simple star schema:

FactProduction (daily grain)
    → DimCoder (one row per coder)
    → DimClient (one row per client)
    → DimDate (standard date table)
    → DimTargetLookup (CPH targets by client + level + claim type)

One important design decision: DimTargetLookup connects to FactProduction through a bridge using both Client and Coder Level as match keys — not a single foreign key. This required a calculated column in the fact table to create a composite key for the relationship.

Key DAX Measures

Here are the core measures that drive the dashboard.

1. Actual CPH

Actual CPH = 
DIVIDE(
    SUM(FactProduction[CodesCompleted]),
    SUM(FactProduction[ProductiveHours]),
    0
)

Simple — but note we use ProductiveHours, not total shift hours. This excludes training time, system downtime, and breaks.

2. Chart Target CPH (Range-Based Lookup)

This is the most complex measure. It needs to find the right target from the lookup table based on the current filter context (which client, which coder level):

Chart Target CPH = 
CALCULATE(
    AVERAGE(DimTargetLookup[TargetCPH]),
    TREATAS(
        VALUES(DimCoder[CoderLevel]),
        DimTargetLookup[CoderLevel]
    ),
    TREATAS(
        VALUES(DimClient[ClientName]),
        DimTargetLookup[ClientName]
    )
)

Watch out: If your client names in DimClient don't exactly match those in DimTargetLookup, this measure returns blank — silently. Always audit your client name lists before publishing the report.

3. CPH vs Target (Variance)

CPH Variance = [Actual CPH] - [Chart Target CPH]

4. Performance Status

This drives the conditional formatting — green, amber, or red for each coder row:

Performance Status = 
VAR ActualCPH = [Actual CPH]
VAR TargetCPH = [Chart Target CPH]
VAR FloorCPH  = [Chart Floor CPH]
RETURN
    SWITCH(
        TRUE(),
        ISBLANK(TargetCPH),        "No Target",
        ActualCPH >= TargetCPH,    "On Target",
        ActualCPH >= FloorCPH,     "Below Target",
        "Below Floor"
    )

This gives you three meaningful states — not just a pass/fail binary.

5. Weighted Team CPH

Rolling up individual CPH to a team total requires weighting by hours, not a simple average:

Weighted Team CPH = 
DIVIDE(
    SUMX(
        VALUES(DimCoder[CoderID]),
        [Actual CPH] * CALCULATE(SUM(FactProduction[ProductiveHours]))
    ),
    SUM(FactProduction[ProductiveHours]),
    0
)

A simple AVERAGE of individual CPH figures would overweight coders who worked fewer hours. This measure gives you the correct team-level productivity number.

Dashboard Layout

I kept the layout to three pages:

Page 1 — Daily Summary

• KPI cards: Team CPH, Total Codes, Hours Logged

• Table: Each coder, their CPH, target, variance, and status (colour-coded)

• Slicer: Date (defaults to today), Client

Page 2 — Client Deep Dive

• Bar chart: CPH by client vs. target line

• Table: Coder-level breakdown within each client

Page 3 — 30-Day Trend

• Line chart: Daily team CPH vs. target over rolling 30 days

• Scatter: Coder performance consistency (average CPH vs. variance)

Things That Tripped Me Up

Client Name Mismatches

As mentioned — "Network Health" vs "NetworkHealth" will silently break your target lookups. I now run a data quality check as part of the refresh process.

Wellmed NLP Anomaly

Wellmed uses NLP-assisted coding, which produces much higher CPH numbers. When I first built the dashboard, Wellmed coders were showing as massively over-target — not because they were exceptional, but because the NLP target hadn't been set correctly. Always maintain a separate target row for NLP-assisted clients.

Blank Dates Breaking the Date Table

If your production extract has rows with null dates (e.g., records still being processed), those rows fall outside your DimDate table and disappear from all date-filtered visuals. Add a data cleaning step to handle nulls before the data hits your model.

The Outcome

Once live, the dashboard cut our daily reporting time from about 45 minutes of manual Excel work to zero. Managers open it each morning, see the colour-coded coder table, and immediately know where to focus their attention.

It also changed the conversation in team meetings — instead of debating whether someone was performing well, we had a shared, objective reference point that everyone trusted.

What's Next

In a future post, I'll cover how we added a 30-day rolling productivity trend with DAX time intelligence functions, and how we set up row-level security so each team lead only sees their own coders.

Built using Power BI Desktop, with a SQL Server production extract and a manually maintained Excel target lookup table imported as a flat file.

#powerbi #dax #medicalcoding #dataanalytics #businessintelligence #reporting