Northwind Relay

• 

• 

• 

• 

• 

• 

Inspiration

Northwind Utilities asked for an AI-powered complaint triage and response solution. But after reviewing the supplied complaint, meter, staffing, systems, KPI, cost, and previous AI pilot data, we found that the bigger issue was operational.

Billing and metering represented the largest concentration of complaints, complaint handoffs were associated with much longer resolution times, and Northwind was opening more cases than it was closing.

Instead of adding another layer on top of those problems, we built Northwind Resolve around three ideas: prevent avoidable complaints, make the complaints that remain easier to execute across systems, and give operations a way to actively reduce the backlog.

What it does

Northwind Resolve has three core operational capabilities:

Prevent identifies transparent meter-to-bill exception conditions that should be reviewed before they become customer complaints. It does not assume that a flagged bill is incorrect; it gives an operator the evidence and actions needed to review it.

Relay manages complaints across fragmented systems while preserving the full case context and a single accountable owner. Handoffs require acknowledgement, failures do not silently transfer ownership, retries are safe, duplicate actions are prevented, and every step is recorded in an audit history.

Relay also provides deterministic customer updates during meaningful workflow changes so customers are not left calling simply to ask for the status of their case.

Recovery gives operations a view of the inherited complaint backlog, including blocked work, overdue cases, work awaiting acknowledgement, operational queues, and the recovery pace required to reduce the backlog.

Together, the model is simple:

Prevent what we can → Relay what remains → Recover the backlog.

How we built it

We first analyzed the supplied Northwind datasets and independently checked the calculations and assumptions used in our recommendation.

The application was then built as a working operational prototype using a typed web application architecture with explicit domain logic for cases, ownership, handoffs, notifications, prevention events, recovery planning, and audit history.

External Northwind systems are represented through adapters rather than pretending that production integrations already exist. This allowed us to demonstrate realistic failure, retry, acknowledgement, and reconciliation behavior without inventing access to systems that were not actually provided.

The final prototype includes deterministic demo data and reset functionality so every workflow can be reproduced consistently.

Challenges we ran into

The biggest challenge was separating symptoms from causes.

A large backlog does not automatically tell us why complaints are being created or why they take longer to resolve. We had to distinguish complaint generation, handoff friction, staffing pressure, and capacity constraints without claiming that correlation proved causation.

We also had to work with different levels of data freshness. For example, Northwind's refreshed aggregate reports a backlog of 1,758 cases while the supplied detailed open-case ledger represents 1,599. Instead of fabricating the missing 159 records, the application exposes that reconciliation boundary directly.

Another challenge was making the prototype reliable enough for a live demonstration. The final system includes failure handling, idempotency, duplicate protection, persistent state, deterministic demo dates, customer notification safeguards, and a global reset.

Accomplishments that we're proud of

We challenged the original brief instead of forcing technology onto the problem.

The final solution is a working operational product rather than slides describing what a future product might do.

The prototype can demonstrate a meter/billing issue being caught before a complaint, a complaint safely surviving a downstream system failure and retry, customer updates tied to real workflow events, and an operational recovery view for the current backlog.

The final implementation passes 108 automated tests along with lint, type checking, production build, and browser runtime validation.

What we learned

The biggest lesson was that the most visible problem is not always the root problem.

Northwind's complaint backlog is a symptom of both complaint generation and the organization's ability to process incoming work. Improving only the customer-facing response would not address those underlying operational issues.

We also learned how important it is to distinguish observed evidence from assumptions. Several of our financial and prevention figures are deliberately presented as conditional planning scenarios rather than guaranteed outcomes.

What's next for Northwind Resolve

The first step would be a controlled 90-day operational pilot.

We would reconcile the current backlog, instrument the relevant queues and handoffs, pilot the meter-to-bill prevention workflow, deploy Relay across one real integration path, and establish clear Recovery ownership.

The next phase would measure actual prevention rates, handoff performance, closure capacity, repeat customer contact, and operational cost before scaling anything further.

Longer term, Northwind Resolve could expand prevention to additional complaint sources and integrate additional Northwind systems as their real interfaces, permissions, and data contracts are validated.

Built With

• next.js
• node.js
• react
• tailwind-css
• typescript
• vitest