Cherrye Moore had been working on the same problem for years. Her five-person multi-day Italy operation was running on color-coded spreadsheets, manually rebuilt checklists, and a team spread across continents with no shared picture of what was happening or what came next.
She tried Monday.com. She tried building things with AI on her own. She kept hitting brick walls. What she and David London, Director of Product at Nivo, eventually figured out together is that the brick walls were not a tools problem. They were a diagnosis problem. Before they bought anything, built anything, or touched Airtable for the first time, they spent days just watching Cherrye’s team work, asking what the actual problem was, and discovering that half the team found color codes motivating and the other half found them paralyzing. Today, Cherrye’s operation runs on a single automated hub that generates 42 tasks per trip with calculated due dates, assigns work by trip type, and gives everyone a single source of truth in whatever view works for them.
David London walked through the whole build in this session. No developer. No prior Airtable experience. Two hours of David’s time, about 30 minutes of back-and-forth with Cherrye, and Claude Cowork did the rest. The Airtable system handles trips, tasks, pipeline, calendar views, and team assignments across B2B trips, custom heritage tours, and set-departure groups. The session also covers what Claude Cowork actually is and why it matters now: a desktop tool that can read and write files, connect to your tools, and navigate the web as if it were you. If you have been wondering whether AI-built operations systems are real and within reach for a small multi-day operation, this session is a working example you can copy, starting this week.
Key Takeaways
- Most operators skip the diagnosis step because solving feels better than thinking. Albert Einstein’s rule was to spend 55 minutes on the problem and 5 on the solution. Human nature runs the opposite direction. Cherrye spent years trying different tools and kept hitting brick walls. When she and David finally slowed down and spent actual time watching the team work, they discovered that color-coded spreadsheets were motivating for half the team and completely paralyzing for the other half. Knowing that changed everything about what they built.
- A five-person geographically distributed team with 57 custom trips a year cannot afford information living in five places. Cherrye’s world before the build: tasks in Google Sheets with manual color codes, trip context in emails or in someone’s head, customers in a separate CRM, and no way to see what the team in Italy was working on without sending a WhatsApp. Fast proposal responses could win or lose a deal, and there was no system that made fast responses easy.
- The team member who always resisted new tools actually likes Airtable. This was the signal that the solution was working. Previous tools, including Monday.com, failed because adoption was uneven. Airtable stuck because it let each person see information in whatever format matched their working style: list view, Kanban, calendar, filtered by destination or trip type. The underlying data is the same; the view adapts to the person.
- Every new trip now auto-generates 42 tasks with calculated due dates. Cherrye used to rebuild a client checklist manually every time someone booked. Now, when a new trip is created in Airtable, the full task list generates automatically with due dates anchored to the departure. The system distinguishes between B2B trips, custom heritage tours, and set-departure groups, and each gets a different automation with different ownership assignments.
- Claude Cowork built the entire Airtable system from conversation — David had never used Airtable before. The build process was entirely conversational. David fed context about Cherrye’s problems, team, and workflow into Claude Cowork. Claude researched the right tool, built the Airtable instance, and updated it when Cherrye asked for changes. David estimates the total human effort at a couple of hours plus about 30 minutes of back-and-forth with Cherrye. He never had to touch Airtable directly.
- Diagnosing the problem correctly saved years. Cherrye had been trying to fix her operations for years before this build. The previous attempts failed not because the tools were bad but because the problem was not scoped correctly. She was building solutions for the wrong friction points. Once she and David spent the time to understand what was actually breaking down, and why it was breaking down for different people on the team, solutioning went fast.
- Start slowly even if you want everything done yesterday. Cherrye’s biggest personal warning: she wanted to do everything at once and it would have been a disaster. Starting slowly meant they could verify each piece was working before adding the next. Moving one week at a time gave them the signal they needed to know what was working.
- Relational databases let task completions automatically advance trip stages. In Airtable, a task is actually linked to a trip. When a set of tasks completes, an automation can fire that moves the trip to the next stage. Nothing requires a human to update two places. Todo lists in tools like Todoist or Trello do not have this kind of structural connection.
- Cherrye keeps prospects in her CRM and only moves them to Airtable when they book. Airtable is her operations hub, not her CRM. The two systems serve different purposes: the CRM handles inquiry through to commitment, and Airtable takes over once someone becomes a client. This separation keeps the operations hub clean and focused.
- When Claude Cowork cannot use a connector, it just opens a browser and does it anyway. LinkedIn has no public connector because LinkedIn does not want one. When David asked Claude to connect with someone on LinkedIn, Cowork opened a browser session, navigated LinkedIn, found the person, and sent the connection request. He watched it happen without doing anything.
- Your working surface is a personal choice. Cherrye runs entirely in Airtable. David runs entirely in Cowork. Cherrye uses a Chromebook and does not have Claude Cowork. Her team works in Airtable as the daily tool, never touching Cowork. David built and maintains the system through Cowork. Both approaches reach the same outcome.
- Every problem is different. Do a time-tracking study if you cannot see where the time goes. There is no universal AI solution for tour operators. Several operators David has worked with did formal time-tracking studies and discovered that the hours they thought were going to focused work were going to email.
- Pick a starting problem that is big enough to fight through, but not your biggest. The problem needs to be significant enough that you will push through the learning curve. But if you start with your biggest, most complex problem, the learning curve may make it impossible to tell what is working. Find a meaningful problem in the middle, get a win, build momentum, then go bigger.
- It is never done. Agents drift and require ongoing tuning, just like employees. Building an AI system is not a one-time event. The system will drift over time. Claude will occasionally make mistakes. Assumptions baked into the automation will stop matching reality as the business changes. The advantage agents have over employees is that they do not take vacations, get sick, or quit. But they still need someone paying attention.
- Use Sonnet as your daily driver. Save Opus for genuinely hard problems. Opus 4.8 is the most powerful model but it chews through context and tokens fast. David only reaches for it when a problem is genuinely complex. Sonnet is his daily driver: highly capable and much more token-efficient. Haiku handles simple, routine tasks with minimal token use.
- The goal is to do nothing. If Claude can do it, let Claude do it. David’s operating rule is that unless Claude physically cannot do something, it does it. The only exceptions are drag-and-drop reordering, login credentials, and credit card entry. He runs five Claude tasks simultaneously, bouncing between them to give input and then letting Claude do the actual work.
- Nivo already has a live passenger agent that maps messy email data into booking fields automatically. If a passenger forwards a screenshot of their flight confirmation, Nivo’s passenger agent reads it and populates the right fields in the booking. The next step is connecting to the actual email inbox so no human has to copy, paste, or touch anything.
- Operators like Cherrye are shaping what Nivo builds next. Nivo is working hands-on with operators to build the automations and connections that do not yet exist in the product. What they learn from five or six operators doing this work becomes the roadmap for what gets built into the platform itself.
- Write down your entire process before you build anything. Cherrye’s practical tip: she and her team did three rounds of mapping their process, about three hours spread over a couple of weeks. Writing out every step, where the gaps were, where things were being handed off, gave David what he needed to build something that matched how they actually work.
- Your first AI day has a clear sequence: block time, download Claude Desktop, describe your business, connect one tool, start diagnosing. Download the Claude Desktop app. Build context first: describe your business, your workflow, your team. Connect something you already use. Start a conversation. Tell Claude to ask you questions one at a time. Connect another tool. Start automating one routine task. Monitor and tune. The sequence does not have to be perfect. It just has to start.