When the venue team celebrates a rollout
Costumes are an unusual success measure for a point-of-sale project. Ted Hardy remembers venue employees dressing up to celebrate their rollout well into the deployment at Topgolf. The novelty should have worn off by then. Instead, the people who would use the system were still excited to receive it.
In his ChatGTM conversation with Michael Beck and Chad Horn, Hardy connects that response to work that happened before deployment. His team spent time understanding what different stakeholders needed and showing how their work could improve. The software mattered, but the team also had to reconsider the routines surrounding it.
Hardy describes an earlier replacement effort that had tried to exchange one system for another without sufficiently rethinking those routines. The systems behaved differently, and the replacement did not deliver the desired result. When he joined, the task became broader: establish what guests and employees should experience at each touchpoint, then build a foundation that could support it.
Find the work nobody should have to keep doing
One of Hardy's examples involves a corporate colleague who initially insisted that a burdensome process was necessary. After working through its purpose together, she reached a different conclusion. Familiarity had made the extra work seem inevitable. Examining the underlying goal created room to change it.
That kind of conversation requires more than declaring a process inefficient. The person doing it usually knows something the project team needs to understand. Taking time to learn the constraints makes it possible to distinguish a necessary control from a workaround that has outlived the problem it originally solved.
Hardy gave his team a demanding principle: departments could improve by different amounts, but nobody should go backward. It is a useful challenge for a transformation proposal. A saving in one department can look very different to the people who inherit its reconciliation work. Before calling a process simpler, follow the work all the way to the person who finishes it.
For another operator, a practical starting point is one transaction rather than an entire technology strategy. Trace how an event booking becomes an order, how a change reaches the kitchen and how the final bill is settled. Ask each person where they re-enter information, check another screen or wait for clarification. Those observations give a project a much stronger brief than a list of fashionable features.
Keep the point of sale good at its own job
Topgolf presents an unusual operating environment: large venues, multiple floors, events and food service alongside gameplay. Hardy describes resisting the temptation to push every special requirement into the point of sale. Some logic connecting event sales and orders belongs in an integration layer, where the team can address its particular needs without asking the core system to become something else.
The same discipline shapes his build-versus-buy thinking. Topgolf develops technology that contributes to its distinctive golf experience. Building a point of sale has a different economic case. Hardy considers the cost over time and the work around payments, certification and ongoing maintenance, drawing on an earlier payments project he would prefer not to repeat.
He also sees newer development tools making smaller internal applications more attainable for capable teams. These positions can coexist. A focused tool that fills a narrow gap carries different responsibilities from the system taking payments across a large business. The fact that a team can assemble the first version does not answer who will maintain it.
A useful evaluation therefore needs two estimates: what it takes to create the solution, and what it takes to keep owning it. Include support, changing requirements and the people who hold the necessary knowledge. Hardy's examples suggest reserving custom work for places where the business has a real reason to be different.
Describe the experience in verbs
Hardy's desired guest experience is easy to picture. Someone walks into a bay, picks up a club and starts playing. Food and drinks arrive without confusion. At the end, the host thanks them and they leave. Technology supports those actions without demanding the guest's attention at every transition.
He is careful to describe parts of this as a goal. In the interview, he identifies improvements he still wants, including better information about delayed orders. That distinction is useful for any project team: an intended experience should guide investment without being mistaken for a capability already delivered.
Hardy encourages curiosity about operations and credits learning beside an experienced operator early in his career. It is an approach a technology team can practice without buying anything. Watch a busy shift. Ask why a step exists. Notice where an employee protects the guest from a process that does not quite work.
Then return to the people expected to adopt the change. Can they explain how it helps them? Would they choose to keep it after a difficult first week? Hardy recalls asking an early venue whether it wanted its old system back and receiving a firm no. That answer, and the costumes that followed elsewhere, say more about adoption than a completed installation checklist alone.
