AI hackathon ideas, by function

01What should operations teams build?#

Recurring report assembly and inbound triage. Operations work is unusually well suited to a one-day build because it is repetitive, rule-heavy, and already documented in the runbooks people follow, which means the context an AI system needs already exists in written form.

• The weekly operations report, generated from the same sources a person currently opens by hand
• An inbound request triager that categorizes, routes, and drafts the first response
• A vendor or partner status digest that reads updates from three systems and summarizes exceptions only
• A runbook assistant that answers 'how do we handle this' from the existing documentation

02What should finance teams build?#

Anything involving reconciliation narrative, variance explanation, or document extraction. Finance rarely wants AI making calculations; it wants AI doing the reading and the writing around calculations that a spreadsheet already does correctly.

• A month-end variance narrative drafter that explains movements against a written commentary standard
• An invoice or receipt extractor that normalizes into the format the ledger expects
• A contract terms summarizer for revenue recognition review
• A budget-question answerer grounded in the current plan, so the FP&A inbox stops being the interface

Keep the arithmetic in the system that is already trusted for arithmetic. The build is the explanation layer, not the calculation layer.

03What should support teams build?#

Triage, summarization, and draft-response tooling grounded in the existing help center. Support is usually the fastest function to show measurable return, because ticket volume makes even a small per-ticket saving visible within weeks.

• A ticket pre-summarizer that gives the agent the situation before they read the thread
• A draft-response generator grounded strictly in published help content
• An escalation detector that flags tone and risk signals early
• A weekly themes report on what customers are actually complaining about, which usually surprises someone senior

04What should people and HR teams build?#

Screening summaries, policy answering, and onboarding support. These teams carry a heavy load of repeated written explanation, which is exactly the shape of work that a grounded assistant handles well, with a human firmly in the loop on anything affecting an individual.

• A recruiter screen summarizer that produces a consistent structured note per candidate
• A policy answerer built on the actual handbook, with citations back to the source section
• An onboarding buddy that answers the first-two-weeks questions nobody wants to ask twice
• An interview-notes synthesizer that turns four panel write-ups into one decision document

Draw the human-in-the-loop line explicitly before the build starts. Anything touching hiring, performance, or compensation outcomes gets a person making the decision, always.

05How do you tell if an idea is one-day sized?#

Three tests: the data it needs already exists in one place, a person could do the task correctly given the same inputs, and the output is text or a document rather than a system change. Fail any one of those and it becomes a project, not a hackathon build.

Questions people ask#

Can teams build customer-facing things?

They can, but they usually shouldn't in a single day. Internal tools have a forgiving failure mode and no approval chain, which is exactly what you want for a first build.

What if two teams pick the same problem?

Let them. Two approaches to the same friction is genuinely useful information, and the demo comparison teaches the room more than either build alone.