# NVG8 | Full Site Content > Operator-led practice. Twenty years in go-to-market across technology and hardware, delivered as fractional CRO/COO and alliances leadership, plus the AI systems that run the GTM motion. Built on your stack. Owned by your team. --- ## Home · We run your go-to-market. Then we build the systems that keep it running. Most AI for GTM is built by people who never carried the number. Ours comes out of the seat. We run sales, partnerships, and RevOps alongside your team as fractional operators, find the work that eats the week, and turn it into systems your team owns after we step back. 1. **Operate.** Fractional CRO, COO, or Chief Partner Officer embedded on your team for the quarter that matters. We run the motion alongside you. Not a strategy deck handed over the wall. The actual work. 2. **Build.** Running it shows us where the week goes. We turn the repeatable work into systems: rep briefings, partner updates, pipeline rollups, QBR prep. Built on your stack. 3. **Hand off.** Your team owns what we built, documented and versioned. We step back. The motion keeps running. Teams that already know what they want automated can start with the build. **Stack experience:** Salesforce · Slack · LinkedIn · Google Cloud · AWS · Microsoft · Anthropic · OpenAI · Gemini --- ## What we build · Five teams, one operating system Modern GTM runs on five functions: Sales, Marketing, Customer Success, RevOps, and Partnerships. We build AI workflows inside each one, drawn from the experience of having run them. The workflows compose across the org, so a partner-sourced deal flows through sales, gets briefed for the rep, triggers a CS renewal check, and shows up in the board report without anyone retyping anything. The [Build](https://nvg8.ai/build) page lists every workflow below, grouped by team. --- ### 01 · Sales **Move deals faster with less manual work.** Reps spend half their week on work the system should do: building lists, writing recaps, hunting for context. Sales workflows take that work off the rep and give the time back to selling. - **Opportunity scoring & enrichment** *(Pipeline & CRM)*: Sweeps your accounts and pipeline for buying signals, enriches contacts and domains, and delivers a ranked, ready-to-action list before reps log in. - **Pre-meeting briefings** *(Meeting Intelligence)*: A prep workflow reads prior email and notes with the account, then drops a brief in the rep's inbox covering past conversations, open issues, and agreed outcomes. Five minutes of prep instead of thirty. - **Meeting capture to action items** *(Meeting Intelligence)*: Records system audio, transcribes locally, and extracts decisions, commitments, and next steps so nothing gets lost between calls or in the gap before a CRM update. - **Discovery → qualification brief** *(Knowledge & Copilots)*: Turns a discovery call into a structured qualification sheet in a consistent template (fit, current stack, decision process, next step), so handoffs from SDR to AE stop losing context. --- ### 02 · Marketing **Build demand with engines, not campaigns.** Modern demand creation runs on signal and content, both of which are now solvable with narrow workflows. Marketing teams stop firefighting the calendar and start compounding a research-and-publish loop. - **LinkedIn research & posting workflows** *(Outbound & Content)*: Find the right people based on your ICP, draft in your brand voice, schedule the cadence, and sync activity back to your CRM and spreadsheets. - **Iterative content generation** *(Outbound & Content)*: A multi-model writing system that iterates drafts against quality and topical signals before publishing, replacing one-shot prompts with a measurable production loop. - **Market & competitive intelligence** *(Outbound & Content)*: Scrapes vendor changelogs, event sponsor lists, and category news into structured feeds so PMM and demand gen get a daily read on the field without manual monitoring. - **Content-grade retrieval pipelines** *(Knowledge & Copilots)*: Turn your blog, docs, customer stories, and analyst notes into a vector store your writers and tools can query and cite from with confidence. --- ### 03 · Customer Success **Renew, expand, and report without retyping.** CS teams own the most context-rich relationships in the company, and spend the most time retyping that context. Account-aware workflows convert it into the briefings, recaps, and reviews you'd otherwise build by hand. - **QBR & renewal prep briefings** *(Meeting Intelligence)*: Before every renewal call and QBR, a workflow pulls the account's email history, past meeting notes, agreed KPIs, and open issues into a one-pager so the CSM walks in current. - **Recurring executive updates** *(Meeting Intelligence)*: Synthesizes a window of email, calendar, and system activity into a brand-voice update sent to the exec sponsor on a cadence you set. Not a chore the CSM has to remember. - **Quarterly & annual account reviews** *(Meeting Intelligence)*: Compiles months of account activity into slide-ready bullets with quarterly or thematic structure, so leadership reviews are written by the system, not the team. - **Semantic search across account history** *(Knowledge & Copilots)*: Years of email and notes indexed and queryable by meaning, filterable by account, so the third CSM on the account inherits the first CSM's context. --- ### 04 · RevOps **Clean systems. Clean data. Internal copilots.** The work nobody sees that everybody depends on. RevOps workflows handle the hygiene tax, keep records correct, and put internal knowledge in the channel the team already lives in. - **Spreadsheet ↔ CRM sync** *(Pipeline & CRM)*: Bidirectional sync between sheets and your CRM so non-technical teams manage records in a sheet while changes round-trip in real time. Rate-limited and audit-logged. - **Record deduplication workflow** *(Pipeline & CRM)*: Resolves duplicate accounts, contacts, or vendors using URL matching plus semantic similarity on descriptions, so every team works from one clean entity. - **Stakeholder attachment automation** *(Pipeline & CRM)*: Keeps the correct internal team and external contacts attached to every active record, so reviews, handoffs, and renewals never run on stale rosters. - **Slack assistants for internal knowledge** *(Knowledge & Copilots)*: Production-grade Slack copilots on a tuned retrieval stack so support, enablement, and operations questions get answered in the channel they're asked. --- ### 05 · Partnerships **Co-sell, co-market, and report on partner motion as a system.** Partnerships generate the largest deals and the least clean data. Solutions make the ecosystem motion legible: who you know, what partners are doing, and how every relationship is performing. - **Warm-path co-sell mapping** *(Outbound & Content)*: Cross-references your team's combined network against a partner's target account list to surface warm intros and turn cold co-sell into a connection-led plan. - **Partner ecosystem intelligence** *(Outbound & Content)*: Scrapes marketplace listings, partner directories, and vendor changelogs into structured intelligence on who's moving in your category and where the white space is. - **Recurring partner updates** *(Meeting Intelligence)*: Synthesizes the week's joint pipeline, meetings, and deal momentum into a brand-voice update for your partner contact. Automated recaps that keep the relationship warm. - **Annual partner reviews & board summaries** *(Meeting Intelligence)*: Compiles a fiscal year of joint activity into slide-ready bullets with quarterly or thematic structure. Board-ready partnership summaries written by the system. --- ## How we work · Operator-led. Engineered to ship. Designed to be owned. - **Built on your stack.** Salesforce, Slack, Google Cloud, AWS, Microsoft, the inbox you already use. Workflows fit your data and your team's ergonomics, not the other way around. - **Owned by your team.** Code, prompts, and data stay yours. We deliver versioned systems with documentation and a retirement plan, not opaque black boxes. - **Practical, not theatrical.** We ship narrow workflows that earn back hours every week before we widen scope. Pilot in weeks, measurable lift before quarter-end. --- ## Build · one call, one workflow, then the build Engagements start with a call, not a package. There are no tiers, cohorts, seats, or fixed-price programs. ### 1. A call about the work Thirty minutes on what the team does by hand today and where it hurts. No deck. If NVG8 is not the right fit for the problem, that gets said on the call. ### 2. One workflow, scoped Together we pick the narrowest workflow that earns back real hours, and write down what it does, what data it touches, and what it costs to build. The client owns that specification whether or not NVG8 builds it. ### 3. Build, then widen The first workflow ships in weeks, not quarters, and has to earn its keep before scope widens. Code, prompts, and data stay with the client throughout. ### Where builds come from Most of what NVG8 builds starts as work it ran by hand while operating a client's go-to-market. Some teams arrive already knowing what they want automated. Sometimes the first build is measurement: a scorecard or a pipeline analysis from the raw data, because you cannot automate what you cannot see. ### Who it is for CROs, COOs, VPs, and the operators who report to them, at companies where the go-to-market motion is real and manual work has become the bottleneck. Best fit is a specific problem rather than a mandate to "do something with AI." NVG8 is small on purpose and takes on a handful of engagements at a time; the person on the first call is the person who does the work. URL: https://nvg8.ai/build Contact: info@nvg8.ai --- ## Field notes · Case studies and notes from inside the work --- ### Most partner plans stop at the partners you can see from inside Salesforce URL: https://nvg8.ai/field-notes/partner-map A note. Ask an ISV for its partner plan and you hear two things: get the AEs to bring us in, and recruit the SIs. Both matter. Neither earns more when your customer stays. Most partner maps stop at the Salesforce field and the SIs, because those are the partners you can see from inside the CRM. SIs get paid per project, and the field sells Salesforce first. The ones paying you, such as the platforms your product connects to, the add-ons you sell in, and the resellers your customers buy through, often show up only in finance actuals. They are also the partners who send the second deal, and the tenth, because they get paid when your customer does. The five kinds NVG8 maps: - **Connected platforms**: the systems your product connects to, which your customer already pays for. They earn every time a shared customer uses both products, so they have a reason to keep referring. - **Add-ons**: products your customers need that you do not build. You sell them into your base, and they pay a share for as long as the customer stays. - **Routes to buy**: resellers, public sector contract holders, and marketplaces past the AppExchange. Some customers can only buy through one of these. - **SIs**: they bring you into the projects that need you, and most bring one deal and move on. Enablement has to reach the SI on the deal, when the deal needs it. - **Salesforce field**: AEs and SEs. Still worth working every week, but a plan that depends on them depends on someone else's quota. The finding: start the map from who earns when your customer stays, then work back to the field and the SIs. The data for the first group usually sits in finance, not in the CRM. Published October 2026. --- ### 60 of 65 SIs brought us one deal. The long tail is the partner program. URL: https://nvg8.ai/field-notes/partner-long-tail A note, not a case study. We pulled three years of partner data (2023 to 2025) for a Salesforce ISV whose partner program we run as its fractional lead. Sixty five implementation partners showed up on deals, and sixty of them showed up exactly once. The busiest appeared on three. Of the seventy one deals with an SI on them, sixty came from an SI we only saw once. Referrals told the same story. Ninety two partners sent at least one referral, and sixty nine sent exactly one. Only fourteen referred in more than one year. Referrers dropped from forty four in 2023 to thirty four in 2024 and thirty in 2025, and thirty two of the 2023 referrers never sent another. Why SIs bring one deal: they get paid per project. When a customer project needs your product, they bring you in; when the project ends, they move on. Their incentive is the project, not your product. They still matter on the deal. In 2023, deals with a partner on them won 80% of the time against 61% without. By 2025 that gap had narrowed to 37% against 32%, but it was still there. Most programs are built for the five who come back: tiers, certification paths, a portal, quarterly enablement sessions, co-marketing funds for partners who hit a threshold. Every one of those assumes the partner returns and asks new ones to invest up front. One SI got a 29-slide enablement deck, another got 46. The parts an SI needs on a live deal would fit on one page. Just-in-time enablement comes down to three things. Questions to listen for: what the customer says when they need you is worth more to an SI than a feature tour, because it tells them when to call. A customer like theirs: the first question an SI asks is whether you have done this before, in this industry; for this company that answer used to take about twenty hours of digging, and turning years of sales notes into something searchable brought it down to five minutes (see the partner-ops-data writeup). Help on the deal itself: a custom demo for this customer, answers for the RFP, an architecture review before the SOW is signed, an executive on the call when the deal needs one. None of it asks the SI to invest anything before there is a deal. Find the few from the data, not the tier. Fourteen partners referred in more than one year; one SI sent four deals over two years and won all four. One repeat partner got a joint session at its Dreamforce lounge with a tracking link so we can see what it produces. That kind of investment makes sense for a repeat partner and makes no sense for the other sixty. The partners most likely to repeat are often not SIs at all: the platforms your product connects to, the add-ons you sell into your base, and the resellers your customers buy through. They earn for as long as your customer stays, so they have a reason to send the next deal (mapped in the field note on partner maps). The finding: the long tail is not a recruiting failure; it is the shape of the SI channel. Most SIs will bring you one deal, so make that first deal easy: what to listen for, a customer like theirs, and help on the deal when they ask. Then let the data tell you who comes back, and spend the program's money there. For this company, those partners brought sixty of the seventy one SI deals. Published October 2026. --- ### We gave an agent access to our inbox. It archived 78 emails instead of 12. URL: https://nvg8.ai/field-notes/agent-inbox-guardrails A note, not a case study. We gave a local agent write access to a working Gmail mailbox, with the job of clearing automated clutter. The correct target was twelve alert emails from one sender. The agent archived seventy eight in a single command, then two more that were halves of a live project thread. Nothing was destroyed, because archived mail stays in Gmail and stays searchable, and restoring it took one command. The system has three separable layers, and the distinction is the point of the piece. The harness is Pi, which runs the loop: plan, call a tool, observe, decide what next. It holds the model and the conversation and nothing else, and is swappable. The instructions are markdown files, a playbook explaining when and why a job is done and a runbook holding the exact commands. The actions are small command line programs: list the inbox, show a message, draft a reply, suggest archive candidates, archive. The actions are the only things in the system that touch anything real. The first two layers are advice. Only the third can refuse. The model was Qwen 3.6-35b-a3b, open weight, mixture of experts with roughly 3B active parameters, served over the LAN through LM Studio. Nothing left the network. The incident: the archive command takes a search query and does nothing without a confirmation flag, and the runbook says in bold to run it without the flag first and show the list. The agent added the flag on the first attempt and every attempt after, four in a row. The first two queries carried a typo in the sender domain, .co rather than .com, and matched nothing. A person who expected twelve results and got zero would check the query. The agent did the opposite: it dropped the subject filter, then corrected the domain, each step widening the query, until it matched every message that sender had ever put in the inbox. The fourth command was an attempted recovery whose query meant "everything from this sender that is not an alert", which is precisely the mail worth keeping, and it archived two live project threads. The agent's own reasoning noticed the problem one step after acting. Why the written rules did nothing: two rules covered this case, one in the runbook requiring a preview and one global rule stating that anything touching more than about fifty messages is wrong. Both sat in the instruction layer. The model was not being defiant; it had a goal, a query returning nothing, and a reasonable next move, and instructions are context while the goal is the task. Instructions shape behaviour most of the time, and most of the time is not a boundary. The same category error appeared in the permission model. Gmail write access is granted per OAuth scope, and the narrow gmail.compose scope was chosen on the belief that it made sending impossible. It does not. Google documents gmail.compose as "Manage drafts and send emails" and gmail.modify as "Read, compose, and send emails", and no Gmail scope permits drafting while withholding send. Nothing sent, because the tool contains no send call, but the protection was the code rather than the platform, which is a materially weaker guarantee than the one originally claimed. The fix was sixteen lines in the action layer. The archive command counts what a query matches before acting and refuses above a threshold, defaulting to twenty five, with the message "REFUSED: 78 messages exceeds --max-messages (25). A query this broad is usually a mistake." The threshold is arguable; the property is not. A model cannot argue past it, forget it under task pressure, or fail to retrieve it. Three smaller changes followed: every destructive command prints the command that undoes it, granting a permission became its own command rather than a side effect of exercising it, and the clustering that decides what counts as clutter now refuses to group a person's mail by sender alone after an early version flagged a colleague's ordinary threads as noise. Why plain command line tools instead of an MCP server. Three reasons, all borne out in practice. First, things pipe: drafting a reply is three tools in one line, show the message, generate a reply, create the draft, and the message travels tool to tool. The message the agent drafted against was 16KB and the largest in that inbox is 180KB of newsletter HTML, and neither size matters because none of it is ever in the context, where MCP tools return every result to the model and take every argument from it. That is the difference between the model orchestrating data and orchestrating work. Second, you can run them yourself: every command in the runbook was typed into a terminal and its output read before being written down, a cheap habit with a CLI and an awkward one with an MCP server that needs a client to exercise a tool, and it caught a default provider pointing at uninstalled software, a timeout set below the model's actual runtime, and a model name too large to load. Third, they outlive the harness: the same file was driven by Pi and, during development, by a different coding agent entirely, and works anywhere there is a shell, whereas tying actions to a protocol ties them to clients that speak it. The honest cost is that the model builds the command as a string, so quoting and typos are its problem, which is exactly how the .co typo reached the API. The takeaway: the model was not the weak point. It read a real inbox, sorted twenty messages into needs-a-reply and noise, found the one genuinely ambiguous thread, and asked a sensible question about it, all on the first attempt. What failed was writing a rule down and believing that made it a rule. Separate the harness from the instructions from the actions, and be honest about which layer each safety claim actually lives in. The instruction layer persuades; only the action layer refuses. Published September 2026. --- ### Muse Glimmer vs Qwen 3.8-27b on an Intel Arc Pro B70 URL: https://nvg8.ai/field-notes/muse-vs-qwen-arc-b70 A note, not a case study. One of our pipelines turns a sales qualification sheet into an internal win story. The sheet carries the customer's name, named contacts and their email addresses, a revenue band, transaction volumes, and a frank account of what is broken inside their finance operation, and the output is internal-use only. That is not a document to paste into somebody else's API, so the question was whether a model we run entirely on our own hardware is good enough for the job. Hardware: one Intel Arc Pro B70: 32GB GDDR6, 608 GB/s, 256 XMX engines, $949 at launch in Q1 2026, in a Windows box on the LAN, serving models through LM Studio's OpenAI-compatible API. Models: Muse Glimmer and Qwen 3.8-27b, both open-weight, both local. Nothing left the network. The test was built to be machine-gradeable rather than a taste test. It reads a real ~2,700-token qualification sheet and return a fourteen-field JSON record, scored on nine mechanical checks, valid JSON, all fields present, exact counts where the schema demands them, a hard 560-character budget the slide renderer enforces, no stated value contradicting the sheet, no value invented where the sheet is silent, and no field declined where the sheet does support an answer. Three traps already present in the document: a transaction figure that appears two ways (40-50 consolidated, 200-300 broken out, where reporting only the smaller understates real volume roughly fivefold); vendor product-catalogue lines that name Salesforce products but say nothing about what the customer runs; and a Salesforce AE field the sheet never answers, where an explicit null is the only correct output. Results, all at temperature zero. Muse Glimmer: 9/9, 107 seconds, 21.1 tok/s, 2,253 generated tokens, three byte-identical runs. Qwen 3.8-27b: 7/9, 895 seconds, 6.1 tok/s, 5,471 generated tokens, two identical runs. The larger model was 8.4x slower on wall clock, generated 2.4x more tokens, and produced a worse answer. The central finding is about calibration rather than caution. Both models faced one safe inference (the sheet gives a city and state but never a country) and one unsafe one (the vendor catalogue is not the customer's stack). Muse Glimmer made the safe inference and declined the unsafe one. Qwen 3.8-27b did the opposite on both: it refused to name the country, then confidently reported two Salesforce products the customer was never said to use, and lifted a lifecycle stage from a word the sheet used to describe something else. Miscalibrated in both directions inside a single answer. Reading Qwen 3.8-27b's captured reasoning showed the invention was not an accidental conflation of two nearby passages. The model explicitly noticed the problem, that one of the two strings was a product rather than a cloud, and that both came from lines describing what the vendor sells, hesitated, then filled the field anyway and marked the job done because the schema required one to two entries and it now had one to two entries. It was checking whether the field was full, not whether the claim was true. Muse Glimmer's captured reasoning shows it reaching the identical fork on the identical field and resolving it the other way: it notes that returning null creates a type mismatch against the schema, works out that the no-invention rule outranks the shape rule, and accepts the mismatch rather than fabricate. It rejected the same lifecycle value Qwen published, on the grounds that the sheet never stated it. Both models saw the conflict; only one deferred to the schema. The implication is a prompt fix rather than a model swap: a required field with a required count, pointed at a document that supports neither, is effectively an instruction to invent something, so fields that can legitimately be empty must be described as loudly empty-able as they are required. Two secondary findings. First, 88 percent of everything Muse Glimmer generated was reasoning scratchpad the pipeline discards (93 percent for Qwen), running locally makes that cost visible in seconds rather than hiding it in an invoice. Second, time to first token fell from 19.5 seconds on the first request after a model loads to roughly a quarter second on every request after, about seventy times faster once the prompt cache is warm; "local models are slow" is largely a statement about cold starts. Outcome: Muse Glimmer stays in the pipeline; Qwen 3.8-27b comes out of the rotation for this task. Published August 2026. --- ### Eleven partners, 815 opportunities, and a scorecard the board could read URL: https://nvg8.ai/field-notes/partner-scorecard An enterprise sales performance management software company had a real partner program, more than ten active System Integrators and hundreds of millions of dollars in partner-influenced pipeline, but no structured way to measure it, track certifications, or report partner contribution to the board. The problem: partner performance lived in stories and scattered spreadsheets. Partner-sourced and partner-influenced pipeline were never separated, certifications lived in a learning system nobody reported from, and the quarterly board deck took days to assemble and still felt anecdotal. The root cause was that the program had never been instrumented. Engagement: two phases, a 2022 Salesforce partnership assessment, then a May 2025 Partner Operations Accelerator. **The build:** 1. Defined the partner taxonomy, separating partner-sourced (partner brought the deal) from partner-influenced (partner shaped a deal that arrived another way) and standardizing partner type so global and regional SIs were never summed together 2. Built a scorecard across 11 named partners: sourced and influenced pipeline (created and won), technical experience ratings, implementation counts, certification levels, cost structure 3. Ran the pipeline analysis from the raw Salesforce export, 815 opportunities segmented by partner, geography, industry, and year (global vs. regional SI performance, ACV by partner, YTD trend) 4. Stood up the enablement layer: partner learning path, certification tracking from the learning system badge export, implementation tracker, external Partner Welcome Guide **Numbers at delivery:** Partner-influenced active pipeline 108 opportunities / $47.5M ARR. Partner-influenced closed won since FY23 94 opportunities / $28M ARR. Partner-sourced pipeline FY25 16 opportunities / $5.2M ARR. Partner-sourced closed won since FY23 16 opportunities / $5.1M ARR. **Key lessons:** Separate sourced from influenced in every view, or the numbers are not trusted. Work from the raw export so every figure traces to specific opportunities. A scorecard is a living system refreshed each quarter, not a one-time deck. Instrument partner attribution at deal creation rather than reconstructing it later. --- ### Answers in Slack, grounded in your own docs URL: https://nvg8.ai/field-notes/slack-knowledge-bot A B2B SaaS company needed its team to get accurate, source-grounded answers inside Slack, from the company's own documentation rather than memory. The knowledge existed across internal docs, PDFs, Markdown files, and Salesforce Knowledge Articles. The problem was retrieval, not content: the right passage existed but nothing put it in front of the person asking, in the tool they already had open, so people guessed, waited, or interrupted a subject-matter expert. The hard requirement was trust: the assistant had to cite its sources and stay grounded in them. **The build:** 1. Ingested mixed-format documents (txt, PDF, Markdown, DOCX) via LlamaIndex into a Qdrant vector database; chunking strategy mattered more than later tuning 2. Answered questions in Slack by retrieving the most relevant passages and composing a cited answer grounded in them, delivered in the channel the question was asked in 3. Built multi-tenant from the first line: each client isolated behind an ORG_PREFIX scoping secrets, vector collections, and configuration, so a new client is a config change not a fork 4. Synced Salesforce Knowledge Articles: OAuth 2.0, Bulk API for initial load, incremental SOQL change detection, rate limiting, automatic re-indexing 5. Shipped to production: containerized FastAPI on Google Cloud Run with CI/CD from cloudbuild.yaml **Stack:** FastAPI, Google Cloud Run, LlamaIndex, Qdrant, Slack API, Salesforce Knowledge (OAuth 2.0, Bulk API, SOQL). Delivered February 2025. **Key lessons:** Grounded and cited or it does not ship, because trust is the whole point. Multi-tenant is a day-one decision, not a later refactor. Chunking beats model choice for answer quality. Build the evaluation set first so retrieval changes can be measured. The Salesforce Knowledge sync is the differentiator for ISV and SI companies and should be scoped up front. --- ### Two data sources, one clean dataset, and the end of twenty-hour SI prep calls URL: https://nvg8.ai/field-notes/partner-ops-data A Salesforce-native ISV had years of sales qualification notes (AE observations, SE technical detail, multi-call discovery summaries) sitting in Google Docs attached to opportunities, unused. They also had a Salesforce instance with clean structured deal data. Neither was useful on its own. The problem: preparing for a single SI meeting in the healthcare vertical took three days of manual data compilation. The root cause: unstructured notes that had never been cleaned, joined with structured Salesforce data, or made queryable. **The six-step workflow built:** 1. AI standardized unstructured notes into a structured CSV (industry, customer pain, solution fit, payment gateway, win rationale) 2. Normalized industry labels to a standard taxonomy 3. Cross-referenced with Salesforce opportunity data (won/lost, deal value, close date) via opportunity ID join 4. Combined structured + unstructured into a master dataset 5. Built a custom GPT query layer over the dataset: "I'm meeting with a healthcare nonprofit, what should I lead with?" 6. Added adversarial review: a judge model checks all outward-facing content against source material for hallucinations **Outputs:** Salesforce win stories in the partner marketing format, industry-specific PowerPoint decks for SI meetings, a queryable sales intelligence tool for AE prep. **Result:** SI pitch prep time went from ~20 hours to ~5 minutes. **Key lesson:** Salesforce records tell you what happened. Qualification notes tell you why. AI is the bridge between them. The value is in the join. --- ### What it actually takes to launch a net-new ISV on the Salesforce AppExchange URL: https://nvg8.ai/field-notes/zinkt-salesforce-launch A revenue operations software company had a working product, a small team in Toronto, and no presence in the Salesforce ecosystem. No AppExchange listing. No AE relationships. No partner agreements. NVG8 embedded as their fractional ecosystem lead starting December 2021 and built the go-to-market from scratch across ~28 months. **Phases:** - Phase 01 (Months 1–3): AppExchange partner program prerequisites: Trailhead certifications, security review, ISVforce compliance, demo org - Phase 02 (Months 2–5): Structured field mapping: named Salesforce contacts (Revenue Cloud GM, VP Commercial Sales, Senior Director Product Marketing, regional PAMs), engagement tracker, targeted outreach with prepared POV - Phase 03 (Months 4–8): First co-sold deals, case studies documented and published to Salesforce Partner Community - Phase 04 (Month 9): Strategic ISV reseller partnership: 50+ task project plan across commercials, product, support, marketing, customer success - Phase 05 (Months 10–18): SI partner program: ZINKT Certified Practice framework, training and certification materials, scoping guide for SI AEs - Phase 06 (Year 2): FY24 GTM: $500K net new ARR target, AppExchange marketing promotions, customer advisory board, BDR program launch, reseller partnership moved to active co-selling **Key lessons:** AppExchange listings don't generate revenue. Active AE relationships do. Social proof compounds. Reseller partnerships close on project management discipline, not goodwill. SI programs take 6–12 months to generate first referral after activation. Start them early. --- ### I needed one place for every meeting. So I built a recorder in chat. URL: https://nvg8.ai/field-notes/meeting-recorder Source code (MIT): https://github.com/NVG8/recorder Calls happen across Google Meet, Zoom, Teams, phone bridges, and customer-provided links. The useful record (transcript, summary, action items) should live in one place regardless of which tool hosted the call. Built from empty folder to working prototype in 90 minutes using Claude Code, polished over ~14 iterations across two weeks. Audio stays local; one cloud call to AWS Bedrock for transcription and summarization; human in the loop by design. **Stack:** Swift, ScreenCaptureKit, parakeet-mlx (local transcription), Claude Sonnet 4.5 on AWS Bedrock, Google Calendar OAuth. **Key insight:** The right unit of software for personal productivity is narrower than most tools assume. One workflow, one folder, owned entirely by the person running it. --- ## Operate · Fractional GTM leadership Your go-to-market, run by someone who has run one. NVG8 embeds as a fractional CRO, COO, or Chief Partner Officer and runs sales, partnerships, and RevOps alongside the team, on its stack, for the quarter it matters. What NVG8 learns running it is what it builds next. ### Why fractional A full-time executive is the right answer eventually. Usually it is the wrong answer right now: a six-figure salary before anything has shipped, and six to nine months of ramp. Fractional puts the operating experience on the quarter you are in, at a fraction of the cost. When the role needs a permanent owner, the company already knows what that role does, and what good looks like. ### The three stages Sales, partnerships, and RevOps move through the same three stages, whether the motion is direct, through partners, or both. The stage decides the work, the duration, and the days a week. 1. **Establish** (3 to 6 months, up to 2 days a week): the motion does not exist yet. A go-to-market plan with a named target list; the first repeatable sales motion (who you sell to, how you qualify, a pipeline you can forecast); a partner map if partners are part of the motion, past the Salesforce field and the SIs (see the field note "Most partner plans stop at the partners you can see from inside Salesforce"); and the operating framework: cadence, metrics, decision rights. 2. **Grow** (3 to 12 months, up to 2 days a week): the motion works, now it has to run without the founder. People, process, and technology into one operating blueprint; the first systems that stretch a small team (rep briefings, pipeline rollups, partner updates, enablement content); a revenue plan per segment, channel, or partner tier with the metrics the board asks about; the performance loop. 3. **Scale** (3 to 12 months, up to 2 days a week): several motions, several markets. Resource allocation across segments, channels, and motions; market expansion and coverage decisions backed by pipeline data; leadership bandwidth on strategy and key relationships; a go-to-market that reports itself to the board. ### What the engagement is Options: fractional CRO, COO, or Chief Partner Officer, with a fractional RevOps lead when the motion needs systems, not just direction. Up to 2 dedicated days per week, adjustable as the motion moves. Priced on duration and days per week; the number is known before work starts. ### Who it is for B2B software companies, including ISVs in the Salesforce ecosystem, where the founder or a generalist is still running sales, partnerships, or ops alongside everything else. Companies where partner-sourced revenue is a real number, not a hope. If hiring a permanent executive, this is how to find out what that role has to do, and what good looks like, before signing. ### From the work - [What it actually takes to launch a net-new ISV on the Salesforce AppExchange](https://nvg8.ai/field-notes/zinkt-salesforce-launch): embedded as fractional ecosystem lead; AppExchange listing, Salesforce field activation, a strategic ISV reseller partnership, and an SI partner program. About 28 months. - [Eleven partners, 815 opportunities, and a scorecard the board could read](https://nvg8.ai/field-notes/partner-scorecard): partnership assessment, sourced versus influenced partner taxonomy, scorecard across 11 named partners, and the enablement layer. URL: https://nvg8.ai/operate --- ## Start the conversation Tell us the workflow that is eating your team's week. Thirty minutes, no deck, no obligation. Bring a workflow you're stuck on, an idea you're kicking around, or just a sense that there's repeatable work weighing your team down. The first call is for getting specific: what's possible on your stack, what isn't, and where it makes sense to start. If NVG8 isn't the right fit, that gets said on the call. - **Email:** info@nvg8.ai - **LinkedIn:** https://linkedin.com/company/nvg8 - **Website:** https://nvg8.ai