Connected Email case study

01 · What had failed

The first version stopped before the work was actually done.

The original feature helped dispatchers create an email from DAT so they didn't have to copy and paste load deatils, but they still had to leave the product to finish and send it. That extra handoff made the feature easy to ignore, and early usage showed it wasn’t gaining traction.

Low adoption Less than 20 people continued through to their email. The feature wasn't becoming part of their workflow.

Extra handoff Users still had to leave DAT to finish the task. We initially thought this would work because our Mobile app did this. But our web users were moving at a rapid speed compared to our mobile users.

Business question Was email worth investing in, or was the idea itself wrong?

Previous Connected Email flow showing users starting in DAT One, creating an email, then moving to their email provider to send it — The original flow. DAT helped create the message, but users still had to leave the product and finish the job in their email provider.

02 · The problem we had missed

The problem wasn't copy and paste. It was context switching.

Paid plugins worked because they pulled load details into an email and let dispatchers act quickly. When I talked with dispatchers and watched how they worked, the pattern was clear. One person could be managing 7 to 13 trucks while jumping between DAT, email, spreadsheets, broker boards and phone calls. If email was going to be useful, it needed to remove one of those jumps instead of adding another.

Dispatcher working across multiple screens

Dispatcher workstation observed during research

Multiple tools open across a dispatcher workstation

Dispatcher managing work across several screens

Dispatcher workstation from field research

Workflow map showing a dispatcher managing several trucks at the same time

Watching dispatchers work made the problem much easier to see. Multiple screens, multiple tools and several trucks were all competing for attention.

Research that informed the rebuild

01 10 virtual interviews

02 45 in-person sit downs across 21 companies

03 7 to 13 trucks managed per dispatcher

03 · Changing the constraint

Instead of improving the workaround, I questioned why we needed it.

The first feature had been built around the assumption that users would have to leave DAT to send the email because of security concerns. Instead of polishing that handoff, we brought the problem back to security and backend engineering. Together we found a secure way to connect Gmail and Outlook so users could send from their own account without extra steps.

Once we knew a direct connection was possible, the question became how to make it fast without creating new trust or security problems. We focused on three things: who the email could go to, who actually sent it and how much work DAT could remove for the dispatcher.

Trust and safety

Verified broker email

The email could only go to the verified broker address tied to the load, which helped reduce fraud risk.

User ownership

User’s own account

Gmail or Outlook sent the message through the connected account. DAT did not need to read or store the user’s email content.

Less repeat work

Load details included

Broker and load details were filled in automatically, so users did not have to choose a template or copy and paste the information themselves.

New Connected Email flow showing dispatchers connecting Gmail or Outlook and sending an email from DAT One without leaving the product — The new flow. Connecting Gmail or Outlook removed the handoff, so dispatchers could go from finding a load to sending the email without leaving DAT One.

04 · What we built

A connected flow, built quickly with design and engineering working side by side.

I gave the front-end engineers a small set of key screens, interaction guidance and the design rules that mattered most. They used Claude Code to build out the experience, and we worked in tight loops with frequent check-ins, design reviews and pull request feedback to make sure the final experience still matched the intent.

Connected Email screen for connecting Gmail or Outlook — Connect the account. Users connected Gmail or Outlook once before sending from DAT One.

DAT One load search with the option to start an email to the broker — Start from the load. Email became part of the load-search workflow instead of a separate task.

Connected Email review screen with broker and load information filled in — Review before sending. Broker and load information were already filled in while the dispatcher kept control of the final message.

Confirmation that the Connected Email message was sent successfully — Send without leaving DAT. The full task could finally be completed inside the dispatcher’s existing workflow.

How we moved fast

Design direction first, then tight build-and-review loops.

Instead of fully designing every state before engineering started, I gave the front-end team the core screens and interaction guidelines they needed to move. They used Claude Code to build quickly, while I stayed involved through frequent check-ins and pull request reviews to catch visual and interaction issues as the experience came together.

05 · What happened

The feature went from barely used to thousands of sends.

The first version had only 11 sends. After connecting Gmail and Outlook directly to DAT One, users sent more than 10,000 emails in the first few days. We also added an in-product CSAT, which resulted in a 4.2, and gave us the evidence we needed that email was worth continuing to invest in.

Adoption

11 → 10,000+

Emails sent from the old experience compared with the first days after the new updates.

Customer satisfaction

4.2 CSAT

Using AppCues, an in-product pop-up feature that let us connect to users with no development work, showed users had high satisfaction with the new feature.

Business validation

Worth investing in

The overwhelming success of the launch gave us the evidence that connected email was solving a real world problem and was worth continuning to build on.

06 · What came next

Once the core workflow worked, users started asking for more.

The feedback changed after launch. Instead of struggling with the basic flow, users were asking for ways to make email faster and more useful for the way they already worked. That gave us a much clearer direction for what should come next.

Personalization

Better signatures

Users wanted richer signatures with logos, images and the details they normally included in broker emails.

Repeat work

Reusable templates

Dispatchers often sent similar messages throughout the day and wanted a faster way to reuse them.

More control

Richer editing

Users wanted more flexibility to format and adjust the email before sending it.

Phase 2 Connected Email concepts showing richer signatures, templates and expanded email controls — Exploring the next phase. The next concepts focused on the improvements users were asking for after the core connected-email workflow proved useful.

07 · Leasons Learned

The first version technically worked. The second version worked with the way dispatchers actually worked.

This project reminded me that a workflow can make sense on paper and still be wrong for the people using it. The biggest change didn’t come from polishing the original idea. It came from watching dispatchers work, questioning a constraint we had accepted and working closely with engineering to try something better. Once we removed the tool switching, the difference showed up almost immediately in how people used it.