Before we run the audit, we need to make sure we're asking the right questions about the right competitors to the right buyers. This document presents what we've learned about Acme's market — your job is to tell us what we got right, what we got wrong, and what we missed.
Before we measure citation visibility in the work management and project collaboration category, these three signals tell us whether AI crawlers can reach, render, and trust Acme's site. Right now the first signal is a hard blocker — and it sits upstream of the other two.
AI search is reshaping how mid-market teams discover and evaluate work management and project collaboration platforms — buyers increasingly open ChatGPT, Claude, or Perplexity to name vendors, compare capabilities, and build a shortlist before any sales conversation happens; in 6sense's 2025 research, 94% of B2B buyers now use LLMs somewhere in the buying process (6sense, November 2025). For a mid-market challenger in a category anchored by Asana, monday.com, ClickUp, and Jira, establishing GEO visibility early is how a smaller vendor earns a place in answers it would otherwise be left out of — citations compound as AI platforms learn to trust a cited domain, so late movers end up competing against entrenched answers rather than empty space.
This Foundation Review covers three inputs the audit depends on. First, the competitive set — which platforms appear alongside Acme in the queries buyers actually run, and which tier each belongs in. Second, the buyer personas — who evaluates, who signs, who can veto, and therefore how queries should be phrased. Third, the technical baseline — whether AI crawlers can access, render, and extract citable content from the site at all. On that third input there is one unavoidable headline: the site is currently unreachable, and until that is fixed every other technical and content signal is moot. Content gap analysis and citation benchmarking come next, after the audit runs against the inputs you confirm here.
The validation call is a decision-making session with real stakes, because the entire knowledge graph below was inferred rather than observed — the domain never resolved, so nothing could be scraped. Two types of decisions need to happen: (1) input validation — confirming or correcting the personas, competitor tiers, and feature strength ratings that define where you're strong and where you're exposed, all of which currently carry low or medium confidence — and (2) engineering triage — getting the domain live and crawler-ready so the audit has a site to measure. The pre-call checklist at the end of this document aggregates every decision in one place so nothing gets dropped.
Three things to know before you dig in: what this document is for, what you need to do with it, and how to read the confidence badges.
Purpose The Foundation Review validates the knowledge graph that drives the audit's query set — the competitors, personas, features, and pain points we'll use to probe AI platforms about the work management and project collaboration category. Get these inputs right, and the full audit measures what actually matters. Get them wrong, and the audit produces clean data on the wrong questions.
Your Job Read every section. Flag anything you disagree with. The purple callouts (like this one) are the highest-value validation points — each names a specific uncertainty and explains what changes in the audit if your answer differs from our current read. Everything you flag gets resolved at the validation call before query execution begins.
Confidence Badges High means directly observed in reviews, product pages, case studies, or competitor comparisons. Medium means inferred from category patterns or supported by indirect evidence — treat these as our best hypotheses, not conclusions. Low means speculative and specifically flagged for your confirmation. Because the domain never resolved, the entire Acme profile below was inferred rather than observed — so nearly every badge here is Low or Medium, and your corrections at the call carry more weight than usual.
Category, positioning, and name usage shape every query in the audit. The most consequential thing to confirm is which product motion leads — a lightweight board tool or a full cross-functional work management platform.
→ One Product or Two Motions? The KG lists both Acme Boards (a lightweight, flexible Kanban experience that competes with Notion- and Trello-style tools) and the Acme Work Management Platform (a full cross-functional system that competes with Asana, monday.com, and ClickUp). These are two different buying conversations that search very differently. Which leads your pipeline — the simple board tool buyer, or the platform buyer? If it's roughly split, we build two parallel query clusters ("simple kanban/board tool" vs "enterprise work management platform") and weight the persona set accordingly; if one clearly dominates, we trim the other and reallocate the query budget. (Note: this entire profile is llm_inference at low confidence — the domain never resolved, so even the category framing is our hypothesis, not observed fact.)
5 personas: 3 decision-makers carrying veto power (VP Operations, IT Director, COO), 1 evaluator (Head of PMO), and 1 influencer (Marketing Operations). These personas shape how every buyer query is phrased.
Critical Review Area Personas drive query construction more than any other KG input. If a persona's influence level is wrong, the queries we test under their role will miss — or worse, simulate the wrong buyer. Because the Acme domain never resolved, there is no public review or case-study data behind any of these personas — all five are llm_inference at low confidence, inferred from how mid-market work-management deals typically run. Every one of them is a candidate for correction.
Data Sourcing Note Normally name, role, department, seniority, influence level, veto power, and technical level are KG-sourced from scraping and review mining, while role descriptions, buying jobs, and query focus areas are synthesized. Here, because nothing could be scraped, both layers are inferred — the structured fields are pattern-based hypotheses, not observations. Flag anything that doesn't match who actually shows up in Acme deals.
→ Is Dana the economic buyer who signs, or the champion who builds the case for the COO (Jordan Hale) to sign? If she signs, her adoption-and-visibility criteria anchor the decision-stage queries; if she only champions, we weight the decision-stage set toward the COO's strategic framing instead.
→ Does the Head of PMO control a tooling budget line — making him a de facto decision-maker — or does he only recommend while an ops/exec buyer signs? If he holds budget, we reclassify him as a decision-maker and add validation-stage queries around his approval criteria; if he only recommends, his cluster stays weighted below the veto-holders.
→ Does IT actually veto the platform choice, or only gate it on SSO/SCIM and security (the Admin & Security capability)? If it's a full veto, we add an IT evaluation cluster at decision stage; if she only security-gates, we keep her queries to a narrow admin/security band and let the ops buyers drive the platform decision.
→ Is Marketing Operations a genuine buying stakeholder in Acme deals, or primarily a heavy user whose team is the wedge? If she's a stakeholder who shapes the shortlist, we keep a marketing-workflow query cluster; if she's just the entry-point user, we fold her queries into the broader adoption theme and don't run them as a distinct buyer.
→ Both the COO and the VP of Operations (Dana Whitfield) carry veto and both sit in the operations leadership lane — are these two distinct buyers, or does the COO only enter above a spend threshold while Dana owns the everyday decision? If distinct, we run separate executive-tier and operational-tier query clusters; if the COO is just the escalation signer, we merge them to avoid double-counting one buying motion.
→ Missing Personas? Three roles often show up in mid-market work-management deals that aren't in the KG — do they appear in yours? (1) CFO / Finance or Procurement (the per-seat "pricing creep" pain in this KG usually means someone in Finance scrutinizes the spend — is benefits-of-tooling a Finance-signed line?); (2) a frontline Team Lead / end-user champion (in work management, the team that has to live in the tool every day frequently makes or breaks adoption and the renewal); (3) a Security / Compliance owner distinct from IT admin (if data governance is a separate buying conversation from provisioning). These are validation probes, not gaps — who else shows up in your deals?
7 competitors: 4 primary + 3 secondary. Tier assignments determine which competitors appear in head-to-head queries vs. category-awareness queries.
Why Tiers Matter Primary competitors drive head-to-head queries like "Acme vs Asana" or "best monday.com alternatives for mid-market teams" — roughly 6–8 queries per primary pair, so ~24–32 direct-differentiation queries across the 4 primaries. Secondary competitors appear in category-awareness queries only. All four primaries (Asana, monday.com, ClickUp, Jira) currently carry medium confidence because they were assigned from category listings, not observed in Acme's deals. The one we're most uncertain about is Jira — it's an engineering issue tracker, a different buying conversation from cross-functional work management — so confirm whether it truly belongs head-to-head.
→ Validation Questions (1) Missing vendors: Do Trello, Airtable, Basecamp, Linear, or Microsoft Planner/Project show up in your deals but not in this list? (2) Jira tier: It's our most questionable primary — does Jira actually appear head-to-head in your deals, or is it really an adjacent engineering tool that belongs in secondary/category-awareness? Moving it shifts ~6–8 queries. (3) Notion's tier: If Acme Boards is your lead motion, Notion may deserve promotion to primary — it's the closest lightweight-board competitor. (4) Irrelevant: Is any listed competitor never actually seen in your deals today? (All four primaries are medium-confidence category assignments, so any of them is fair game to re-tier.)
10 buyer-level capabilities mapped: 4 strong, 4 moderate, 2 weak. Buyer language determines how capability queries get phrased in the audit.
Plan projects, assign tasks, set due dates, and see what everyone is working on in one place
Switch between Kanban boards, lists, Gantt timelines, and calendars without re-entering work
Discuss work in context with @mentions, attachments, and approvals instead of scattered email threads
Get non-technical teams productive in days without a consultant or long training
Automate handoffs, status changes, and notifications with rules instead of manual updates
Build real-time dashboards to track progress, workload, and on-time delivery across teams
Connect to Slack, Google Workspace, Microsoft 365, and the rest of our stack without custom code
Enforce SSO, granular permissions, and provisioning so IT can manage access at scale
See who is overloaded and balance workload across the team before deadlines slip
Roll up many projects into one portfolio view to track strategic initiatives and budgets
Feature Prioritization Four capabilities are rated Strong: Task & Project Tracking, Flexible Views, Collaboration & Comments, and Ease of Use & Onboarding. The audit tests all 10, but competitive-differentiation queries will emphasize 3. Which of these best represents where Acme wins deals? Our working hypothesis is Ease of Use & Onboarding (it's tied to the "rollout failed / half the team never logged in" pain), Task & Project Tracking (tied to tool sprawl), and Flexible Views (tied to missed deadlines) — but Collaboration & Comments could displace one if "everything lives in scattered email and chat" is the sharper wedge in your deals.
→ Feature Validation (1) Strength accuracy vs. named competitors: We rated Task Tracking, Flexible Views, Collaboration, and Ease of Onboarding strong — are those genuinely where you beat Asana, monday.com, and ClickUp, or is the real edge somewhere we under-rated? Every rating here is llm_inference / low confidence. (2) Two weak features carry high-severity pain: Resource & Capacity Management is weak yet anchors the high-severity "missed deadlines / can't see the bottleneck" pain, and Portfolio & Cross-Project Management is weak yet anchors the high-severity "can't see whether initiatives are on track" exec pain — if these are real gaps, they're exactly where competitors will out-cite you, so confirm whether you're truly weak there or have depth we couldn't see. (3) Merge candidates: Do buyers evaluate Reporting & Dashboards and Portfolio & Cross-Project Management as one capability, or separately?
9 pain points: 4 high, 5 medium severity. Buyer language is how queries will be phrased — if the framing doesn't match how your prospects describe their problem, the audit will miss.
→ Pain Point Validation (1) Severity accuracy: 4 of 9 are rated high. Is "failed rollout / low adoption" really as urgent as "no single source of truth," or is adoption a post-purchase worry rather than a buying trigger? The answer changes which pains we lead queries with. (2) Buyer language: Does "half the team never logged in again" match how your buyers describe the adoption risk, or do they frame it as "we need something people will actually use"? The phrasing changes which queries hit. (3) Missing pains: Three that often surface in this category — change-management/onboarding fatigue from switching tools yet again, integration-maintenance burden when connectors silently break, and vendor lock-in / migration risk when leaving an incumbent like Asana or monday.com. Any of these resonate with your deals?
Layer 1 analysis of e2e-test-acme.com — findings your engineering team can triage before the validation call. These are the technical and structural issues that determine whether AI crawlers can discover and extract citable content.
Critical — Engineering, Start Immediately There is one blocker that supersedes everything else: the domain e2e-test-acme.com does not resolve (DNS NXDOMAIN), so there is no host serving content and no page any AI crawler or human can reach. Two further findings — robots.txt and sitemap.xml both unreachable — are direct downstream consequences of the same root cause and resolve once the host is live. The single action engineering should take now: point the domain at a live host (register/confirm the domain, add A/AAAA DNS records, stand up a web server with valid TLS), then re-run the site analysis once the homepage returns HTTP 200. Crawler access cannot be evaluated and AI visibility is zero by definition until this is fixed.
What we found: The seed domain e2e-test-acme.com returns DNS NXDOMAIN at every layer checked: OS resolver (nslookup/host), direct curl ("Could not resolve host"), the web-search gateway (no live site indexed; only unrelated ACME entities), and a fetch of https://e2e-test-acme.com/robots.txt (ECONNREFUSED). No A/AAAA record exists, so there is no host serving content.
Why it matters: If a domain does not resolve, no AI crawler (GPTBot, ClaudeBot, PerplexityBot, Googlebot, etc.) and no human visitor can reach any page. AI visibility is zero by definition — there is nothing for an LLM to retrieve, cite, or index. Every downstream signal (robots rules, sitemap, schema, content depth, freshness) is moot until the domain resolves to a live host.
Recommended fix: Point e2e-test-acme.com at a live host: register/confirm the domain, add A/AAAA (or CNAME) DNS records, and stand up a web server with valid TLS. Re-run the full site analysis once the homepage returns HTTP 200.
What we found: A request for https://e2e-test-acme.com/robots.txt failed with a connection error (ECONNREFUSED) because the host does not resolve. robots.txt does not exist in any retrievable form. Crawler access could not be evaluated; all seven tracked AI crawlers are reported as "not_mentioned" by default, which here reflects "could not be assessed" rather than an affirmative allow.
Why it matters: robots.txt is the first file every AI crawler requests. Its absence is not itself a block — when a domain has no robots.txt, crawlers treat the site as implicitly allowed — but here the file is unreachable purely because the host is down, so crawler policy is undefined and untestable. Once the domain resolves, a robots.txt should be published with explicit allow rules for AI crawlers.
Recommended fix: After the domain resolves, publish a robots.txt at the site root that explicitly allows the AI crawlers you want citation visibility from (GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, Googlebot) and references the sitemap. Re-verify crawler status after deployment.
What we found: A request for https://e2e-test-acme.com/sitemap.xml could not be completed because the host does not resolve. No sitemap, sitemap index, or child sitemaps were retrievable, and the homepage could not be fetched for navigation crawling. Page discovery returned zero URLs; the proposed page list is empty.
Why it matters: The sitemap is the primary discovery surface for AI crawlers and for this analysis. With no sitemap and no reachable homepage, there is no way to enumerate commercially relevant pages (product, pricing, comparison, blog) — exactly the content most cited by LLMs in vendor-evaluation queries.
Recommended fix: Once the domain resolves, publish a sitemap.xml (or sitemap index) listing all canonical, indexable URLs with accurate lastmod timestamps, reference it from robots.txt, and submit it to Google Search Console. Then re-run discovery to build the scored content inventory.
The following item could not be assessed through our analysis method (rendered markdown). We recommend your engineering team verify it manually once the site is live, before the validation call.
What to check: No pages could be fetched because the host does not resolve, so no page-level signals were observable. Independently of reachability, this analysis method relies on rendered markdown rather than raw HTML — meaning JSON-LD schema markup, meta descriptions, Open Graph tags, canonical URLs, and client-side-rendering (CSR) status are not directly assessable even for live pages. These signals materially affect whether AI crawlers can parse and cite a page.
Recommended action: After the domain resolves, verify schema markup, meta descriptions, OG tags, canonical tags, and CSR status using browser developer tools or a crawler such as Screaming Frog — viewing source with JavaScript disabled to confirm content renders server-side.
Coverage Note The analysis covered 0 pages — none could be reached because the host does not resolve (DNS NXDOMAIN). Every score above is therefore "Unable to assess," not a low score: there was simply nothing to measure. All quality metrics (heading hierarchy, content depth, freshness, extractability, schema) become assessable only after the domain is live and pages return HTTP 200, at which point we re-run the full Layer 1 analysis to build the scored content inventory.
Why Now
Once the domain is live and the validation call resolves the open questions, the full audit will measure citation visibility across buyer queries in the work management and project collaboration space — including "best work management software for mid-market teams," "Asana vs monday.com alternatives," "easy-to-adopt project tracking that replaces spreadsheets and chat," and "work management platform with SSO and no-code automation." You'll see exactly which queries return results that include Asana, monday.com, ClickUp, or Jira but not Acme — and what it would take to appear in them. Getting the domain resolving and crawler-ready before the audit runs is what makes any of that measurable in the first place.
45–60 minutes. We walk through this document together, resolve every purple question, confirm competitor tiers, and lock the query set before execution begins.
We generate buyer queries across the selected AI platforms (ChatGPT, Claude, Perplexity, Google AI Overviews) — persona-weighted, category-specific, and head-to-head against your primary competitors.
Visibility analysis, competitive positioning, and a prioritized three-layer action plan: technical fixes, content priorities (now informed by what actually costs citations), and category/narrative moves.
Start Now — Engineering The Layer 1 fixes don't depend on the validation call and are the prerequisite for everything else: (1) point e2e-test-acme.com at a live host — register/confirm the domain, add A/AAAA (or CNAME) DNS records, and stand up a web server with valid TLS so the homepage returns HTTP 200; (2) once it resolves, publish a robots.txt at the site root that explicitly allows GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, and Googlebot, and references the sitemap; (3) publish a complete sitemap.xml of canonical URLs with accurate lastmod values and submit it to Google Search Console. Once the homepage returns HTTP 200, tell us and we re-run the full Layer 1 analysis to build the scored content inventory and verify crawler access — and engineering should then manually verify page-level signals (schema, meta/OG tags, canonical, and server-side rendering with JavaScript disabled).
Two jobs before we meet. The questions on the left require your judgment — no one knows your business better than you. The engineering tasks on the right don't require the call at all.
llm_inference (low/medium); confirm or correct personas, tiers, and feature/pain ratings before query generation