0 of 11 decided

Review — Turn incoming enquiries into paid bookings, and make every step measurable

Plan: /Users/agency/Documents/Agty/Analit/action-plans/2026-08-09-analit-lead-to-booking.md

Source: the client meeting of 30 July 2026. Every task below comes from something actually said on that call.

How to review this

T-001 — Extend measurement past the form submit to the paid booking

Not decided
Task

Design a tracking loop that shows, for every enquiry, what happened after it arrived: contacted, quoted, waiting on reply, deposit invoiced, deposit paid. Reconcile that back to the campaign that produced it, with no extra admin step for the client.

Problem solved

Reporting stops at form fills and phone-number taps. Nobody can say which campaign produced a paying traveller, so channel decisions get made on click volume.

Cost of inaction

Budget keeps being judged by lead counts that include bot submissions, while the real bottleneck after the enquiry stays invisible.

Benefit

One shared answer to whether the spend produced bookings, and a named bottleneck instead of a guess.

Done

A written design naming every funnel stage, the CRM field that carries it, the key that joins an enquiry to a campaign, and who updates what. Validated read-only against real records, with gaps listed rather than assumed. 80/20. One table showing where campaign, enquiry, quote, deposit and booking data live today, and which joins are missing.

Charts
flowchart LR
  A[Reporting stops at the form fill] --> B[Follow the enquiry through the CRM to the deposit] --> C[You can see which campaign produced a paying traveller]
  
flowchart TD
  S1[Ground read-only in CRM and analytics] --> S2[Map every stage to a real field]
  S2[Map every stage to a real field] --> S3[Define the enquiry to campaign join key]
  S3[Define the enquiry to campaign join key] --> S4[Validate against real records]
  S4 --> D{Every stage traceable on a real record}
  D -- yes --> DONE[Done]
  D -- no --> S2
  
Open questions

(layout preview — real questions are generated by the new pipeline)

Decision

T-002 — Write the target-audience persona document

Not decided
Task

Draft a compact document for the buyer groups named on the call: couples travelling as two pairs, parents with teenage children, retired couples, and returning travellers. Each with motivations, typical questions, objections, and what they are grateful for afterwards.

Problem solved

Ads, website and follow-up emails speak to everyone at once, so nothing reads as written for me.

Cost of inaction

Segmentation, landing pages and email variants all stay blocked, because none of them can be written without the personas.

Benefit

One reference every piece of communication builds on, instead of re-deriving the audience each time.

Done

One section per persona, grounded in evidence from real enquiries or the meeting rather than invention, with open slots left for the client's own audience notes promised on the call. 80/20. Three personas, five bullets each.

Charts
flowchart LR
  A[One message for everyone] --> B[Name the three or four real buyer groups] --> C[Every ad, page and email can speak to one of them]
  
flowchart TD
  S1[Read transcript and real enquiries read-only] --> S2[Write one section per persona]
  S2[Write one section per persona] --> S3[Mark inference separately from evidence]
  S3[Mark inference separately from evidence] --> S4[Leave slots for the client's notes]
  S4 --> D{Every claim traceable to evidence}
  D -- yes --> DONE[Done]
  D -- no --> S2
  
Decision

T-003 — Rework the newsletter structure and audit past performance

Not decided
Task

Audit the recent sends, then produce restructured letter templates that open like something worth reading and carry the offer in the closing lines, instead of opening with the trip and the dates.

Problem solved

Roughly one in ten subscribers opens, almost nobody clicks through, and unsubscribes run steadily. That is the pattern of a list that reads every letter as a sales letter.

Cost of inaction

The largest owned audience the business has keeps eroding while producing almost no traffic.

Benefit

The existing list starts producing enquiries without buying a single extra click.

Done

An audit table of the recent sends with opens, clicks and unsubscribes per letter, at least three restructured draft templates keyed to the personas, and a sending-rhythm recommendation. Nothing is sent. 80/20. The audit table plus one restructured template.

Charts
flowchart LR
  A[Every letter reads as a sales letter] --> B[Restructure: value first, offer in the closing lines] --> C[The existing list produces enquiries again]
  
flowchart TD
  S1[Confirm read-only mail platform access] --> S2[Audit opens, clicks and unsubscribes per letter]
  S2[Audit opens, clicks and unsubscribes per letter] --> S3[Draft three persona-keyed templates]
  S3[Draft three persona-keyed templates] --> S4[Recommend the rhythm from the audit]
  S4 --> D{Audit table and drafts exist, nothing sent}
  D -- yes --> DONE[Done]
  D -- no --> S2
  
Decision

T-004 — Build the traveller testimonial video pipeline

Not decided
Task

Collect the raw testimonial footage that already exists, including the longer group interview and the material already on YouTube, and turn it into a small set of short cuts plus a written plan for where each one is used.

Problem solved

The strongest asset here is that people who travelled recommend it, and none of that is visible to a stranger comparing travel agencies.

Cost of inaction

The trust argument stays a claim on the website, indistinguishable from every competitor making the same claim.

Benefit

Short, credible proof usable on landing pages, in ads and on social, built from material that already exists.

Done

An inventory of the supplied material with its permission status, the short cuts, and a placement plan naming where each clip goes. Any clip without documented permission stays unpublished and is listed as blocked. 80/20. Three short cuts from the material already on hand.

Charts
flowchart LR
  A[Trust is only a claim on the page] --> B[Cut real traveller footage into short proof] --> C[A stranger sees people like them recommending it]
  
flowchart TD
  S1[Inventory the footage and its permission status] --> S2[Cut only clips with documented permission]
  S2[Cut only clips with documented permission] --> S3[Write the placement plan per clip]
  S3 --> D{Permission documented for every published clip}
  D -- yes --> DONE[Done]
  D -- no --> S2
  
Decision

T-005 — Integrate the Google reviews into the website officially

Not decided
Task

Connect the business profile reviews to the website through the official route so real reviews render on the site instead of being copied in by hand, and rebuild the review-collection form that went missing.

Problem solved

The review collection form has disappeared and reviews are not surfaced on the site, so the strongest third-party proof the business has is invisible exactly where buyers decide.

Cost of inaction

Trust proof stays scattered across platforms, and the page keeps missing the search and ad-quality benefit an official integration brings.

Benefit

Reviews appear automatically, they help the site's search standing, and a better landing page improves how the ad platforms score it.

Done

Reviews render from the official integration in a staging build, the replacement collection form works end to end, and the deploy steps are documented. Going live is a separate approval. 80/20. Reviews rendering in staging on one page.

Charts
flowchart LR
  A[Reviews live only on the profile] --> B[Official integration plus a working collection form] --> C[Proof renders on the page where people decide]
  
flowchart TD
  S1[Confirm profile read access] --> S2[Implement the integration in staging]
  S2[Implement the integration in staging] --> S3[Rebuild the collection form and test a submit]
  S3[Rebuild the collection form and test a submit] --> S4[Document the deploy, leave live for approval]
  S4 --> D{Staging renders live-sourced reviews}
  D -- yes --> DONE[Done]
  D -- no --> S2
  
Decision

T-006 — Take manual control of budget allocation across departures

Not decided
Task

Analyse how the automatic allocation is splitting budget across departures, then produce a recommended manual allocation that funds the departures the business actually needs to fill.

Problem solved

The automatic allocation chased the easiest conversions and piled enquiries onto one autumn departure, while a priority departure got almost none and seats had to be released.

Cost of inaction

Budget keeps following whatever is easiest to sell rather than what needs selling, and departures with real inventory stay quiet.

Benefit

Spend follows the departures that need passengers, and the effect shows within one cycle.

Done

A per-departure breakdown of current spend and enquiries, a recommended allocation with the reasoning, and the exact change list ready to apply on approval. No live change in this task. 80/20. The breakdown plus a one-line recommendation per departure.

Charts
flowchart LR
  A[The algorithm picks which departure gets budget] --> B[Allocate per departure by what needs filling] --> C[Priority departures actually get enquiries]
  
flowchart TD
  S1[Pull spend and enquiries per departure read-only] --> S2[Show how the automatic split behaves today]
  S2[Show how the automatic split behaves today] --> S3[Recommend the manual allocation with reasoning]
  S3[Recommend the manual allocation with reasoning] --> S4[Write the change list, pending approval]
  S4 --> D{Recommendation backed by per-departure data}
  D -- yes --> DONE[Done]
  D -- no --> S2
  
Decision

T-007 — Decide the search strategy: narrower keywords or move the budget

Not decided
Task

Run keyword research against the personas to find whether intent-specific search terms exist in useful volume, then use that evidence to answer whether search budget should stay and narrow, or move to social.

Problem solved

Search brings plenty of cheap clicks on broad destination terms and very few of them reach a form, so the channel looks busy and delivers little.

Cost of inaction

The choice between the two channels keeps being reopened every month without evidence, while broad terms keep absorbing budget.

Benefit

One evidence-backed decision. If search stays, it runs on keywords tied to the personas rather than to the destination name.

Done

A keyword research table with volume and intent per cluster, mapped to personas, plus a written recommendation that names explicitly what is given up either way. 80/20. The keyword clusters plus a one-paragraph recommendation.

Charts
flowchart LR
  A[Broad terms, many clicks, few enquiries] --> B[Research intent-specific clusters per persona] --> C[One evidence-backed channel decision]
  
flowchart TD
  S1[Ground read-only in performance by search term] --> S2[Research clusters and map them to personas]
  S2[Research clusters and map them to personas] --> S3[Write the recommendation and name the tradeoff]
  S3 --> D{Volume evidence exists behind the recommendation}
  D -- yes --> DONE[Done]
  D -- no --> S2
  
Decision

T-008 — Test segmented follow-up messages after an enquiry

Not decided
Task

Turn the single reply template into three persona-keyed variants, each keeping the personal sentence the team already adds by hand, and define how the variants are compared so the winner is known rather than felt.

Problem solved

Every enquirer gets the same template, and the personal touch is added manually by one person, so nothing about what works is ever learned.

Cost of inaction

The step where the business is actually lost, between enquiry and booking, stays untested indefinitely.

Benefit

Within a few weeks the team knows which argument moves this audience, and the winner becomes the default.

Done

Three drafted variants, the rule assigning an enquirer to a variant, the metric compared, the sample size needed before calling a winner, and where results are recorded. Plus a short proposal for getting enquirers to volunteer more detail up front. 80/20. Two variants and a written comparison rule.

Charts
flowchart LR
  A[One template for every enquirer] --> B[Three persona-keyed variants, compared properly] --> C[The team knows which argument converts]
  
flowchart TD
  S1[Read the current template and real replies] --> S2[Draft three persona-keyed variants]
  S2[Draft three persona-keyed variants] --> S3[Define assignment, metric and sample size]
  S3[Define assignment, metric and sample size] --> S4[Propose collecting more detail at enquiry time]
  S4 --> D{Winner decidable from the recorded results}
  D -- yes --> DONE[Done]
  D -- no --> S2
  
Decision

T-009 — Stand up the shared departure-status view

Not decided
Task

Set up a small shared view showing, per departure, how many seats are confirmed, how many enquirers are still undecided and how many seats remain, fed by an extract from the client's own sheet.

Problem solved

Both sides walk into the review meetings without a common picture, so decisions about where to push budget are made from memory.

Cost of inaction

Budget decisions keep being made without knowing which departure has seats left, which is exactly how the priority departure was missed.

Benefit

Both sides open the same view, and the budget conversation starts from facts.

Done

The view exists, refreshes from the client's extract without manual retyping, carries no personal traveller data, and is confirmed correct against one departure the client verifies. 80/20. A static first version covering the next three departures.

Charts
flowchart LR
  A[Each side has its own picture] --> B[One shared per-departure status view] --> C[Budget talks start from the same facts]
  
flowchart TD
  S1[Agree the extract format from the client's sheet] --> S2[Build confirmed, undecided and remaining per departure]
  S2[Build confirmed, undecided and remaining per departure] --> S3[Verify one departure against the client's numbers]
  S3 --> D{One departure verified by the client}
  D -- yes --> DONE[Done]
  D -- no --> S2
  
Decision

T-010 — Make the long contributor bios collapsible on the website

Not decided
Task

Make the contributors section expandable, so each person shows a short summary by default and their full introduction only on click, and nobody's text has to be cut.

Problem solved

Some contributors write two lines and some write a very long introduction, so the section reads unevenly, and cutting someone's own words on their behalf is not wanted.

Cost of inaction

The page keeps looking unbalanced, and the choice stays between a tidy page and someone's own words.

Benefit

Everyone keeps their full text, and the page stays readable.

Done

The section collapses and expands in a staging build, keyboard accessible, verified live at desktop, tablet and mobile widths. Going live is a separate approval. 80/20. Collapse and expand working on desktop.

Charts
flowchart LR
  A[Uneven wall of bios] --> B[Summary by default, full text on click] --> C[Readable page, nobody's text cut]
  
flowchart TD
  S1[Locate the contributors section in the source] --> S2[Implement collapse and expand with keyboard access]
  S2[Implement collapse and expand with keyboard access] --> S3[Verify at desktop, tablet and mobile widths]
  S3 --> D{Verified at all three widths}
  D -- yes --> DONE[Done]
  D -- no --> S2
  
Decision

T-011 — Filter the junk enquiries out of the lead numbers

Not decided
Task

Identify the pattern behind the batches of nonsense enquiries arriving on some days, add protection at the form so they stop, and mark the historic ones so reported enquiry counts reflect real people.

Problem solved

Batches of automated submissions with nonsense addresses land on some days, and they inflate every enquiry count both sides discuss.

Cost of inaction

Every conversion rate calculated from here on is quietly wrong, and the measurement work in T-001 inherits the error.

Benefit

Reported enquiry numbers mean real people, so the conversion rate is worth acting on.

Done

The pattern documented from real submissions, protection in place in staging and verified with a genuine negative control (a submission that should be blocked, and is), and historic junk flagged. No record is ever deleted. 80/20. The pattern documented and historic junk flagged.

Charts
flowchart LR
  A[Bot submissions inflate the lead count] --> B[Block them at the form, flag the historic ones] --> C[Conversion rates describe real people]
  
flowchart TD
  S1[Review recent submissions and document the pattern] --> S2[Add form-level protection in staging]
  S2[Add form-level protection in staging] --> S3[Run a negative control that must be blocked]
  S3[Run a negative control that must be blocked] --> S4[Flag historic junk without deleting anything]
  S4 --> D{A blocked submission proves the filter works}
  D -- yes --> DONE[Done]
  D -- no --> S2
  
Decision