AddisFly - Registering a New Booking Agent (GDS Sign-On & Attribution)
Registering a New Booking Agent
Do this on the new agent's first day. Until it is done, every booking they make is credited to somebody else — and nobody notices, because nothing errors.
What went wrong when we skipped it: a Booking Agent joined on 7 August and issued 270 tickets. Only 40 (15%) were credited to her. The other 230 were credited to 19 different colleagues — whoever happened to import the record. Her sales, her commission, her scorecard, all attributed to other people. There was no error message at any point.
First decide: does this agent have their OWN sign-on?
There are two different situations and they are set up differently. Getting this wrong is what breaks attribution.
| Agent has their own GDS sign-on | Agent uses a shared / company sign-on | |
|---|---|---|
| Example | 593YKT belongs only to Kidist |
Several agents book under one company sign-on |
| Who gets credit | Resolved from the sign-on | Resolved from who created the booking in the ERP |
| What you must set up | A GDS Agent record (below) | Their own ERP login, and they must record their own bookings |
A — Agent has their own sign-on
Step 1: Create the GDS Agent record
- Search bar → GDS Agent → + New
- Fill in:
| Field | What to enter | Example |
|---|---|---|
| Son (sign-on) | Z + the agent's two initials |
ZKT |
| Primary User | their ERP login | [email protected] |
| Agent Name | their full name | Kidist Tekleab Abebe |
- Save.
Why the Z + initials format matters
The GDS report shows the sign-on as 593YKT — that is the PCC prefix 593Y plus the
agent's initials KT. The system strips the prefix and looks for a GDS Agent whose
sign-on ends in those initials. So 593YKT finds ZKT.
Get the initials wrong and there is no error — the booking is silently credited to whoever created it instead.
Step 2: Check it worked
Ask them to make one booking, then open it and confirm Booking Agent shows their name. If it shows someone else, the GDS Agent record is missing or the initials are wrong.
B — Agent uses a shared or company sign-on
Do NOT create a GDS Agent record pointing a shared sign-on at one person. That would credit every booking made on that sign-on to that one agent, and quietly steal the work of everyone else using it.
When a sign-on cannot identify one person, the system falls back to who created the booking in the ERP. So for these agents:
- They must have their own ERP login. Never let two people share one login — once they do, attribution is gone and no fix can recover it.
- They must record their own bookings. If someone else imports or types in their booking, the credit goes to that person.
- Nothing else is needed — no GDS Agent record.
⚠️ If two GDS Agent records ever end up with the same initials, the system refuses to guess: it will not attribute to either, and falls back to the creator. That is deliberate — a wrong attribution is worse than none.
Also do these on day one
Registering the sign-on is one of several setup steps that are easy to miss, because none of them produce an error when skipped:
| Step | Where | Symptom if skipped |
|---|---|---|
| GDS Agent record | GDS Agent | bookings credited to the wrong person |
| Mailbox / channel access | User Manager → Channels | "I can't see any email" — an empty inbox, no error |
| Role Profile | User Access Request | cannot open the screens they need |
See also: User Access Management.
Troubleshooting
A booking shows the wrong Booking Agent
The sign-on on the booking has no matching GDS Agent record, so the system used the booking's creator instead. Create the record, then ask IT to re-run the attribution job for the affected bookings.
The agent's bookings show no agent at all
The sign-on is unregistered and the person who created the booking does not hold a booking-agent role. Create the GDS Agent record.
Two agents share initials
Give one of them a different sign-on with the GDS provider. The system will not guess between them.
Owner: IT / Booking Operations. Created 1 September 2026.