AI-assisted utility data workflow for enterprise sustainability teams.
Sustainability managers at a large, growing hospitality franchise were losing weeks each month to manually pulling utility bills from multiple portals into spreadsheets; the hard part was not reading the bills but designing an AI-assisted workflow they could trust when its output feeds carbon reporting.
6 months
Lead UX Designer, sole designer
Sole designer, 0 → 1
An AI-assisted workflow designed for a large hospitality client operating a franchise model. The system extracted utility data and suggested actions. Sustainability managers reviewed and approved. Nothing was autonomous.
Research synthesis
Synthesized findings from existing research on sustainability manager and franchisee workflows
Problem framing
Translated a vague client AI request into a focused design problem: extraction, confidence scoring, and structured human review
Concept exploration
Led concept exploration across multiple automation approaches before committing to the human-in-the-loop model
Confidence states
Designed the three confidence states and the logic for what each tier required from a reviewer
Explanation system
Designed the explanation panel system, including what to surface on every extraction regardless of confidence level
Human-in-the-loop model
Defined the human-in-the-loop model: what the system surfaced, what required a quick check, and what required full verification
Stakeholder recommendation
Developed options and a recommendation for stakeholders on how to balance automation with human accountability
Product screens
Designed all product screens, from the review queue to the dashboard and missing bill monitor
Post-launch validation
Validated the shipped product with users after launch
- Synthesized findings from existing research on sustainability manager and franchisee workflows
- Translated a vague client AI request into a focused design problem: extraction, confidence scoring, and structured human review
- Led concept exploration across multiple automation approaches before committing to the human-in-the-loop model
- Designed the three confidence states and the logic for what each tier required from a reviewer
- Designed the explanation panel system, including what to surface on every extraction regardless of confidence level
- Defined the human-in-the-loop model: what the system surfaced, what required a quick check, and what required full verification
- Developed options and a recommendation for stakeholders on how to balance automation with human accountability
- Designed all product screens, from the review queue to the dashboard and missing bill monitor
- Validated the shipped product with users after launch
- Client sustainability managers
- Franchisees at individual sites
- Client stakeholders
- Internal analysts
- Customer success
- Sustainability SMEs
- PM, engineering
What zero looked like
When I joined this project, there was no product, no design direction, and no automation in place. Sustainability managers and franchisees at a large hospitality client operating a franchise model were spending weeks every month manually downloading utility bills from multiple provider portals, copying consumption data into spreadsheets, and uploading it to the platform by hand. The client's portfolio spanned 500+ properties.
The franchise model made the problem structurally hard. Utility bills came from many different providers across hundreds of independently operated sites. Each site managed its own accounts, used different providers, and submitted documents on different schedules. There was no central view of what had arrived and what was missing. Gaps only surfaced when someone noticed them, usually at month-end, when correcting the problem was most costly.
I was the sole designer on this project. I synthesized findings from existing research on user workflows, framed the design problem, defined the human-in-the-loop model, and designed the confidence state logic, explanation panels, and product screens. I worked with one PM who owned the product roadmap and scoping decisions, two engineers who owned the OCR pipeline and portal integrations, and one data scientist who owned the confidence scoring model.
Two groups shaped this differently. Internal analysts and customer success knew the existing workflow: where data came from, where it broke down, and what was at stake for carbon reporting. They informed the design. Sustainability managers and franchisees were the ones who'd actually use it, and they needed to trust it without becoming experts in how it worked.
The design challenge
Reading utility bills was the easy part. The hard part was trust: sustainability managers are personally accountable for carbon data that flows into ESG reports and regulatory filings. They can't hand that to a black box.
The real question wasn't whether the system could automate data collection. It was how to make sustainability managers trust it with compliance-critical data. Every decision traced back to that.
I don't mind AI doing the tedious work, but I need to understand what it's doing and be able to correct mistakes. Trust is everything with carbon data.
I started from research others had already run, plus conversations with internal SMEs and stakeholders. The takeaway was clear: people didn't just need faster extraction. They needed to know where the data came from, how confident the system was, and what actually needed their attention. That shaped every decision that followed.
Collaboration
A real reaction from the people closest to the client
Situation: Customer success had spent enough time with the client to understand what their monthly utility workflow actually felt like: the manual downloading, the tracking across multiple providers, the missing bills that only showed up as gaps when a carbon report was already due. When I walked them through the end-to-end flow of how a sustainability manager would move through a month's worth of bills, they reacted immediately.
What I did: This was not a formal review. I wanted a read from the people who understood the client's reality, not just the requirements.
What changed: Their response was direct: if their clients used this platform and this process, the experience would be significantly better than what they were doing. That reaction mattered because it came from the people who understood the gap best.
Explanation panels on every extraction, not just flagged ones
Situation: The PM wanted a leaner v1 with explanations only on items queued for review.
What I did: I showed the difference in trust between silent automation and full transparency and framed it as a retention risk: users who could not see the reasoning would stop trusting the queue.
What changed: Explanation panels became core to v1.
Per-field confidence over bill-level scoring
Situation: Engineering scoped confidence at the bill level. I needed per-field scores so reviewers could see exactly which values were uncertain, not just whether a document was flagged.
What I did: I showed how a reviewer working through a 12-field extraction needed to know which two fields to check, not whether the bill as a whole was trustworthy.
What changed: They rebuilt the model output to expose per-field data. The review queue became surgical instead of all-or-nothing.
Three confidence tiers over a single threshold
Situation: The initial model used one cutoff: above it, auto-approve; below it, flag for review.
What I did: I brought evidence that a single threshold produced two failure modes at once, then worked with the data scientist to check where the model's confidence naturally clustered so the tiers matched real output patterns.
What changed: The three-tier model came from combining the behavioral reasoning with distributional knowledge from the model. Neither of us would have landed there independently.
Key decisions
Three confidence states for directing human attention
I designed three confidence states instead of a single approve-or-flag cutoff. Reviewing every field wastes time; auto-approving too liberally creates compliance risk, since sustainability managers sign off on numbers that flow into regulatory carbon reports. The three tiers route attention to where risk actually sits: high confidence asks for a sign-off, mid confidence flags specific fields, low confidence queues for full verification. It's not a trust dial. It's a routing decision about where human time matters most.
Where each tier routes attention
Explanation panels on every extraction, not just exceptions
The simpler path was flagging only the exceptions and hiding the rest. I tried it early, and the problem was immediate: with no visibility into how a correct extraction was reached, there was no basis for trusting the ones that were flagged. Every extraction now shows the source document, field-level confidence, and how the value was derived, trading some density for legibility, enough for a reviewer to judge without re-verifying from scratch.
Only exceptions surface. No visibility into how a confident extraction was reached.
Every extraction shows the source document, field-level confidence, and how the value was derived.
Framing AI as collaborator, not replacement
Early prototypes said "automated by AI," implying the system had already acted, but sustainability managers are accountable for what goes into carbon reports. I reframed every touchpoint to surface work, not complete it, keeping the human in the decision. It became the preferred direction in stakeholder review.
"4 bills auto-processed."
"The assistant found 4 bills. 3 are ready to approve, and 1 needs your review."
How AI was used
I used AI tools at three steps of my own design work on Energy Tracker. Each one made a step faster or let me explore more. The design decisions still came from users and the team.
Research synthesis
Dovetail AI
I started from research others had already run. Dovetail AI helped me sort those notes into themes faster, so I reached the core finding sooner: people needed to know where the data came from and how sure the system was.
Design exploration
Figma AI
I used Figma AI to generate more variations of the confidence states and review screens than I could have drawn by hand, then narrowed them down to the three-state model.
Prototyping
Claude Code
I built an interactive prototype of the extract, review, and approve flow with Claude Code, so users could try a realistic version before engineering built it.
AI design thinking
Why AI
The client operated a franchise model: hundreds of independently run sites, each with its own provider and schedule. No one had a central view of what had arrived or what was missing, so gaps only surfaced once they'd already hit a carbon report.
Missing and late documents meant real financial risk: late fees, delayed reporting, and manual chasing across a 500+ property portfolio. At that scale, manual tracking couldn't reliably catch problems before they happened.
The only way to manage this manually was to keep adding headcount. That wasn't sustainable. The real solution wasn't a faster manual process. It was a system that tracked what arrived, surfaced what was missing, and routed only the exceptions to a human.
Human vs AI output
Carbon data goes into ESG reports and regulatory filings: it carries legal weight. The model I designed was built around that accountability. The system could assist with extraction and prioritization. The sustainability manager or franchisee at a site remained responsible for review and approval. Nothing in the review model changed that. Designing that boundary clearly was the core of the work.
AI produced
- →Raw bill extractions: consumption figures, billing periods, and provider identifiers
- →Per-field confidence scores based on OCR clarity and model certainty
- →Anomaly flags when a reading deviates from a site's historical baseline
- →Proactive gap detection when an expected bill does not arrive
- →Suggested corrections with source citations for low-confidence extractions
Human controlled
- ◎Final approval of every extraction the system flags for review
- ◎Override and correction of any suggested value before it enters the platform
- ◎Sign-off on the monthly dataset before it flows into carbon reporting
- ◎Escalation decision when a portal is unreachable or site credentials have expired
The three confidence states defined the boundary in the review model. High-confidence extractions asked for a sign-off. Mid-confidence items flagged specific fields for a quick check. Low-confidence items queued for full verification with suggested corrections. The tiers were not about how much the system could handle autonomously. They were about where a sustainability manager or franchisee needed to pay attention. The system assisted with extraction and prioritization. The approval was always theirs.
Trade-offs & guardrails
The design accounted for the decision points that carry the most compliance risk. There are still areas I would design further. For a compliance-sensitive workflow, knowing what the product does not yet cover is part of the work.
What didn't make v1
What the prototype accounted for
Confidence states and review routing
Three confidence states defined what a sustainability manager or franchisee needed to do with each extraction: sign off, check specific fields, or verify in full. The routing logic was designed so that nothing moved forward without an explicit human action at the appropriate level.
Approval lock
Once a person approved a value, the system could not overwrite it. The model could suggest a correction, but the lock stayed until the person changed it. This constraint was central to the review model.
Failure cases: portal errors and missing bills
If the system could not reach a portal, or if an expected bill did not arrive, it alerted and queued rather than skipping silently. A flagged gap in carbon data is recoverable. An undetected one going into a regulatory filing is not. These failure paths were part of the design from the prototype onward.
Next, I would strengthen
Exception categories
The system flagged exceptions. The next iteration would need to categorize them: format changes, portal outages, reading anomalies, so sustainability managers could triage by type rather than work through a flat queue.
Correction history
When a person overrides a suggested value, that correction should be logged and visible. Understanding where the model was wrong, and how often, is information a sustainability manager needs to calibrate trust in the system over time.
Audit trail per extraction
The design called for logging source URL, timestamp, OCR output, confidence score, model version, and approver. The next iteration would need to verify that trail is complete, queryable, and exportable for compliance review.
Model feedback loops
Corrections made during review should feed back into model retraining. Without a feedback loop, extraction quality stays static regardless of how many corrections are made. Designing how corrections are captured and used to improve the model is the next area I would take on.
Analytics on recurring extraction failures
If the same portal format, provider, or property type generates repeated low-confidence extractions, that pattern needs to surface before it becomes a reporting problem. A view showing where the model struggles consistently was not in scope for this work.
In hindsight, I would have pushed for a shadow mode in the first month. The system runs fully but does not surface any suggestions for approval. Sustainability managers and franchisees review everything while the model runs alongside. It would have let us catch trust calibration issues before they became adoption problems, and given us real data to work from before it went wider.
Intent and measurement
What the design was intended to change
The design aimed to change the monthly data cycle: no more manual portal logins, downloads, and spreadsheet copying across every property, with gaps caught before month-end instead of after.
The change was structural: extraction ran automatically, and gaps surfaced before becoming errors. Review went only to real risk. The goal was making people's time count, not removing them.
What I'd measure next
Confidence score drift over time
As portal formats change, does model accuracy stay consistent? I would track precision and recall quarterly and retrigger retraining when drift exceeds a defined threshold, before it reaches users.
Over-trust behavior
Which users approve nearly all flagged items without making any edits? That is a signal the review queue is not creating genuine oversight, just adding friction before rubber-stamping. Worth surfacing in an admin view.
Threshold calibration by property type
The design used uniform confidence thresholds across the portfolio. Industrial properties have larger bills with more complex tariff structures. I would test whether they warrant different thresholds than commercial or residential sites.
Time to comfortable adoption
How long does it take a new sustainability manager or franchisee to stop reviewing auto-approved items out of habit? That is a proxy for onboarding effectiveness I would use to redesign the first-run experience.
Error propagation distance
When an extraction error is approved and flows into a carbon report, how far downstream does it travel before someone catches it? Understanding this would tell me how conservative to be with the confidence thresholds, and whether the audit trail design is working.
What was delivered
Designed for a large hospitality client operating a franchise model, Energy Tracker moved from prototype to a shipped product used by real users. After launch, I validated it with users.
Review screens for extracted bill data
The product included review screens showing extracted consumption figures, billing periods, and provider identifiers for each bill. Sustainability managers could move through a month's worth of extractions from the review queue rather than logging into individual portals.
Three confidence states and explanation panels
Each extraction was assigned one of three confidence states: sign-off, quick check, or full verification. Every extraction, regardless of confidence level, included an explanation panel showing the source document, the per-field confidence score, and how the value was derived.
Upload and preview flows for missing documents
When an expected bill did not arrive, the product surfaced the gap and provided an upload flow so a sustainability manager or franchisee could add the document manually. The uploaded document went through the same extraction and review path as automatically collected bills.
Prototype demos
Dashboard and data overview
Energy tracking dashboard showing emissions data, utility consumption, and AI-powered insights from a unified interface.
System investigating missing bills
The system searches by service type and surfaces extraction results with confidence indicators for sustainability manager review.
Reflection
Designing for AI requires a fundamentally different approach than traditional software. The most impactful design decisions weren't about the AI itself, but about how we communicated its capabilities and limitations to users who are accountable for the data it produces.
If I did this again, I would invest more in onboarding. Some users initially over-trusted the system and reduced their review effort. Others under-trusted it and reviewed everything, which removed the benefit. Setting expectations early on what the system does well, where it needs help, and when it will surface something for review would have smoothed adoption significantly.