If I Had These Capabilities Then: Rethinking an International VAT Refund Journey

Decision Architecture Pathway

Separating contextual assistance from enforceable statutory validation:

1. Interpret Contextual intake & ambient cues

2. Retrieve Targeted statutory policies

3. Explain Minimal guidance for staff / tourist

4. Validate Explicit, audited rule engine

5. Authorized Action Human or certified digital execution

From the tourist's point of view, the story is fairly straightforward: I bought something while travelling, I may be eligible to recover some tax, and I would like the refund.

Behind that sentence sits a much more interesting product problem.

• Eligibility & Residency
• Transaction Information
• Trip & Transit Itinerary
• Country Requirements
• Retail Checkout Staff
• Payment Processing
• Customs Validation
• Settlement & Disbursal

And the awkward fact that some of the information needed later in the journey originates much earlier, often while the tourist is still standing at a retail checkout.

I spent a significant part of my payments experience inside that kind of complexity. What I find interesting now is that this is exactly the sort of workflow where I would be very reluctant to say, "Let's automate it with a model."

There are too many different kinds of decisions hiding inside the process. Some should be flexible. Others absolutely should not be.

The First Job Would Be Separating Interpretation From Enforcement

If I were revisiting this problem now, I would probably begin by drawing a fairly boring diagram. That isn't an insult. Boring diagrams have saved me from a surprising number of exciting mistakes.

I would map the information entering the transaction, identify the points at which a person interprets information, and separate those from places where the business is enforcing a rule. That gives us a clearer place to consider newer capabilities:

• Contextual retrieval could help bring forward the relevant guidance based on country, transaction, and traveller circumstances.
• Generative synthesis might explain why a particular piece of information is required in language appropriate to the merchant or tourist.
• Classification could help route an unusual case toward the right support path.

Those are all interesting. But eligibility itself may involve conditions that should remain explicit and testable. That is where deterministic rules matter.

A Fluent Answer Is Not the Same Thing as a Valid Decision

This is one of the areas where the language we use about these systems matters. A generated response can sound complete. That does not mean the underlying decision has become deterministic.

If a model receives a traveller's context and produces "This person appears eligible," I would want to know what role that statement is playing:

Those are very different product designs. For a consequential financial workflow, I would prefer something closer to:

That may create more steps than the most ambitious automation proposal. I'm comfortable with that. The goal is not to remove as many people as possible from the workflow. The goal is to improve the outcome.

Where I Think Generative Capability Could Genuinely Help

The strongest opportunity may actually be around exceptions. Well-designed systems often become complicated because the common path is relatively easy while the exceptions accumulate around it:

• A merchant receives a document they do not recognize.
• The traveller's itinerary does not fit the expected pattern.
• A required field is missing.
• The customer does not understand why they must complete another step.

Historically, the answer often becomes more rules, more screens, more support documentation, or another escalation queue.

Today I would want to test whether a tightly constrained decision-support capability could help explain the exception, retrieve the appropriate policy material, and recommend the next investigation step. Not complete the decision prepare the person making it.

That is a subtle difference, but I think it could release meaningful value:

• An experienced employee spends less time searching.
• A newer employee gets more context.
• The customer receives a clearer explanation.
• And the organization retains the deterministic controls where consistency matters.

This Is Also a Build-Versus-Buy Question

There would inevitably be vendors claiming they could solve the whole journey. Some probably could solve meaningful parts of it. But before choosing a vendor, I would want to understand which part of the process was actually creating the cost or friction:

That approach is less exciting than buying the promise of "end-to-end intelligence." It is also more likely to tell us what we are paying for. And in a regulated or financially consequential workflow, knowing exactly what you have asked the technology to do seems like a very good place to begin.