Most “travel tools” for small teams are still folders. We’re rebuilding around the trip.
For two years, the way we planned travel at our last jobs was a quiet mess. A flight confirmation would land in Gmail. A Slack thread would start with “wait, who’s on this trip?” Someone would book a hotel on the wrong credit card. A week before departure, a calendar invite would appear with the wrong arrival time. The CFO would ask, on a Friday, what Q3 travel looked like, and the answer was “I can get back to you Monday.”
The tools we tried didn’t fix the problem. They filed it differently.
What a “travel inbox” gets wrong
The category that dominates the SMB travel market — TripIt, Concur, Lola, a dozen others — is built around an assumption: that a trip is a thing you collect. Forward an email, get a card, file it under a tab. The artifact is the trip.
That works if the trip is the deliverable. For a family vacation, it is. For a small team that travels for offsites, sales, recruiting, and conferences every single month, the trip is a trigger for everything else: who’s traveling, where, when, who approves it, what budget bucket it falls under, what expenses it generated, and whether the airline is going to change the gate thirty minutes before boarding.
A folder doesn’t answer any of those questions. A folder waits to be asked.
What a trip command center does differently
When we started TravelOps, the design question wasn’t “how do we forward confirmation emails?” — that part was the easy bit, and we knew from experience it was already half-solved by everyone in the category. The question was: what owns the trip the moment it exists?
Our answer: a single workspace that treats the trip as a first-class record, not a card. Everything that touches a trip — flights, hotels, ground transport, travelers, budgets, expense charges, calendar events, status pings from the airline — is attached to the trip itself, not a folder hierarchy or a thread or a Notion page. When the airline pushes a gate change, the trip changes. When the card posts a charge, the trip changes. When the CFO asks, on a Friday, “what does Q3 travel look like?”, the answer is the trip list, filtered by quarter, with totals already in front of you.
That’s not a small distinction. It changes the design of every other feature:
- Ingest is bidirectional. We forward to
[email protected], but we also pull status from SITA, sync charges from Brex and Ramp, and import from calendars. Each side pushes into the trip. - Spend is a trip property, not a follow-up report. When the team uses their Brex card on the trip, we don’t generate a CSV for next month’s review. The trip’s spend total updates live. Budgets compare to it. Categories roll up to it.
- Status is a trip property, not a notification. When the gate changes, the trip reflects it. No new email, no new Slack ping. The next time someone opens the trip, they see the current state.
- Approval is a trip property, not a workflow. Travel managers can require approval before the trip is “active” in the org. Once approved, the trip is real and all downstream systems know.
What we explicitly do not do
A clean list of things we have decided to leave out, because we think they distract from the core value:
- No booking. We integrate with the tools teams already use (Brex Travel, Ramp Travel, corporate travel agencies, direct airline portals). We don’t take a cut and we don’t try to be a TMC.
- No corporate-card issuance. Brex and Ramp already do this for the segment that needs a card. We sync what they issue.
- No all-in-one chat replacement. The trip command center is the record. Slack, email, and calendar are still the channels. We notify them when the trip changes, but we don’t try to be where the conversation happens.
- No “AI travel assistant” theatrics. We use AI to parse confirmation emails, map spend to trips, and answer questions like “how much did we spend on the NYC offsite?” But we don’t pretend to plan your trip for you.
These are not feature gaps. They are scope decisions we made on purpose, because we think the category is full of products that tried to do everything and ended up doing nothing well.
Honest limits, called out
Even with all that, the trip command center model has limits we won’t pretend away:
- Pre-trip planning is not solved by us. If you need an agent to plan a complex 8-day, 4-city international itinerary with backup flights and hotel swaps, we are not that. Use a TMC or a human EA. We will surface their work in the trip.
- Risk management for groups >50 is out of scope. That segment is well-served by larger platforms with security and duty-of-care features. We’re optimized for teams of 3 to 50.
- In-app booking is gated to Growth+. Below that, we expect you to use Brex Travel / Ramp Travel / your TMC. We will track the trip regardless of where it was booked.
The honest version
We built TravelOps because we lived the problem. We don’t think a folder is the answer. We think a workspace that owns the trip — the moment it exists, and for as long as it matters — is the answer. That means a lot of careful, unglamorous engineering around ingestion, identity, and idempotency. It means saying no to features that would distract from the core. It means shipping a smaller, sharper product than our category is used to.
If you run travel for a small team and this resonates, forward a confirmation to [email protected] and see what happens in fifteen seconds.
— Serdar, founder, TravelOps