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.
J/K to move between tasks and open the one you land on, to see its cards. Pick one option per task, then hit Submit decisions at the bottom right. Keys: 1 delegate, 2 drop, 3 idea, 4 ask first, 0 clear, J/K to move and open.! to make it a hard requirement it cannot ignore.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.
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.
Budget keeps being judged by lead counts that include bot submissions, while the real bottleneck after the enquiry stays invisible.
One shared answer to whether the spend produced bookings, and a named bottleneck instead of a guess.
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.
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
(layout preview — real questions are generated by the new pipeline)
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.
Ads, website and follow-up emails speak to everyone at once, so nothing reads as written for me.
Segmentation, landing pages and email variants all stay blocked, because none of them can be written without the personas.
One reference every piece of communication builds on, instead of re-deriving the audience each time.
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.
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
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.
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.
The largest owned audience the business has keeps eroding while producing almost no traffic.
The existing list starts producing enquiries without buying a single extra click.
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.
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
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.
The strongest asset here is that people who travelled recommend it, and none of that is visible to a stranger comparing travel agencies.
The trust argument stays a claim on the website, indistinguishable from every competitor making the same claim.
Short, credible proof usable on landing pages, in ads and on social, built from material that already exists.
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.
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
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.
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.
Trust proof stays scattered across platforms, and the page keeps missing the search and ad-quality benefit an official integration brings.
Reviews appear automatically, they help the site's search standing, and a better landing page improves how the ad platforms score it.
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.
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
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.
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.
Budget keeps following whatever is easiest to sell rather than what needs selling, and departures with real inventory stay quiet.
Spend follows the departures that need passengers, and the effect shows within one cycle.
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.
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
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.
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.
The choice between the two channels keeps being reopened every month without evidence, while broad terms keep absorbing budget.
One evidence-backed decision. If search stays, it runs on keywords tied to the personas rather than to the destination name.
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.
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
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.
Every enquirer gets the same template, and the personal touch is added manually by one person, so nothing about what works is ever learned.
The step where the business is actually lost, between enquiry and booking, stays untested indefinitely.
Within a few weeks the team knows which argument moves this audience, and the winner becomes the default.
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.
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
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.
Both sides walk into the review meetings without a common picture, so decisions about where to push budget are made from memory.
Budget decisions keep being made without knowing which departure has seats left, which is exactly how the priority departure was missed.
Both sides open the same view, and the budget conversation starts from facts.
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.
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
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.
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.
The page keeps looking unbalanced, and the choice stays between a tidy page and someone's own words.
Everyone keeps their full text, and the page stays readable.
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.
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
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.
Batches of automated submissions with nonsense addresses land on some days, and they inflate every enquiry count both sides discuss.
Every conversion rate calculated from here on is quietly wrong, and the measurement work in T-001 inherits the error.
Reported enquiry numbers mean real people, so the conversion rate is worth acting on.
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.
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