Draft, Don't Decide: Keeping Travel Advisors in the Loop

At 8:50 on a Monday, an advisor opens a thread. It holds fourteen emails between a couple planning a fortieth-anniversary trip and a colleague who has since moved on. Somewhere in there are a shellfish allergy, a firm opinion about rental cars and a half-promise of a private dinner. The AI’s draft proposal arrives forty seconds later.

There are two ways this can go wrong. She can distrust the draft and rewrite all of it, in which case the AI saved her nothing. Or she can skim it, see that it looks right, and send it, and the shellfish allergy mentioned once in message nine is gone.

“Draft, don’t decide” is the principle we design around for the ground between those two failures. It’s simple to say and harder to build than it sounds.

What a draft is, precisely

A draft is a proposed action with four properties:

1. No side effects. Nothing has been paid, booked, sent or promised.
2. Visible reasoning. It says why this inn and why this order.
3. Marked uncertainty. It says which claims it is least sure of.
4. Traceable facts. Every supplier fact points to a source and a date.

A decision is the moment something leaves the building: money moves, a supplier receives a request, or a traveler is told something. The line between drafting and deciding is the most important boundary in any AI-assisted workflow. Most of the design work is about putting it in the right place.

A decision-rights matrix

Two questions settle who holds the pen.

• Stakes: if this is wrong, who is hurt, and how badly? Think money, safety and trust.
• Reversibility: how costly is it to undo, and how quickly?

Together they make four zones:

• Low stakes, easy to undo: AI decides, and logs what it did.
• Low stakes, harder to undo: AI decides after a short delay that a person can cancel.
• High stakes, reversible: AI drafts, a person approves.
• High stakes, irreversible: a person decides, and AI informs.

Here’s how common advisory tasks fall:

Task	AI’s role	Why
Summarize a long client thread	Decides	Internal and easily corrected
Tag stated preferences in the CRM	Decides; the client can view and edit	Low stakes, but it’s the client’s data
Write the first proposal	Drafts	Taste, relationship and money all in play
Place a free 24-hour supplier hold	Decides within rules	Costs nothing and expires on its own
Send a routine pre-trip reminder	Decides, with a 30-minute cancel window	Low stakes, but awkward to unsend
Reply to a supplier about a rate mismatch	Drafts	Money and a relationship
Re-plan a day after a closure	Drafts	Reversible until the traveler is told
Describe a room or trail as accessible	Drafts, with the measurements attached	Safety and trust; a person confirms fit
Pay a non-refundable deposit	Informs	Money, and irreversible
Weather or safety go/no-go	Informs	Belongs to the guide or operations lead

Most of the value sits in the third zone. That’s where the hours are, and it’s where the design has to be good.

The rubber-stamp problem

People over-trust automated suggestions, especially ones that are usually right. Researchers call this automation bias. Operators call it “I didn’t think I needed to check.” It produces an uncomfortable fact: a draft that’s right 97% of the time is more dangerous than one that’s right 70% of the time, because nobody reads the 97% draft carefully.

Better models make the problem worse. It has to be solved in the workflow. Five countermeasures work:

1. Show the diff, not the document. Highlight where the draft departs from the client’s request, from the previous version, or from what the advisor usually chooses. Reviewers notice changes and miss restatements.
2. Flag the three claims most worth checking. A person can check three things properly. They can’t check thirty.
3. Make approval specific. Approving a flagged item means ticking that item, for example “Shellfish allergy carried through to all three hosted dinners,” not pressing a general Send button.
4. Track review time. If the median time to approve a proposal falls below the time it takes to read it, you have a stamp, not a review.
5. Re-review a sample. Each week a senior advisor goes through five sent proposals in depth. This catches drift in the model and in the reviewers.

Designing the draft for the reviewer

The reviewer’s first thirty seconds should go to the things only a person can check, so the top of the draft looks like this, before any narrative:

Draft proposal — anniversary trip, seven nights, northern New Mexico

Why this shape: Two bases instead of three. The clients said in message 4 that they “hate packing up.”

Assumptions: No driving after dark (inferred from message 11, please confirm). Private dinner on night five (offered by a colleague in message 9, not yet booked).

Check these: (1) Shellfish allergy applied to all three hosted dinners. (2) The casita rate comes from a supplier sheet dated six weeks ago. (3) The pottery studio confirms by email only, and hasn’t confirmed yet.

Question for the clients: Would they trade the balloon flight for a slow start on day three?

The polished itinerary comes after this block. A draft that opens with beautiful prose and hides its assumptions in the middle is built to be approved, not reviewed.

The loop runs both ways

“Human in the loop” usually means a person checks the machine. It should also mean the machine checks the person, without the authority to overrule them.

Advisors edit under pressure, and edits break things. An advisor swaps night three to a lovely inn an hour farther north and doesn’t notice that the next morning’s balloon flight now needs a 4:50 AM departure. Another moves a dinner to 7:30 PM, after the restaurant’s last seating for parties of six. Neither is a judgment error. Both are the kind of constraint check software does well and tired people do badly.

So every edit should trigger the same checks the original draft passed: opening windows, drive times, holds that no longer match, dietary notes that didn’t carry over. The result appears as a quiet warning beside the edit, never as a block. The advisor can override it with one click and a short reason. Those reasons are useful data. They show where your constraints are wrong, out of date or too strict.

Measuring whether the loop works

You can’t manage a human-in-the-loop system by asking whether people like it. Measure it:

Metric	What it tells you	Warning sign
Unedited send rate	Draft quality, and reviewer attention	Rising quickly while review time falls
Fact edits per proposal	How well drafts are grounded	Not falling over time
Taste edits per proposal	Advisors are still advising	Falling toward zero
Median review time	Whether people actually read	Shorter than the time it takes to read
Escaped errors	Mistakes that reach a traveler	Any upward trend
Override reasons	Where the model misreads clients	The same reason keeps recurring

The pairing that matters is fact edits and taste edits. Fact edits mean the draft got something wrong, and they should fall as grounding improves. Taste edits mean an advisor applied judgment the model doesn’t have, such as knowing this couple will prefer the small inn to the larger resort. Those should hold steady. If taste edits vanish, either the model has become a perfect copy of your advisors’ judgment, which is unlikely, or your advisors have stopped reading.

In one pilot with a boutique agency, the median time from inquiry to first proposal fell from about two working days to the same day. About a third of proposals still went out unedited, and taste edits held steady, which we read as a healthy loop.

Where we draw the lines

We build every product on this matrix. In Nova’s Itinerary Studio, a proposal stays a draft until an advisor sends it, with the assumptions block on top and every supplier fact linked to its source. The supplier holds placed by our booking workflow automation are free, time-limited and logged. Anything that costs money waits for a person.

For travel advisors and agencies, the matrix is also a client-facing promise. You can tell clients plainly what software does for them and what a person always decides. Writing that promise down, along with what the system may and may not do with a traveler’s preferences, is a core part of our responsible AI and traveler data governance work, and it runs through our approach to every engagement.

Promoting a task from “draft” to “decide”

Tasks can earn more autonomy, but it should be earned slowly and lost quickly. Before promoting a task, check that:

• The task is reversible, or has a cancel window a person can use.
• At least 200 consecutive reviewed instances have passed with no fact errors that would have reached a traveler.
• The people doing the reviews asked for the change. It wasn’t imposed on them.
• Every automatic decision is logged with its inputs and can be audited.
• A demotion trigger exists: one escaped error of a defined severity sends the task back to draft.

Write your matrix this week

List twenty things your team does in a typical week, from summarizing threads to paying deposits. For each one, answer the two questions about stakes and reversibility, place it in a zone, and compare that with what your tools do today.

The mismatches are your roadmap. Some will be tasks where software is deciding something a person should own. Just as often, they’ll be tasks where a person is still doing work a good draft could have done in forty seconds.