The SaaS Website Diagnostic Your Agency Can Reuse Without Making Clients Look Alike

Summary

How many times this quarter have you run the exact same discovery call—same questions about the product, the customer, the competitor—for two clients who insisted they were completely different? You already know the answers will be different, but the jobs each SaaS site has to do are not. Every SaaS product website is a small set of machines that run the same tasks: explain what the product does, show what it costs, tell developers how to integrate, answer the objections that stop a purchase, and prove the company is credible. A repeatable diagnostic that audits those five jobs will survive contact with any client, because the jobs don't change. The system you build around it is what lets you move from one engagement to the next without starting from zero. It takes less time than your current discovery process, it gives the client a clear reason to trust you, and it produces a deliverable that doesn't look templated because the questions are standard but the answers are specific.

How many times this quarter have you run the exact same discovery call—same questions about the product, the customer, the competitor—for two clients who insisted they were completely different? You already know the answers will be different, but the jobs each SaaS site has to do are not. Every SaaS product website is a small set of machines that run the same tasks: explain what the product does, show what it costs, tell developers how to integrate, answer the objections that stop a purchase, and prove the company is credible. A repeatable diagnostic that audits those five jobs will survive contact with any client, because the jobs don't change. The system you build around it is what lets you move from one engagement to the next without starting from zero. It takes less time than your current discovery process, it gives the client a clear reason to trust you, and it produces a deliverable that doesn't look templated because the questions are standard but the answers are specific.

'My clients are too different for one system'

Run the same five-point diagnostic on every client before you write a word of copy or open a design tool. The differences that make your clients special—industry, audience, pricing model—sit on top of a shared foundation. A payroll SaaS and a social-media scheduling tool have nothing in common except the five jobs every page is doing. If you audit for those jobs, you will find the same patterns in the same places.

Page or section	What your client usually asks for	What is actually happening on the page
Feature showcase	'Show every feature we built'	Showing the outcome a user gets, not just the function. Visuals like screenshots, GIFs, or videos should demonstrate a moment the product changes the way someone works.
Pricing	'Make the prices easy to read'	The buyer is forced to decide which plan is for them. Tiers need to read as a progression that guides a choice, not a flat list of prices.
API documentation	'Our developers will find that in the docs'	Often the first test a developer runs when evaluating whether the product can be trusted. Clarity here is a feature, not a nicety.
FAQ section	'Answer questions so support calls drop'	The last thing a buyer reads before clicking a button. It should handle pricing objections and edge cases, not just generic company questions.
Social proof	'Put the logos up'	The evidence that the claims made earlier are true. Logos and testimonials are trust indicators, not decoration.

A diagnostic is not a template. It is a set of questions you ask of every page: does this make the buyer understand what the product does, does it make the next step obvious, does it answer the objection that is currently blocking the sale? When you ask these questions with a client present, the client sees you as the person who understands their market, rather than as the tenth agency that showed a slide deck. The research on SaaS websites points to companies like HubSpot, Slack, and Zendesk as examples of well-organized FAQ sections, and to Stripe, GitHub, and Twilio as standards for documentation clarity. None of those companies got there by treating the FAQ as a stack of support tickets. They treated it as a conversion surface. That is the attitude your diagnostic needs to bring to every client.

Consider a client who sells inventory software and another who sells payroll software. The diagnostic often turns up the same three gaps: the feature page mentions modules instead of outcomes, the pricing page doesn't justify the jump between plans, and the FAQ answers support questions rather than purchase hesitations. Because you have seen these gaps in both, you know exactly what to ask for in the design stage. The client sees a process that is specific, not generic. Write the diagnostic as a one-page PDF with a score from 1 to 5 for each job, and a note for each. Share it with the client before the design kickoff. This gives you a shared vocabulary and turns the audit into a deliverable you can charge for. This is the core of a repeatable system, and we have a separate walkthrough of how to set that system up here.

'It'll make our work look like everyone else's'

Standardize the questions you ask, not the answers you ship. The diagnostic gives you a scoring rubric, not a layout. The research on SaaS feature showcases shows they use visuals like screenshots, GIFs, or videos—but the content of those visuals is different for every product. The salary-reporting feature in an HR tool and the barcode-scanning feature in inventory software will never look alike. What remains constant is the question you pose to your strategic mind: 'Does this page show the outcome, or just the function?'

A doctor's intake form does not make all diagnoses the same; it makes the doctor reliable. Your framework is the intake form. The client still gets a custom website, but you get a diagnostic that is repeatable. The thing that will actually make your work look generic is the lack of a diagnostic—because without it, you fall back on the same hero image, same three-column features layout, same homepage structure you used for the last project just to move fast. The diagnostic forces you to justify the structure from the evidence, so each site is structurally different where it needs to be.

In practice, this means the diagnostic might tell you to start one client's feature page with a video of an import wizard and another's with a GIF of a drag-and-drop report builder. The page structure stays the same, but the assets, copy, and pacing are unique. The client sees custom work; you see a repeatable process. When you present the diagnostic to a client, you are demonstrating that you know what every SaaS site must do. That is a stronger pitch than 'we'll create a one-of-a-kind design.' The design is the consequence of the diagnosis, not the starting point.

'We don't have time to audit every page'

Do the focused 90-minute version, not a full audit. Most agency discovery processes are already an audit, just an unstructured one. You spend forty-five minutes on a discovery call that covers background, competitors, and 'what do you want out of this,' then you spend weeks reacting. The diagnostic flips that: you score the five jobs, list the highest-leverage fixes, and move to design. It saves time because you stop re-doing work after the first design review. The cheapest fixes are the ones you make before anyone sees pixels.

Here is a concrete 90-minute split: block one (30 minutes) reviews the homepage and feature page for the five jobs. Block two (30 minutes) skims the pricing page and FAQ. Block three (15 minutes) checks whether the API docs answer 'can I get the data out,' and the last 15 minutes list the top fixes and the owner for each. You do not need to read every page top to bottom; you need to find whether the job is being done. If the pricing page has no FAQ, the design will be approved faster if you catch that before you mock up the fourth pricing column. If the API docs are written to an internal standard rather than the developer's standard, you know it before you brief the copywriter.

In one engagement, the diagnostic surfaced that the target buyer was terrified of data migration. The FAQ we added for that answer cost two hours of writing. Without the diagnostic, that fear would have followed us through design, through development, and into a post-launch support overload. The 90-minute version is not a phase that precedes the project; it is the first phase of the project. It also gives you an honest way to estimate: you leave the session with a list of what exists and what doesn't, so the proposal you write is built on evidence rather than guesses.

'My non-technical client doesn't need API docs'

Use a decision tree, not a checklist: if the product has a public API or an integration story, API docs are a core page; if not, consciously skip them. The research on API docs is blunt: companies like Stripe, GitHub, and Twilio set the standard for documentation clarity because their developers are effectively the buyers. If your client has a developer-facing integration, the docs are not a developer convenience; they are a trust device that sits beside the pricing page. A non-technical customer may never look at them, but the developer evaluating a purchase absolutely will.

The decision tree is part of the system. When the client says 'we don't have a developer audience,' ask one question: 'does any part of your onboarding require a developer to wire the product into another system?' If yes, the docs stay. If no, you skip them and put the effort into the FAQ and social proof. Apply the same logic to social proof: for one client, a row of logos is enough; for another, a detailed testimonial with measurable outcomes is required. The diagnostic tells you which, rather than defaulting to every logo you could collect. That choice is what makes the framework repeatable without being rigid. If you need to work out what 'clarity' means in practice, this guide to API documentation walks through the structure.

'But my client wants a feature list, not outcomes'

When the client says they want to show off their features, ask them to name the user task each feature unlocks. The common assumption is that the feature showcase is where you win the sale. The diagnostic suggests otherwise: in a typical SaaS site, the pricing page is where the final mental math happens, and the FAQ is where the last objection is resolved. The feature showcase is essential, but its job is a narrow one—to show the moment the product becomes valuable. A long list of features with a paragraph under each one does not do that.

Clients resist this because a list feels tangible and easy to approve. But a page of fifty features produces a skimming visitor, and a visitor who skims your feature page has already moved their attention to the pricing table. Your system's job is to make the client comfortable with the tradeoff: you are not removing features, you are moving them to where they will be read. A well-placed FAQ that says 'we integrate with the tools you already use' often does more work than a features page that says the same thing under the wrong heading. This is the nuance most articles skip, and it is precisely the kind of tradeoff a diagnostic can make explicit.

The diagnostic also gives you a defensible reason to push back on scope creep. When a client asks to add another row of features to the homepage, you can point to the table and say 'that page's job is to show outcomes, not catalog functionality.' A generic page builder could generate a features grid, but it cannot decide whether the grid should be replaced by a video or an FAQ. That decision is the real product, and it is the reason a framework does not commoditize your work.

'We already have an internal process'

If your agency has a homepage process or a pricing page checklist, the objection is usually about not wanting to replace it. You don't have to. The five-job diagnostic is not a replacement for your creative process; it is a front-end that feeds it. The problem with most internal processes is that they are invisible. They live in the senior designer's head. The diagnostic externalizes the process so a junior team member can run the first pass, and you can review it in minutes. That is the repeatability you actually need at an agency with multiple clients.

A visible process also changes the conversation with clients. Instead of 'we have a proprietary design process,' you can say 'we run a diagnostic against the five jobs every SaaS site has to do, and then we design around the findings.' The first sentence is a black box that makes clients nervous. The second is a clear method that invites them in. The diagnostic becomes part of your sales story, not just a production tool.

'The client says the current site is fine'

The diagnostic still works if the client wants nothing more than a refresh. It gives you a baseline. You score the current site and show that a specific page is failing a specific job. You can say, 'Your FAQ page is organized, but it doesn't answer the question your sales team hears every week,' and that is a fact-based reason to change, not an aesthetic preference. This is often the gentlest way to start a redesign: you are not telling the client their site is ugly, you are telling them one job is not being done.

This also protects you from the common failure where a client insists on keeping a beloved homepage element that hurts conversion. The diagnostic gives you the vocabulary to say 'that element is not doing any of the five jobs,' and the client can see the evidence. The objection is no longer a matter of taste.

The diagnosis is the product

Repeatability is not about squeezing every client into the same template. It is about running a standard process that surfaces what is unique about each client. The five-job diagnostic takes less than two hours, gives your team a common language, and gives the client a clear list of decisions. The agency that can promise a consistent diagnostic can land a client in a week and deliver in a month, not because the work is easier but because the discovery is predictable. And when the client asks why you need to ask so many questions, the answer is simple: you are not auditioning, you are diagnosing.

For a deeper look at how the feature showcase and pricing page should work together, and why the myths around them persist, see this myth-busting guide.