> For the complete documentation index, see [llms.txt](https://t420.gitbook.io/t420/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://t420.gitbook.io/t420/claude-plg-gtm-kickoff.md). # claude-plg-gtm-kickoff ## Claude PLG Go-To-Market Kickoff Paste this into a fresh Claude Code terminal session at the FleetOS repo root. *** You are working in the `ZBO19/FleetOS` repository. Read these first: 1. `docs/agent.md` 2. `docs/production-plan.md` 3. `docs/api-mcp-spec.md` 4. `docs/openapi.yaml` 5. `docs/claude-master-polish-10of10.md` 6. `docs/homepage-copy-review.md` Then inspect the actual code, routes, landing pages, docs pages, developer docs pages, settings/admin surfaces, blog structure (if any), metadata, SEO setup, and current copy before making any claims. ### Mission Rework FleetOS for a **PLG go-to-market motion** so it can hit the ground running before OpenClaw is layered in. This pass is not about backend workflow changes first. This pass is about making FleetOS: * easy to understand * easy to try * easy to trust * easy to discover via search * easy to convert from landing page → demo → signup → docs → API OpenClaw will be integrated later. For now, your job is to make FleetOS’s product story, content surfaces, and growth surfaces launch-ready. *** ### What success looks like FleetOS should feel like a product-led company that knows: * exactly who the first user is * exactly what problem it solves first * exactly what the free product does * exactly why someone should try it now * exactly how docs and SEO support that motion The final result should support this funnel: 1. discover FleetOS via SEO / shared link / referral 2. instantly understand the value prop 3. choose the right path: supplier, fleet, developer, or demo 4. try the product with low friction 5. deepen trust via docs, pricing, examples, and proof 6. convert into usage 7. later expand into integrations and OpenClaw-assisted growth *** ### Non-negotiables * Do not invent fake proof. * Do not overclaim AI capabilities that are not yet real. * Do not leave legacy or confusing messaging in place. * Do not let docs and landing pages drift from actual product capabilities. * Do not make the copy vague, generic, or investor-ish. * Keep the tone operational, direct, believable, and PLG-oriented. * Preserve truthfulness. * Preserve the FleetOS visual identity. *** ## PART 1 — POSITIONING FOR PLG ### 1. Clarify the primary wedge You must identify and sharpen the first best PLG wedge for FleetOS. Likely candidates: * mobile tire / roadside fleet-service suppliers * fleet operators coordinating outside service providers * service shops handling fleet work via WhatsApp/email/manual requests #### Your job Determine the strongest first wedge from the actual product and current repo surfaces. Then make the product story clearly support that wedge. #### Rule FleetOS can speak to broader categories later, but the PLG motion must have a clear first user and first job-to-be-done. *** ### 2. Rewrite core messaging around PLG adoption The product must communicate: * what FleetOS replaces or improves immediately * what users get for free * what they can try right now * what they do not need to change * why there is low switching cost #### Message spine to strengthen * turn WhatsApp/email/web requests into trackable jobs * no new app for customers/partners to install * low-friction browser workflow * audit trail and approvals by default * free core coordination layer * premium upsell later for retail/AI/admin features #### Important The copy must feel like a real operational tool, not a vague SaaS layer. *** ## PART 2 — LANDING PAGE / MARKETING SITE / CONVERSION ### 3. Rework the homepage for PLG conversion Audit the current homepage and tighten it for: * clearer first-time understanding * stronger wedge focus * stronger CTA structure * less repetition * more product-led conversion logic #### Fix * hero headline/subheadline * primary CTA wording * demo CTA wording * supplier vs fleet split * developer path discoverability * proof/credibility sections * pricing framing * FAQ wording * footer/support/discoverability #### Specific conversion goals The homepage should make it obvious how to: * start as supplier * start as fleet * try a demo * read docs * view developer docs *** ### 4. Reduce repetitive messaging Current content likely repeats variants of: * one dashboard * zero chaos * unified inbox * audit trail * WhatsApp/email/web forms #### Fix Condense and sharpen. Every section must have a distinct job: * value prop * proof * who it is for * how it works * why trust it * pricing * FAQ * next step *** ### 5. Add stronger proof mechanics without faking proof If real customer proof does not exist yet, use stronger product proof instead. #### Examples * annotated workflow walkthroughs * before/after process explanation * request → quote → approval → completion example * concrete feature proof in screenshots * sample use cases by vertical #### Rule No fake logos. No fake metrics. No fake testimonials. *** ## PART 3 — BLOG / CONTENT / SEO ENGINE ### 6. Build a real blog/content strategy for PLG growth If the repo lacks a proper blog structure, create the scaffold and IA. #### Deliverables * blog index page structure * blog post template * article metadata structure * category/tag structure * internal linking strategy * CTA blocks inside articles #### Initial blog themes * operational pain content * workflow education * dispatch/service coordination best practices * WhatsApp-to-work-order problem * fleet service supplier operations * approvals / audit trail / compliance * API / integration content * category pages for target verticals *** ### 7. Create a prioritized SEO content map Design the SEO/content plan around intent, not fluff. #### Content buckets 1. Problem-aware searches * managing fleet service requests * WhatsApp job tracking * service dispatch workflow * approval workflow for fleet repairs 2. Solution-aware searches * fleet service coordination software * fleet vendor management workflow * work order approval software 3. Vertical pages * mobile tire operators * roadside assistance providers * towing companies * fleet maintenance shops 4. Developer/integration pages * fleet work order API * webhook-based service updates * WhatsApp-to-work-order API flows #### Output Build a keyword + page map and implement the highest-value pages first. *** ### 8. Fix technical SEO basics across the site Audit and improve: * page titles * meta descriptions * H1/H2 hierarchy * canonical behavior * internal linking * route structure * OG/Twitter metadata * structured data where useful * sitemap/robots if present or needed * image alt text on meaningful product images #### Rule Do not over-optimize keywords unnaturally. Make pages clear, indexable, and useful. *** ### 9. Create high-intent landing pages / use-case pages FleetOS needs pages that convert specific buyers, not just one general homepage. #### Examples to create or improve * FleetOS for Mobile Tire Operators * FleetOS for Roadside Assistance Teams * FleetOS for Fleet Coordinators * FleetOS for Service Shops Handling Fleet Work * FleetOS API / Developer Overview #### Goal Each page should: * match a clear search/user intent * explain the workflow pain and solution * show the right CTA * support PLG signup/demo flow *** ## PART 4 — DOCS / DEVELOPER DOCS / PRODUCT EDUCATION ### 10. Turn docs into PLG activation tools Docs should not only explain the product. They should help activate and convert users. #### Fix * quick-start structure * supplier quick-start * fleet quick-start * developer quick-start * demo orientation * clearer cross-links between docs and product * clearer screenshots/examples * fewer walls of text #### Goal A user who is evaluating FleetOS should leave docs more ready to use it, not just more informed. *** ### 11. Align developer docs with PLG strategy Developer docs should support adoption and expansion. #### Fix * make the API value prop clearer * explain what the API unlocks in plain language * improve self-serve vs managed-service clarity * add integration examples grounded in actual product use * improve internal links from landing → developers → settings/API #### Goal The developer story should support growth, not sit isolated as an afterthought. *** ## PART 5 — PRICING / PACKAGING / UPGRADE LOGIC ### 12. Reframe pricing for PLG The pricing page/section must make the free wedge strong and the premium upsell obvious. #### Make clear * what free includes * why free is enough to start * what premium adds later * who premium is for * what is coming soon vs what is real now #### Rule Do not let pricing feel vague or premature. It should help adoption first, monetization second. *** ### 13. Strengthen upgrade logic inside copy Premium should feel like a natural expansion of usage, not a random paid add-on. #### Examples * free = fleet coordination core * premium = retail separation, AI triage, higher-volume workflows, advanced admin features #### Goal Pricing should fit the PLG adoption narrative. *** ## PART 6 — OPENCLAW PREP WITHOUT FORCING IT NOW ### 14. Prepare messaging and architecture for OpenClaw later You are not integrating OpenClaw now. You are preparing FleetOS so OpenClaw can later amplify the go-to-market motion. #### That means * clean funnel entry points * strong category pages * strong docs * strong developer surfaces * strong demo paths * strong conversion story * strong internal linking #### Rule Do not over-emphasize OpenClaw before it is actually exposed. FleetOS must stand on its own. *** ## PART 7 — THINGS TO CLEAN OUT ### 15. Remove confusing or off-strategy messaging Audit for and clean out: * legacy phrasing that does not fit FleetOS * muddled category language * overly broad claims * vague “platform” copy * any leftover confusing references that do not support PLG onboarding * any awkward/dated/SEO-thin content If there are legacy adjacent narratives or confusing messaging remnants, normalize them to the FleetOS wedge instead of inventing new categories. *** ## PART 8 — FINAL DELIVERABLES ### 16. What you must actually produce Deliver concrete, repo-level outputs such as: * tightened homepage copy and structure * improved nav/CTA/discovery * improved pricing section/page * improved docs and developer docs structure * blog scaffold if missing * initial SEO/content map * metadata improvements * use-case/vertical landing pages if needed * internal linking improvements * any needed reusable content components Do not only write strategy notes. Ship actual changes in the repo. *** ## REQUIRED OUTPUT STYLE * Be concrete. * Show exact files changed. * Keep a running checklist. * Make incremental commits. * Explain messaging decisions clearly. * Call out what is real now vs later. * Keep the PLG motion front and center. *** ## FIRST RESPONSE FORMAT Your first response must contain exactly these sections: 1. `Current PLG gaps` 2. `Messaging problems` 3. `SEO/docs/blog gaps` 4. `Best PLG wedge` 5. `Execution plan` 6. `First files I will change` Then start work. *** ## DEFINITION OF DONE You are done only when FleetOS feels ready for a PLG launch across: * homepage * conversion paths * pricing * docs * developer docs * blog/content structure * SEO basics * use-case messaging * product truthfulness The standard is: clear, believable, searchable, trial-friendly, and ready to compound once OpenClaw is added later. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://t420.gitbook.io/t420/claude-plg-gtm-kickoff.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.