Skip to content

Planning a trip

A partner is going to London for two days. Who else should they see while they are there? Which meetings are confirmed, which are still requests, and what happened at the ones that took place?

Trips turn that from a series of emails into a record the whole BD team can work from.

Everything here is Core. No Modules licence is required.

1. How a trip is structured

Four levels, and the shape is worth learning because it explains where everything lives:

Trip                     the whole journey        "London & Frankfurt Client Visits — Q4"
 ├── Trip Leg            one city, one date range "London, 5–8 Oct"
 │    └── Trip Target    one meeting              "Sana Ahmad, Amazon — Confirmed"
 └── Trip Participant    who from the firm is going

Targets hang off Legs, not off the Trip. A meeting belongs to a city and a set of dates, which is what makes "who can I see while I am in London on Tuesday" answerable at all.

Find trips on the Trips tab in the CV BD app, which also carries a Trip Legs tab.

2. Create the trip

Open the Trips tab and click New. Required:

Field Notes
Name Make it findable — destination and period beats "Q4 Trip"
Start Date / End Date Required. These bound the whole journey, legs sit inside
Status Draft · Planned · In Progress · Completed · Cancelled
Lead BD Contact The BD person accountable for the trip

Status is how the BD team triages. Draft means still being shaped and not ready for others to add targets. Planned means committed. Leaving a live trip in Draft is the most common reason colleagues do not add the target they had in mind.

Two rollups maintain themselves — Total Trip Legs and Total Participants — so the trip record always shows its own size without anyone updating a counter.

3. Add legs

A Trip Leg is one city over one date range. Each requires City, Country, Leg Start Date, and Leg End Date. Purpose is free text and is the field colleagues actually read when deciding whether to suggest someone — "Banking & finance coverage; regulatory update briefings" tells them more than the city does.

Split a journey into legs whenever the location changes. Two cities in one leg makes the "who is nearby" question unanswerable.

4. Add the people going

Trip Participants link firm users to the trip, each with a Role:

  • Traveler — going
  • BD Support — supporting from the office

The distinction matters for follow-up. BD Support is who chases the meeting notes afterwards.

5. Build the target list

Trip Targets are the meetings. Each belongs to a Leg and must name a Contact; it normally also carries the Account.

Open a Trip Leg record and use its Trip Target tab, which holds two components: a target locator for finding candidates, and a targets-by-status view for seeing where the list stands.

Visit Status — the planning state

Status Means
Potential A candidate. Nobody has asked yet
Requested The meeting has been proposed
Confirmed In the diary
Declined They said no, or cannot make it

Keeping Potential separate from Requested is the point. It lets the team build a long list without anyone assuming an approach has been made — and stops two people inviting the same person.

Other useful fields: Visit Purpose, Meeting Date/Time, Linked Opportunity (tie the meeting to a live pursuit), and Research Status — Requested · In Progress · Completed · Expired — for briefing material. Expired is deliberate: research goes stale, and a six-month-old brief is worse than none because it reads as current.

Outcome Status — after the meeting

Status Means
Completed It happened
No-show It did not
Rescheduled Moved
Cancelled Called off

Plus Meeting Notes, Follow Up Required, and Follow Up Due Date.

The follow-up fields are where trip value is won or lost. A confirmed meeting that generates no recorded follow-up is a trip the firm paid for and learned nothing from.

6. The trip record while it runs

The Trip record pulls the picture together:

  • Consolidated Targets — every target across every leg in one list, so you do not open each leg in turn to see where the trip stands
  • Trip Materials — documents for the trip
  • Trip Analytics in the sidebar — a scoreboard of Total Targets, Completed, No Show, Follow Ups, Linked Opps and Completion Rate, alongside the activity panel
  • A Trip Summary field section on the Details tab holding the Total Trip Legs and Total Participants rollups — a different thing from Trip Analytics, despite the similar name

7. Generating an itinerary

The button on the Trip record is Generate & Email Itinerary.

A second button, Generate Itinerary, exists in the package but is not on the Trip page in the reference org — it appears neither in the header nor under the overflow menu. If you were told to look for it and cannot find it, it has not been added to your page layout.

This button may not work at your firm. For technical reasons the itinerary link is not automatically adjusted when the package is installed, so out of the box it points at a page that cannot be found and fails with an error. It is a one-line fix an administrator makes once, and it is listed in the Admin Guide's post-install steps. If an itinerary button gives you an error rather than a document, that is the cause — report it to your admin rather than assuming the trip record is broken.

Known gaps in this release

  • Trip Participants and Trip Targets are not created for you. A new trip starts empty; the legs, people, and targets are all manual.
  • Research Requests link to Market Research records. If your firm does not use that object, the Research Status field will not advance on its own.

Troubleshooting

"I cannot add a target." Targets attach to a Trip Leg, not the Trip. Create the leg first.

"Total Participants is wrong." It is a rollup and recalculates when participants change. If it looks stale, reload — if it stays wrong, tell your admin, as rollup configuration is an admin setting.

"An itinerary button gives an error." See above — a known post-install step, not a fault in your trip. The button on the page is Generate & Email Itinerary; a separate Generate Itinerary exists in the package but is not surfaced by default.

"Two people invited the same contact." Both created a Trip Target for the same Contact on different legs. Check Consolidated Targets on the Trip record before reaching out; that view exists precisely to catch this.