Recursos
Atrás

Se ahorraron cientos de horas de procesos manuales al predecir la audiencia de juegos al usar el motor de flujo de datos automatizado de Domo.

Ver el vídeo
A packed indoor basketball arena with a large scoreboard hanging above the court showing game information.
Acerca de
Atrás
Premios
Recognized as a Leader for
32 consecutive quarters
Primavera de 2025: líder en BI integrada, plataformas de análisis, inteligencia empresarial y herramientas ELT
Fijación

Building Enterprise AI Through Hackathons: How Bissell Shipped Working Workflows in Two Days

Grant Stowell

Field & Partner Marketing Specialist

4
0
min read
Wednesday, May 20, 2026
Building Enterprise AI Through Hackathons: All Talk, No Bots

A focused two-day hackathon turned AI curiosity into production-ready automation at Bissell, cutting reporting time from hours to minutes.

Everyone's asking the same question: What are we doing about AI? Brandon Walsh, director of data and analytics at Bissell, heard it constantly. The challenge wasn't so much a lack of interest as it was finding a way to move from experimentation to execution without derailing existing priorities. His answer was building enterprise AI through hackathons, a time-boxed approach that delivered working workflows across customer service, marketing, product design, and sales in just 48 hours.

In the Domopalooza 2026 session All Talk, No Bots? How Bissell and Domo Turned AI Buzz into Real Workflows, Walsh breaks down exactly how his team structured the hackathon, selected use cases, and measured success. The insights apply whether you're using Domo, another platform, or building from scratch.

Ship something usable in two days

A two-day, cross-functional hackathon can quickly convert AI curiosity into shipped, usable workflows. Walsh describes intentionally carving out dedicated time with partners to build real, functioning outputs. The hackathon was designed to end with something that actually functions and you can use, enabling teams to productionize immediately or iterate later, reducing the usual delay between experimentation and deployment.

"The goal was, at the end of the two days, is leave with something that actually functions and you can use," Walsh explained.

This shipping-oriented mindset changes how you approach the work. Instead of building proof-of-concept demos that sit on a shelf, you're creating artifacts that can go into production or inform clear next steps.

How to apply this approach

Here's what made the two-day time constraint work for Bissell:

  • Set a hard deadline: The timebox forces decisions and prevents scope creep. You can't spend three weeks debating architecture when you have 48 hours.

  • Define "done" upfront: Agree on what a usable output looks like before you start. Is it a working agent? An automated report? A functioning app?

  • Bring the right people: Bissell had eight people from their partner teams on site, including experts working overnight in different time zones.

  • Accept imperfection: The goal is something you can build on, not something polished. Ship first, refine later.

Optimize the process before automating it

A successful hackathon hinges on business ownership and process clarity before automation. Bissell required business stakeholders to spend the full two days with the build team because business context is very important. Walsh also stresses standardizing and optimizing the process first to avoid automating a broken workflow—an enterprise scaling prerequisite for repeatable, governed automation.

Bissell uses an acronym called SODA: Standardize and Optimize, then Digitize and Automate. "Anytime we're automating anything, we have an acronym we call SODA," Walsh noted. The principle is straightforward: Don't force technology into a bad process.

"We needed to not [...] find a lot of times, like, hey, I have this hammer now, let's go find a nail. That doesn't typically work in business partnership," Walsh said.

Making SODA work for your team

Before your next automation project, work through these steps:

  • Map the current state: How exactly does the process work today? If it's not documented, you'll spend significant time in conversation to figure it out.

  • Identify inefficiencies: Where are the manual handoffs? What steps add time without adding value?

  • Standardize first: Get the process consistent across teams or regions before you automate. Otherwise, you're encoding inconsistency.

  • Require business participation: The people who own the process need to be in the room. They understand the edge cases and exceptions that will break your automation.

This approach takes more time upfront but prevents the common failure mode of automating something that shouldn't exist in the first place.

Target non-believers to build enterprise demand

Rather than focusing on data team use cases where belief and adoption were already high, Bissell selected workflows from customer service, marketing, product design and engineering, and sales specifically to get non-believers and convert them. This hackathon-as-change-management strategy helped broaden demand and request volume after the event.

"We purposely didn't pick data and analytics use cases specifically, because we're kind of the early adopters of this. We already believe, generally speaking, so we wanted to get non-believers and convert them," Walsh explained.

The results spoke for themselves. Post-launch excellence reporting that took 8–10 hours per SKU now takes 5–10 minutes with human-in-the-loop validation. Weekly sales reports that required manual screenshots and PowerPoint assembly now generate automatically.

Selecting high-impact use cases

When choosing which problems to tackle, consider these criteria:

  • Pick visible pain points: Choose processes that people actively complain about. The more frustrating the current state, the more compelling the improvement.

  • Quantify the time savings: Bissell tracked hours saved and tied them directly to ROI conversations. Walsh noted that 2,000 hours is approximately a full-time person. That's the kind of math executives understand.

  • Ensure data readiness: Bissell required that data already exist in Domo. This removed data engineering work from the hackathon scope and kept the focus on building workflows.

  • Document the before and after: Validate AI-generated outputs against the original manual versions. Walsh emphasized keeping very much a human in the loop for anything going to executives.

What you can do next

The hackathon approach Walsh describes isn't complicated, but it requires commitment. You need dedicated time, business participation, clear success criteria, and a bias toward shipping something usable rather than something perfect.

The measurable time savings (for example, hours reduced to minutes across multiple departments) create the ROI narrative that funds scaling. And the governance practices, including legal review and human-in-the-loop validation, ensure that what you build can actually go into production.

Whether you're exploring AI automation for the first time or looking to accelerate adoption beyond your data team, the two-day hackathon format offers a practical path forward. Start with a real business problem, bring the right people together, and leave with something that works.

Want the full breakdown of Bissell's hackathon approach, including specific use cases and implementation details? Watch the complete session.

No items found.
Table of contents
Carrot arrow icon
Tags
No items found.
No items found.
Explore all
No items found.
No items found.