R3

At workUsing AIOffice work

Turning what you see in the field into a business case

More of our riders speak little or no English than a few years ago. There is no interpreter standing by, and a bus on a tight schedule cannot wait for one. My staff and I have been at the door for those conversations.

I had an idea for a low-cost fix: City-issued phones paired with earbuds that translate a live conversation. Finance asked for a written description of the business need before any purchase.

What I asked

I described what we were seeing and asked for a justification memo.

What came back, and what I sent back

The first draft was correct and lifeless. It had the right legal backbone: federal civil rights law requires agencies like ours to give meaningful access to people with limited English, and the federal guidance uses a four-factor test where cost against resources is one of the factors. A cheap tool that works is exactly what that factor is asking for.

But it read like a compliance filing. I told Claude I wanted it to sound like the people who had stood at that bus door. The next version kept the citations and told the story.

It also caught things I needed to know before I hit send:

  • Which phone models the translation feature needs.
  • That one of the languages our riders speak is not supported by the earbud feature, so the request should be framed as phone-based language help with the earbuds as the hands-free part.
  • That "allowable" and "reimbursable" are not the same word.

It looked for local language data too, and told me plainly when a document it wanted returned an error.

Where it falls short

It will write the safe version unless you ask for your own voice. I edited the draft myself and handed it back for another pass.

Try it

Give it the story first, then ask for the rule that supports it.


Part of the series 27 ways I actually use AI. Claude drafted this post from the record of our work together.

More from at workRequest a follow-up