Jobs-to-Be-Done Keyword Strategy for SaaS

Why feature keywords fail SaaS companies

Most SaaS keyword strategies are built around the product's features — "project management software", "time tracking tool", "CRM with email automation" — and they fail for a structural reason: the buyer does not search for the feature until late, and by then the search is a comparison between vendors the buyer already knows. Feature keywords are where you compete with every funded competitor on the same page, and where AI Overviews now summarise the category and hand the click to whichever brands are cited.

Jobs-to-Be-Done (JTBD) keyword strategy starts earlier and elsewhere. The buyer has a job — close the books faster, stop losing deals to slow follow-up, get a team of contractors to log hours without chasing them — and a set of struggles that job creates. Those struggles produce searches long before a category name does, and they are searches with almost no vendor competition because vendors do not think in the buyer's language. Mapping them is the difference between a content programme that produces sign-ups and one that produces traffic reports.

The evidence for the shift is in the click data. Ahrefs' December 2025 study of 300,000 keywords found that the top organic result now earns 1.6% of clicks on queries with an AI Overview, down from 7.3% two years earlier. The queries that trigger overviews are disproportionately informational and problem-framed — precisely the JTBD layer. That does not make the layer worthless; it means the goal on those queries is to be the source the overview cites and the page the buyer opens next, not to rank first for its own sake.

This article sets out the JTBD keyword method we use with SaaS clients: how to extract jobs, how to translate them into query language, how to layer intent so the whole journey is covered, and how to build the pages so they earn both the human click and the AI citation. It builds on our earlier work on topical authority for SaaS, which covers the cluster architecture; here the focus is the vocabulary that goes into it.

JTBD versus feature keywords: what actually changes

A feature keyword names what the product does; a job keyword names what the buyer is trying to accomplish; a struggle keyword names what is going wrong while they try. All three exist in search demand, but their volumes, competition and intent are different enough that treating them as one list produces the wrong content. The table below shows the three layers for a single SaaS category, invoicing software for agencies, using the kind of queries that appear in keyword tools and Search Console for that market.

The commercial logic follows from the table. Category queries are expensive to rank for and increasingly answered above the fold. Job and struggle queries are cheaper, closer to the buyer's own words, and — because so few vendors write for them — often winnable with a single excellent page. A SaaS company that owns twenty job and struggle queries in its niche has built a top-of-funnel that its competitors' category pages cannot reach, and the vocabulary of those pages is what an AI system quotes when a user describes the same struggle in a prompt.

The trade-off is measurement. Job-layer traffic does not convert on the first visit at category-page rates, so the programme needs attribution that follows a reader from a struggle article to a trial weeks later. If the analytics cannot do that, the JTBD layer will look like a cost and be cut before it compounds. We set up the tracking before the first article, not after.

Extracting the jobs: interviews, tickets and the search console

Jobs are extracted from customers, not brainstormed by marketers. Three sources give the raw material, and each has a specific yield. Win interviews — ten to fifteen conversations with recent customers about the moment they decided to look for a solution — produce the job statements and the emotional language around them. Support and sales tickets, exported and clustered, produce the struggles in the customer's own words at volume. Search Console query data and on-site search logs show which of those phrases people already type, and in what form.

The output of the extraction is a job map: each job written as a verb-object-context statement ("reconcile client payments against invoices at month end"), the struggles that appear along the way, the outcomes the customer uses to judge success, and the exact phrases they used. We keep the phrases verbatim. A marketer would say "invoice reconciliation"; the customer said "working out who has actually paid". The second is what gets searched, and it is what an assistant repeats back when asked the same question.

1. 1
   Run ten to fifteen win interviews

   Ask what was happening the week they started looking, what they tried first, and what would have made them stop searching. Record and transcribe.
2. 2
   Export and cluster support tickets

   Six to twelve months of tickets, grouped by the job they relate to. Count frequency. Pull verbatim phrases.
3. 3
   Mine Search Console and on-site search

   Filter queries containing verbs (how, why, stop, track, fix) and struggle words (late, missing, wrong, manual). These are your existing footholds.
4. 4
   Write the job map

   One row per job: statement, struggles, success outcomes, verbatim phrases, and the product capability that addresses it.
5. 5
   Validate demand per phrase

   Run every verbatim phrase and its variants through a keyword tool. Zero-volume phrases still go in the map if tickets show them; volume tools undercount long queries.

The last step matters more than it looks. Keyword tools systematically under-report long, conversational queries, and the JTBD layer is made of them. A phrase that shows zero volume but appears in thirty support tickets is real demand; we plan for it and let Search Console confirm the volume after publication. The reverse — a high-volume phrase that no customer has ever used — is usually a category term in disguise and belongs in the feature layer.

Translating jobs into query language and intent tiers

A job statement becomes a keyword cluster by expanding it across four query forms: the struggle ("why are my clients paying late"), the method ("how to get agency clients to pay on time"), the tool ("automatic payment reminders for invoices") and the evaluation ("invoice reminder software vs manual follow-up"). Each form has a different intent and needs a different page. The struggle form wants a diagnostic article; the method form wants a process guide with templates; the tool form wants a capability page that shows the product doing the job; the evaluation form wants an honest comparison.

Intent tiers are how those forms map to the funnel. We use a simple three-tier model for SaaS: TOFU is struggle and early method queries, answered by editorial content with no product pitch beyond a contextual mention; MOFU is late method, tool and template queries, answered by content that demonstrates the product performing the job; BOFU is evaluation, pricing and alternative queries, answered by pages that make the comparison explicitly. The mistake most SaaS sites make is writing every page as BOFU — a product pitch wearing an informational title — which fails the TOFU reader and gets filtered by Google's helpful-content systems as thin.

The tiering also decides internal linking. Every TOFU page links forward to the MOFU page for the same job, every MOFU page links to the BOFU comparison, and every page links to the pillar for that job. That is the cluster structure from our topical authority work, applied with JTBD vocabulary — and it is the structure that turns a struggle search into a trial without the reader ever seeing a category term.

Building pages that win the click and the citation

A JTBD page has to satisfy two readers at once: the human who typed a struggle, and the AI system deciding which source to cite when someone describes the same struggle in a prompt. Both reward the same structure. Open with a direct answer of forty to sixty words that names the job and the cause of the struggle. Follow with sections whose first sentences can stand alone as quotations. Use the customer's verbatim phrases as headings. Include at least one piece of original data — ticket frequencies, a benchmark from your own customer base, a survey — because original data is the strongest driver of citation in every study we have seen and something a competitor cannot copy.

Product mentions belong where the job is being done, not at the top. On a struggle page, the product appears in the method section as one of the ways to do the job, with a screenshot of the job being done rather than a feature list. On a method page, it appears as the worked example. On a tool page it is the subject. This is not modesty; it is what keeps a TOFU page from being classified as a sales page and losing the query it was built for.

For a B2B SaaS client we worked with, the organic growth documented in our case study came from exactly this shift: a content programme rebuilt from the jobs customers described rather than the features the product team listed, with the cluster structure and internal linking to carry a reader from a struggle to a trial. The category pages did not disappear — they still capture late-stage demand — but they stopped being the whole strategy.

A worked example: one job, four pages

Take one job from the agency-invoicing map: "get clients to pay retainer invoices on time". The struggle phrases from tickets were "clients paying late", "chasing invoices every month" and "awkward payment reminder emails". The method phrases were "how to get agency clients to pay on time" and "payment terms for retainer clients". The tool phrases were "automatic invoice reminders" and "recurring invoicing with reminders". The evaluation phrases were "invoice reminder software vs accountant follow-up" and "[competitor] alternative for agencies".

That job produces four pages. A diagnostic article on why agency clients pay late, built on ticket data (how often each cause appeared) and interview quotes, with a single contextual link to the method guide. A method guide on payment terms, reminder cadence and escalation, with downloadable email templates and a worked example inside the product. A capability page showing recurring invoices and automatic reminders doing the job, with screenshots and a short video. A comparison page that puts the product against manual follow-up and the named competitor on the outcomes the interviews surfaced: days-to-paid, hours spent chasing, client friction.

The pages link forward in that order and all four link to the job pillar. The struggle article is the one most likely to be cited by an assistant when a founder types "my agency clients keep paying late", the method guide is the one most likely to be bookmarked, and the comparison page is the one that starts the trial. Measured as a cluster, the job is worth far more than any of its pages ranked alone — and it was built from language no competitor's feature list contains.

Measuring a JTBD programme without fooling yourself

The right metrics for a JTBD keyword programme are assisted conversions, citation share and job-cluster coverage — not rankings for head terms. Assisted conversions require a path analysis in GA4 or your product analytics that credits the struggle article a reader landed on three weeks before starting a trial. Citation share is the proportion of AI Overviews and assistant answers for your job queries that name your page or brand; it can be tracked manually for a fixed query set each month. Cluster coverage is the share of jobs in the map that have all four query forms published and interlinked.

Two warning signs tell you the programme is drifting. The first is TOFU pages that start ranking for category terms instead of struggle terms — usually a sign the product pitch has crept upward and Google is reading the page as commercial. The second is a job cluster with traffic but no assisted conversions after ninety days, which usually means the MOFU page is missing or the internal link to it is buried. Both are fixed with editing, not with more articles.

• Track a fixed set of 30–50 job and struggle queries monthly: rank, AI Overview presence, and whether you are cited.
• Report assisted trials by landing-page cluster, not by keyword; a struggle article that assists five trials a month is outperforming a category page with ten times the traffic.
• Review the job map quarterly against new tickets and interviews; jobs change when the product or the market does.
• Retire or merge pages whose query forms overlap; one strong page per form per job beats three thin ones.
• Keep category pages, but measure them separately — they answer a different question and compete in a different market.

Handled this way, the JTBD layer becomes the asset that feature pages can never be: a body of content in the buyer's own language, cited by the systems that now sit between the buyer and the search results, feeding a comparison page that closes. It is the approach behind our data-driven SaaS SEO service, and it is the reason the SaaS programmes we run report trials rather than traffic.

Frequently asked questions