Joe OviedoIn late July, on a call about a platform we were building, several improvements came up: how to follow up on sessions, what notifications to send, and where someone should report a technical issue. In the middle of that list was a smaller idea: a button in the user's account to request an invoice.
I liked how easy it was to explain who would use it and why. Someone had already paid and needed an invoice. They shouldn't have to work out whom to email.
We decided to add the button. The part we still had to figure out was what would happen after someone pressed it.
The button is the easy part to draw
Imagine you've paid. You open your account, find the charge, and click “Request invoice.” Does the system know which payment you mean? Does it need information it doesn't have yet? Does it confirm the request came through? Can someone on the team see and handle it?
If those questions are unresolved, you may end up with a button that opens a blank email. At least you know where to write. But you still have to explain which payment you mean, and someone on the other end has to look it up.
I'd try to attach the request to the payment. If the system already knows which charge it is, I wouldn't ask the person to copy a reference number or attach a screenshot. I'd ask only for the information still needed to process it. And I'd confirm only what has actually happened: “We received your request,” if that's all we can say yet.
What I'd leave manual in the first version
For a first version, I'd be happy if people could make the request without chasing anyone and the team received enough context to handle it. Review and issuance can stay manual while we see what kinds of requests come in.
That helps me learn what deserves automation. Maybe finding the payment was the slow part. Maybe it was getting a detail that always seemed to be missing. Or the repetitive work might begin after all of that. If I automate issuance before I understand the process, I could spend time on the wrong problem.
I'd treat exceptions the same way. If someone needs to correct their details or can't find the payment, there should be a clear way to get help. The first version doesn't have to solve every case; it does have to know what to do with the ones it can't handle.
What I'd look at once it's in use
I'd follow a few requests from start to finish. Did people find the button? Could the team handle requests without asking for the same information again? Did anyone write back because they didn't know what had happened?
Those questions help me tell the difference between adding an option to an account page and solving a problem. They also suggest what to build next. Sometimes a detail is missing. Sometimes it's a confirmation. Sometimes the flow is fine and it's time to leave it alone.
I left that call with a question I can use to review other support tasks: What are we asking someone to explain that the system already knows? That's usually a good place to start.
← Back to the Journal