> 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/miami-go-to-market-plan.md). # FleetOS Miami Go-To-Market Plan ## Objective Launch FleetOS in Miami, Florida with a focused wedge, simple operating model, and clear evals. This plan aligns three repos into one system: * **FleetOS** = product and activation surface * **OpenClaw (Blade)** = growth operator / research / outreach / content agent * **Mission Control** = human sales and activation cockpit The goal is not a sprawling multi-agent empire. The goal is a tight loop with **3 great agents/roles**: 1. **Architect** — strategy, interfaces, priorities, weekly decisions 2. **Builder** — ships product, content, automation, and experiments 3. **Reviewer/Refiner** — evaluates output, identifies drift, tightens the system *** ## Core Thesis FleetOS wins in Miami if it becomes the fastest way for fleet-service suppliers and fleet coordinators to turn messy inbound service requests into trackable work orders without forcing anyone to install a new app. The wedge is not "all fleet software." The wedge is: **external service coordination for fleet work that currently leaks through WhatsApp, calls, email, and spreadsheets.** Miami is the right wedge city because it has: * dense commercial fleets * mobile service categories * real roadside/field-service need * a practical dispatch culture * enough fleet density to get repeated category learning from a small number of wins *** ## The Wedge ### First ideal supplier user Start with: * mobile tire operators * roadside assistance providers * towing / emergency recovery operators * service shops already handling fleet work ### First ideal fleet user Start with: * fleet coordinators / fleet managers handling external service vendors * businesses with recurring service needs and multiple vehicles * operators who currently coordinate via WhatsApp/email/calls ### Why this wedge is strong Because FleetOS does not need to beat all of fleet management software to win. It needs to beat: * WhatsApp chaos * inbox chaos * lack of approvals * missing audit trail * messy cross-company coordination *** ## Product Positioning ### Say this clearly FleetOS is the operating layer for external fleet service coordination. It: * turns WhatsApp, email, and web requests into trackable work orders * keeps fleet and supplier aligned on quote, approval, schedule, vehicle readiness, and completion * preserves audit trail by default * works in the browser with no extra app for customers or partners ### Avoid these traps Do **not** position FleetOS as: * generic fleet software * a marketplace first * just a chat wrapper * a giant AI platform * a broad maintenance suite before the wedge is proven *** ## The 3-Repo System ## 1. FleetOS — Product Repo ### Job FleetOS must become the 10/10 product surface. ### Responsibilities * supplier dashboard * fleet dashboard * add-job and response workflow * settings/admin/API surfaces * docs and developer docs * pricing and homepage * activation UX ### Success metrics * first value in under 5 minutes * clear demo paths * clear supplier/fleet signup path * low-friction job creation * high trust in statuses and audit trail * clear developer surface for integrations later *** ## 2. OpenClaw / Blade — Growth Operator Repo ### Current issue OpenClaw is still pointed at the old T420 capital raise mission fileciteturn118file0 That is the wrong mission now. ### New job Repurpose Blade into a **FleetOS growth operator** for Miami. ### Blade should do * local supplier prospect research * local fleet target research * outreach prep and personalization drafts * vertical page/content support * objection harvesting and refinement * meeting prep briefs * follow-up sequencing drafts * competitive monitoring * daily market intelligence briefs ### Blade should not do yet * pretend to be fully autonomous sales * blast broad spam campaigns * replace founder/product feedback loops * run 100 agents ### Blade role in the loop Blade prepares, enriches, drafts, scores, and recommends. Human + Mission Control decide and act. *** ## 3. Mission Control — Sales/Activation Cockpit ### Current role Mission Control already positions itself as the internal sales ops tool for the FleetOS B2B Miami launch and targets 20 activated freemium users by April 30 fileciteturn119file0 ### Keep / strengthen that role Mission Control becomes the **human control plane** for: * pipeline management * meeting prep * objection tracking * activation tracking * retention tracking * daily command queue ### Mission Control is not * the product * the public website * the customer dashboard It is the internal operator cockpit. *** ## Operating Model ## Architect This is the weekly decision layer. ### Responsibilities * choose wedge priority * set goals * define experiment sequence * decide what to ship next * decide where Blade focuses * review metrics every week ### Cadence * weekly strategy review * daily 15-minute review of command queue and GTM signals *** ## Builder This is the shipping layer. ### Responsibilities * product polish * landing page improvements * docs and content shipping * API and integration surfaces * onboarding and activation improvements * Blade skill updates * Mission Control schema/UI improvements *** ## Review/Refine This is the quality and eval layer. ### Responsibilities * review outbound quality * review product friction * review messaging accuracy * review activation drop-off * review objection patterns * review whether experiments are actually working *** ## Miami Launch Strategy ## Phase 1 — Tight wedge and local proof (Weeks 1-2) ### Goal Get the product and message tight enough that a Miami operator can instantly understand it. ### Product tasks * finish auth/login/signup clarity * polish mobile readability and dashboard usability * tighten homepage and docs for PLG * make supplier/fleet demo paths obvious * make pricing, docs, and developer path consistent ### GTM tasks * define top 3 Miami verticals: 1. mobile tire 2. roadside/towing 3. service shops handling fleet work * build a 100-account target list in Miami across suppliers and fleets * build vertical-specific landing copy and objection list * build local proof narratives (no fake customer proof) ### Blade tasks * research 100 Miami supplier/fleet targets * enrich with category, fleet relevance, phone, email, website, region, likely workflow pain * draft first-wave outreach sequences * draft Miami vertical pages and FAQ suggestions * create daily intel brief ### Mission Control tasks * pipeline for the 100 accounts * command queue for daily actions * objection capture per meeting/reply * activation tracking per onboarded account ### Eval * 100 qualified Miami targets loaded * 3 vertical pages or category-specific sections live * homepage speaks clearly to Miami wedge * auth and demo path clean enough to use in real calls *** ## Phase 2 — Founder-led sales + PLG activation (Weeks 3-6) ### Goal Close first active Miami users and learn fast. ### Motion Use a hybrid model: * outbound to targeted suppliers/fleets * short founder demos * low-friction self-serve signup * fast activation inside product ### Offer Lead with: * free coordination core * no app install for customers/partners * browser-based workflow * clear audit trail * quote/approval/schedule visibility ### Tactics * 15-minute demos max * onboarding in real time * use their live examples where possible * set up first job/request during or right after meeting * capture exact objection/reason for no ### Blade tasks * prep meeting briefs * generate custom follow-up messages * summarize objections and patterns * propose next-best-targets based on what is converting ### Mission Control tasks * pipeline stage discipline * prebrief/debrief every meeting * activation milestone tracking * flag stalled accounts ### Eval * 20 meetings booked * 8 onboarded accounts * 5 activated accounts * activation = created/processed at least one real request/job * document top 10 objections and top 10 conversion triggers *** ## Phase 3 — Tighten retention loop (Weeks 6-10) ### Goal Turn first accounts into retained users and sharpen the wedge. ### Product tasks * remove repeated friction points from first users * improve the exact workflows used most in Miami verticals * improve docs and help around those workflows * tighten lifecycle nudges and activation prompts ### GTM tasks * stop broad selling * double down on categories with fastest activation and retention * build category-specific case-study style pages from real usage (only if real) ### Blade tasks * mine usage patterns for positioning ideas * generate retention-risk signals from notes and pipeline events * summarize category-specific pain and best messaging ### Eval * 10 activated accounts * 5 retained after 7+ days * one category clearly outperforming the others * at least 3 customer-proof assets from real usage (quotes, process examples, or case snapshots) *** ## Phase 4 — Build repeatable Miami machine (Weeks 10-16) ### Goal Turn what works into a repeatable local motion. ### What becomes systematized * target account criteria * outreach message library * vertical pages * demo script * onboarding script * objection handling * activation checklist * retention check-in cadence ### Mission Control should show * conversion by stage * activation by vertical * retention by vertical * objection frequency * time-to-first-value ### Blade should support * account scoring * personalization * local content suggestions * competitive tracking * daily action prioritization ### Eval * repeatable channel-to-activation flow * 15+ activated Miami accounts * 8+ retained accounts * clear CAC proxy from time spent per activation * clear top-performing wedge segment *** ## Tactics by Channel ## 1. Founder-led targeted outbound Best early channel. ### Why The product is still being shaped and the wedge needs live feedback. ### Method * short targeted list * local relevance * practical pain language * fast demo and onboarding ### Sample angle "You already handle requests on WhatsApp and calls. FleetOS turns them into trackable work orders with quote approvals, schedule visibility, and audit trail — without making your customers install anything." *** ## 2. Demo-led PLG ### Why The product is understandable when seen, not just described. ### Method * strong supplier demo * strong fleet demo * clear CTA paths * clean auth funnel * docs that reinforce activation ### Eval * demo → signup conversion * signup → first job conversion *** ## 3. Local content + SEO ### Why Build compounding inbound while outbound is running. ### Topics * WhatsApp dispatch chaos * fleet approval workflow * mobile tire workflow * towing/roadside coordination * trackable work orders for external vendors * no-app browser workflow ### Eval * page creation velocity * clicks to demo/signup/docs * qualitative usefulness in sales calls *** ## 4. Partnerships later, not first Do not start with channel partnerships. Earn the wedge first. *** ## What must change in each repo ## FleetOS repo ### Must change * homepage sharpened for Miami wedge * auth funnel fixed * supplier/fleet demos obvious * docs and pricing support PLG * mobile polish finished * category pages / SEO pages added * developer docs truthful and useful ## OpenClaw repo ### Must change * replace T420 fundraising mission with FleetOS Miami growth operator mission * replace old skills with FleetOS-relevant skills * define safe/human-in-loop guardrails for local GTM * produce daily intelligence and outreach support instead of autonomous spam ### Likely new skills * miami-supplier-scout * miami-fleet-scout * fleetos-outreach-drafter * fleetos-meeting-brief * fleetos-objection-synthesizer * fleetos-content-assistant * fleetos-daily-brief ## Mission Control repo ### Must change * align fields and stages to real Miami motion * activation metrics emphasized more strongly * objection library connected tightly to real calls * command queue becomes daily operating system for founder + Blade *** ## Clear Evals ## Weekly evals * meetings booked * demos completed * accounts onboarded * accounts activated * accounts retained * top objections * top conversion triggers * time-to-first-value ## Product evals * can a supplier understand the value in <60 seconds? * can a fleet manager understand the value in <60 seconds? * can a new user sign up without confusion? * can a user create/handle first job quickly? * are mobile flows trustworthy and readable? ## Blade evals * quality of target lists * quality of personalization drafts * usefulness of daily brief * usefulness of objection synthesis * reduction in founder prep time ## Mission Control evals * pipeline discipline * meeting prep quality * activation tracking quality * objection capture completeness * decision usefulness of dashboard/queue *** ## Final recommendation Yes — your instinct is right. Do **not** build 100 agents. Build 3 excellent roles: * Architect * Builder * Review/Refine And make the repos converge like this: * FleetOS = product users touch * Blade/OpenClaw = growth/research/copilot layer * Mission Control = internal command center That is a system that can actually win. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://t420.gitbook.io/t420/miami-go-to-market-plan.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.