Your Hotel Group's Agency Relationships Belong in Your CRM, Not a Spreadsheet

Every hotel group we onboard already has an agency spreadsheet. Names down one column, a commission percentage that got updated for the big tour operators and probably forgotten for the small ones, and a payment terms note in free text that only makes sense to whoever wrote it. It sits next to the CRM, not inside it, because most systems never built a way to treat a travel agency the way they treat a guest: as a contact, with a real history, that more than one person on the team needs to see.

That's the actual gap. Not a missing report. A missing row.

What a hotel B2B CRM actually means: agencies as contacts, not a separate system

In GuestMaker, a B2B account is not a parallel database bolted onto the guest CRM. It's a contact, same table, same schema, flagged contact_type='b2b'. That single distinction is what makes the rest of this work: a travel agency contact shows up in the same inbox as a guest conversation, can be added to the same segment tooling, and can receive the same campaign infrastructure a guest contact would, addressed to the right person at the agency instead of a guest. Nobody has to reconcile two systems to find out whether someone already emailed that TTOO rep last week. The email is right there, on the same contact record.

Two sales pipelines come seeded out of the box: Corporate and FIT for the steady, transactional relationships (a corporate travel manager booking rooms on a negotiated rate, a smaller agency sending occasional leisure business), and MICE and Groups for the longer, higher-touch deals (a conference, a wedding block, a multi-property group booking). They're separate pipelines because they close differently, and that difference is where the real work happens.

How do hotel groups track TTOO commissions without trusting a spreadsheet column?

Most of the time, they don't, not really. A commission rate lives in someone's head or a cell that hasn't been touched since the deal was signed, and the person who negotiated it has since left the company. GuestMaker keeps a commission ledger against every agency account with three real states: accrued, then invoiced, then settled. A commission isn't a number you glance at. It's a status you can trace, for every deal that closes.

But the ledger only means something if the number that fed it was actually agreed, not just typed in. That's the part a spreadsheet can't do and a server-enforced gate can.

Why a deal can't skip its own paperwork

Moving a Corporate deal to "won" requires a promo code and accepted payment terms to already be on file. Moving a MICE deal to "won" requires a contract document and a PMS localizer code linking the deal to a real booking. These aren't dashboard warnings a sales rep can click past under deadline pressure. The check runs on the write path itself: the same rule fires whether the stage change comes from the dashboard, from the API, or from a client accepting a proposal on the public booking page. There's no back door where a deal quietly becomes "won" with no contract attached and no way to invoice it later. If the paperwork isn't there, the deal doesn't move. Full stop.

That single rule is the difference between a CRM that records what a sales team did and one that has an opinion about what a sales team is allowed to do.

CRM for managing agency contracts across multiple hotel properties: the parent and child problem

A hotel group's real agency relationships rarely fit in one flat list. A head office negotiates a rate structure, and several national subsidiaries book under it, sometimes with their own local tweaks. GuestMaker models this as parent and child agency families, capped at three levels deep.

The inheritance is deliberate, not automatic in the sense of silently recomputing everything on every change. A brand new child account added under a parent inherits that parent's terms, commission rate and payment days included, at creation. But if an existing account later moves into a different family, its own already negotiated terms freeze in place rather than quietly repricing to whatever the new parent has on file. That distinction matters because the failure mode it avoids is real: a subsidiary that spent months negotiating its own commission rate should never wake up rebilled at a different parent's number just because someone reorganized the account tree.

Whose number is the real one: field locks on a deal

Even inside one account, not everyone should be able to touch every number. A named field on a deal, commission rate, ADR, promo code, can be set to read-only or propose-a-change for specific users. A junior account manager might see the negotiated commission rate but only propose an adjustment, not overwrite it outright. And this isn't a UI convention a determined user can route around by hitting the API directly or by accepting a proposal through the public page. The lock is enforced on every one of those paths, because a rule that only exists in the dashboard is a rule that exists nowhere.

The reservation shows up. Which agency gets credit?

None of the above matters if a real booking can't be traced back to the deal that produced it. Reservation attribution runs a four-priority matcher: it first looks for an explicit agency code on the reservation, then a promo code, then a Mirai booking engine id if the reservation came through that channel, and only after all three of those fail does it suggest a possible match by email domain. That ordering is the point. An explicit code is proof. An email domain match is a guess worth surfacing, not a fact worth billing on, and the system treats the two differently instead of collapsing them into one confident number.

Once attribution lands, the commission ledger has something real to accrue against, and the 1:1 tracked email built into the same record, open and reply tracking, signatures, scheduling, replies matched back to the right deal automatically, means the conversation that closed the deal stays attached to the deal itself, not buried in someone's personal inbox.

What this doesn't do yet

Worth saying plainly: this is not a two-way calendar sync. Today it's read-only ICS import, so a hotel group can see an agency's availability but isn't writing back to it. It doesn't push live rates or allotments out to a partner's own booking system. There's no RevPAR or TrevPAR reporting built into the B2B side. And if two agency accounts turn out to be duplicates of each other, the CRM will warn and block rather than merge them, someone still has to decide which record is the real one. None of that is a hidden gap. It's just not built yet, and a hotel group evaluating travel agency commission tracking software should know exactly where the edges are before relying on it.

What is built is the part that actually removes the spreadsheet: agencies as real contacts in the same system as your guests, stage gates that enforce their own paperwork, family inheritance that doesn't silently reprice an existing deal, and a commission ledger that can answer, for any agency, what's owed and what's already been paid. That's a smaller claim than a full agency management platform. It's also one a hotel group can check against their own accounts on day one.