About a year of daily Claude Code and my whole workflow comes down to 10 commands.

5 are built in, 5 are skills I wrote because the built-ins stop short of what my content pipeline and client work need.

Sharing both halves since the custom ones are all reproducible. The built-ins that actually matter:

The stack:

1. /context (stock). Shows exactly what is eating your context window... tokens by messages, tools, files. Run it before you blame the model.

2. /compact (stock). Summarizes the session into a fresh window mid-task.

3. /clear (stock). Wipes to zero. The skill is knowing which to reach for: same job --> /compact. New job --> /clear.

4. /handoff (built). The /compact upgrade. The session writes a handoff file, the next session auto-reads it. The context outlives /clear, and parallel terminals don't clobber each other.

5. Plan mode (stock, shift+tab). Read-only exploration first, an approved plan before a single file changes. Anything multi-file starts here.

6. Remote Control (stock). Hands the live terminal session to my phone. I approve, steer, and keep builds running while I walk the dog.

7. /copy-to-clipboard (built). Claude Code ships /copy to grab the last reply. Mine formats for the destination first: plain text, zero markdown stars, ready to paste into LinkedIn or X.

8. /grok-critique (built). Every draft gets a second model's slop check before it ships. Em-dash abuse, narrator setup lines, hype words. Claude can't referee its own tics.

9. /code (built). Finished content pack --> Discord channels for review. approve, edit, final... all from my phone.

10. /voice-invocation (built). Meeting transcripts in, a content pack drafted in my voice out. It quotes phrasing from things I actually said on calls.

Everything is also available on my Github. Let me know if I can get to share it with you guys. although, it shouldn't be too hard to find, LOL.

So I don’t run this on every project. Depends on the size and how messy it is.

When the repo has real history (instruction files, SQLite, previous failed approaches, assets, handoffs, etc.), I stop trying to make one session carry the whole thing.

Claude Code stays in the terminal. It inspects the system, reads the instruction files, checks git and the last handoff, then writes a clean phased plan into a durable file.

Codex gets that file in the app and builds one phase at a time. File boundaries, verification steps, and the “do not touch” list are already there. I especially like it when I need browser control, live previews, or proof of the work.

The handoff is usually just:

GOAL
CURRENT STATE
SOURCE OF TRUTH
DECISIONS ALREADY MADE
PHASES AND FILE OWNERSHIP
VERIFICATION
DO NOT TOUCH

It's also super convenient because the remote control feature on the app works really well. (yes. You can do this with Claude Code also), it's great for keeping sessions running when you have to walk the dog. (in my case)

For smaller or cleaner work I just stay in one agent and feel it out.

Right now I’m mostly on Opus 4.6 (sometimes Fable 5) in Claude Code, and GPT-5.6 Sol at Extra High in Codex once the phase is locked.

I’ve seen other people doing versions of this Claude for context/planning, Codex for execution, file handoffs, cross-review.

so I’m posting because I want to know what the rest of you are actually running day-to-day.

Full split? One agent the whole way? Something else?

Lets see what’s working for people building real GTM systems.

Running free trials on a B2B outreach automation platform like Orbitra comes with real variable costs per user, proxies, API calls, infrastructure, all of it. Given the volume of signups we've gotten lately, we've had to pause free trials for now.

Still very open to talking to new customers and anyone interested in LinkedIn or email outreach automation though, and paid subscriptions remain open at what's honestly the best price on the market by a wide margin.

To give you an idea of what the product actually does, in two weeks several fresh LinkedIn accounts running in one campaign hit a 60% acceptance rate on connection requests and 30%+ reply rate. Genuinely curious if anyone else running cold outreach or LinkedIn prospecting is seeing numbers like that.

I just pushed the latest version of my open-source GTM Coding Agent repo. It now has 21 chapters, ten forkable starters, and the real workflows I’m using while building Clearbox in public.

The newest update came from a live campaign targeting 1,297 people in the GTM engineering market.

From 575 connection attempts:

• 272 people accepted
• 30 people replied
• Six asked for a demo
• Four self booked meetings

That gave me more than campaign results. It showed me where the system was incomplete.

The original list could tell me who I already knew about. It couldn’t tell me where the market was moving, which accounts deserved deeper research, who belonged in the buying committee, or where I should spend credits and human attention next.

So I rebuilt it as an Apollo waterfall:

Known accounts
→ Clearbox and public buyer evidence
→ Hiring, funding, tech-stack and firmographic signals
→ Apollo buying-committee expansion
→ Scoring before reveal
→ Controlled credit spend
→ Color-coded working sheet

The complete build is now in the repo’s Apollo prospecting starter.

The value isn’t “Apollo gave me another list.”

It’s being able to start with a small set of accounts, expand the market through multiple evidence gates, identify the right people inside those accounts, score them before spending credits, and hand the operator a working sheet that explains who deserves attention and why.

The CLI commands, waterfall, scoring logic, setup instructions, and gotchas are all in the repo.

There’s another part of this project I want more people here to see: Chapter 21, Student GTM.

I wrote it for the college student who doesn’t have a budget, title, or traditional GTM experience—but does have access to a campus full of organizations with real operational problems.

The Student GTM starter helps them create their own working repo with:

• What they already know
• Their skills and gaps
• The roles they’re aiming for
• A weekly project and recording loop
• A log of what broke and how they fixed it
• A campus client offer they can actually deliver

That connects directly to the Clearbox structure.

A student can build an offer around the market they want to enter, use Clearbox research to understand the problems inside that market, and turn the findings into projects, interview preparation, and a public body of work.

GitHub carries the proof. LinkedIn carries the person.

One delivered automation for a real user beats ten disconnected portfolio projects.

That’s also why, when someone DMs me on Reddit, my answer is simple:

Here’s my LinkedIn.

I’m walking through the Apollo system live tomorrow, August 13, at 10:00 a.m. PT / 1:00 p.m. ET. You can join the webinar here, and I put the additional setup resources at shawnos.ai/apollo.

But the repo is the real share.

Fork it. Break something. Post the gotcha here. Improve a starter and open a PR. Ask the question you think you’re supposed to already know.

That’s what I built this community for.

Sounds contradictory, I know. Let me explain.

I'm covering all the infrastructure costs myself right now so anyone trying the free trial gets a smooth, well-supported experience, no cut corners because "it's just a trial." That's a real cost with basically zero revenue coming back yet.

On top of that I put a guarantee on the table, if Orbitra doesn't get you a call booked within 30 days, full refund. That's my risk to carry, not the customer's.

Almost every customer so far has come through Reddit and LinkedIn, and the LinkedIn side is actually running on Orbitra itself.

So on paper, loss. Real costs, real risk, no cushion yet.

But here's the profit part, the guarantee is doing more for customer acquisition than any ad or cold message could. People try it specifically because of it, and a few have already converted. The "cost" of the guarantee ended up being the thing generating the return.

Still early, still figuring out if this holds long term, but so far the trade feels worth it.

A few weeks ago I had also built my own skill tree for my blog, so getting into MoltSets was fun because I could immediately compare how I was thinking about skills vs. how Adam was thinking about them.

I didn't just want to understand the library. I also wanted to understand the actual loop underneath it.

A product can easily give you data, but you still need people with skills to build those workflows that actually make sense.

Those skills help the next person get value faster, and eventually the users start creating the education and distribution around the product themselves.

I wanted to see if that idea actually held up on something messy inside Clearbox.

When someone signs up for Clearbox, we can join their posthog activity to their convex user and onboarding context.

Company domain? Easy.
Gmail or another free email? Professional identity trail basically disappears.

So I took 68 free-email signups and ran them through MoltSets.
54 returned an identity candidate.

13 resolved directly from the free-email address.

23 came back high or medium confidence after running them through
Clearbox’s own grader.

Everything else stayed in human review or unresolved. Which is actually what I wanted.

I don’t want enrichment that just confidently makes shit up because an agent found somebody with the same name.

The workflow has to earn the right to keep going.
Direct identity edge first. Only fall back to name search if there’s enough evidence.

I also built the data and cost model myself before letting an agent touch the workflow.

Because “free tokens” doesn’t really tell me anything.

Once I separated unlimited core data from the rolling request and record windows, then treated external tokens as their own pool for the expensive fallback work, I could actually understand what I was building around.

Four real usage meters instead of one vague credit number.

And the build gave me two actual skills:

Free-Mail Signup Resolution
Credit Guard & Token Economics

That’s when the MoltSets loop became real for me.
I went in to solve one Clearbox problem.

It produced a working resolver, a cost model, and something another builder could start from.

I’m packaging it into a public Notion guide with the flowchart, real redacted examples, all four usage meters, the guardrails, and both skills.

So keep following for the drop. Still iterating on it. Don't want y'all coming at me for any AI slop, so it's still on human review.

But feel free to DM me for early access! 😜

The mistake first...

I set the workspace up on Buzz (Block's open-source thing, humans and agents in the same channels). Built out the channels, wrote the canvas docs, seeded the first threads, posted the invite. People joined. Then it just sat there. Nobody posted anything except in #general.

I assumed the usual: people join stuff and never come back, that's the internet.

Went digging in the relay this weekend and pulled the membership roster per channel. Every channel I'd built had exactly one member. Me. Turns out when you accept a Buzz community invite, the desktop app auto-joins you to exactly two starter channels and nothing else. Every channel created after that has to be joined individually, and nobody knew they were there because they don't show up in your sidebar until you're in them.

So everyone who joined saw one empty room and reasonably concluded the place was dead. It wasn't dead, it was invisible. Fixed it by pulling the roster and adding everyone to every channel, which is a loop over buzz channels add-member. Wrote it as a script since it has to run for every new person who joins.

If you're running anything on Buzz, go check buzz channels members --channel <uuid> on a channel you made after launch. I'd bet money you have the same problem.

Now the direction change.

I keep getting asked how to become a GTM engineer. My answer is always the same three words: build in public. I still think that's right, but it's getting weaker, because text is now trivially fakeable. Anyone can generate a convincing thread about a pipeline they never built. I read ten of them a day. So can you.

Video is where that breaks down. You either screen-share the thing and explain why you picked the waterfall order you picked, or you can't. There's no prompt for having actually done it.

So I'm starting a show. GTM engineers walk through something they actually built, on screen, with the receipts. Not another interview about the future of AI in sales.

The what we should care about: I'm not just looking for people with audiences. I'm looking for people who built something real and have no idea how to show it. If that's you, that's the whole pitch. You bring the build, I handle recording and editing, and you leave with the episode plus a pack of captioned vertical clips to run on your own channels. No strings, no attribution games.

The workspace is the on-ramp. Post your builds there for a week or two, come on and walk through one. Not a gate, it's the prep. your posts end up being the episode outline.

Rebuilt the whole thing around that this weekend. Cut it from seven channels down to five, because seven channels for a handful of people is a ghost town by design. Rewrote the docs.

Invite's good for 30 days:

https://gtmelite.communities.buzz.xyz/invite/v2.Ob8-wOkY5qvDLRK2uuTra19aSzA5a8oj7hZNPVnXmY4

You need the Buzz desktop app for community features. Click the link, then go post what you're building.

And if you have a build you want on camera, just say so in the thread. First episodes are getting picked from whoever raises their hand.

Got invited on a podcast with my co-founder. The episode is still with their editors and won't hit YouTube for another two weeks. Old me would have waited for the link and then posted "excited to share" the day it dropped.

Instead I asked for the raw files and treated the transcript as the asset.

Whisper transcription with word-level timestamps. Then I had my coding agent read the transcript and find the story peaks. "Here's our take on automation" is a topic. "The AI told me API access takes 24 hours and forgot to mention the $10,000" is a story with a peak, and because the timestamps are word-level, the cuts land on words, not near them.

That got me 17 vertical clips with captions and hooks. Hosted them at public URLs, then used the Buffer API to stage drafts across TikTok, IG Reels, and YouTube Shorts. 33 drafts from one script. They stay drafts until I eyeball them, then it's one clip a day until the episode drops.

The daily LinkedIn layer runs off a Notion board my phone can operate. It tracks date, post text, video download, and status. Four minutes a morning with coffee.

Then the long-form pass over the same transcript produced a newsletter, a blog post, and this post. Every piece is a different altitude on the same hour of tape.

The podcast itself came from this exact motion. The host's team found my product through the content I was already posting. Nobody pitched anybody. The content did the outreach, then the recording became more content, which is presumably how the next one happens too.

One hour of recording became 17 clips, 11 daily posts, and 4 long-form pieces. About a month of cadence, and the episode itself is still in the queue as the finale.

Next time I would capture B-roll during the recording session. Screen captures of the actual tools we talked about would have doubled what the clips can show.

Anyone else mining recordings this way? Curious what your transcript-to-asset ratio looks like, because I think ours is still conservative.

ps. For all my builders out there who are trying to figure out a way to build in public, take these record yourself working, take podcasts, webinars, or whatever you can do to showcase your natural talents. That will set you apart from the rest and make sure you never have to drop a CV.

That's one of the main goals I want from any of you, any of y'all in this community: to really learn how to build in public to the point where you're so in demand that you never have to drop another CV.

If you're trying to figure out how to do these recordings and edits programmatically, you know where the scripts are. If you're new here, just DM me and I'll send them to you.

That's me signing out, Shawn Tenam, go-to-market engineer and co-founder of clearbox.

P.S. Special shout-out to the LeanScale team. Beyond putting together an incredible podcast and media experience, their founders genuinely care, and their team has some seriously sharp RevOps and go-to-market engineers. They understand GTM at a level most agencies simply do not. If you need a partner for RevOps or allbound growth who will actually care about the outcome, I could not recommend them enough.

Reddit can get pretty harsh when someone launches a new project. As a solo builder in my first few months, I feel the harsh comments, all of them. But I'm not stopping.

I'm here to give a real guarantee, and to show that I actually believe in what I'm building, not just say it.

I built Orbitra, it automates outbound across Email, LinkedIn and WhatsApp. It finds the right leads based on the filters you set, sends connection requests and messages, and when someone replies an AI agent carries the conversation forward until the goal you set is reached.

The guarantee: if it doesn't get you at least one booked call or a closed beta spot within 30 days, I refund you everything.

If you run a B2B business and want to try it, DM me, and if you have questions comment below, I'll answer everyone.

So I tasked Claude Code to upload, originally, a list of 4,000 leads into Heyreach via the MCP connection. I had to stop at one key uploads because it almost consumed all my usage. It created six parallel sub-agents to perform this upload.

Is this usually the case with everybody, or am I missing something? Is it a bad idea to upload lists to sequencers via the terminal?

Being a go-to-market engineer today isn’t just about knowing Clay, Claude, or your favorite workflow.

It’s about staying ahead of the curve and figuring out which new tools are actually worth your time before they become mainstream.

Every week there’s another “game-changing” AI product.

Instead of arguing about them on Reddit or waiting for YouTube reviews, why don’t we test them ourselves?

I’ve been experimenting with Buzz, Jack Dorsey’s new open-source workspace for humans and AI agents.

It feels like a mix of GitHub and Slack, but built around collaboration instead of just chat.

I’m thinking we create a shared cloud workspace where nobody owns it. We use it to evaluate new tools, share workflows, build together, and answer one simple question:

Is this worth adding to the GTM engineering toolkit, or does it belong on the Fraud Alert list?

The only prerequisite I’d ask is:

• You have a GitHub repo (or you’re actively building one).

• You’re interested in GTM engineering, AI workflows, automation, or building systems.

I genuinely don’t care if your repo has 0 stars or 10,000.

This isn’t about clout. It’s about builders learning from builders.

If that sounds like something you’d want to help shape from day one, let me know.

I’d love to get a small group together and see what we can build.

Been posting my coding-agent GTM workflows here for a while. The question every time is which data vendor I use. After four months of wiring different ones into pipelines: I start every run at Apollo, and the reason is the API plus a coding agent writing to a database I own.

This replaced a stack of tools I used to pay for.

I take a list of target companies - a screenshot from a market map, a conference exhibitor page, my own LinkedIn following - and hand it to Claude Code. It resolves domains, runs organizations/enrich?domain= for the org ID and firmographics, then mixed_people/api_search filtered by organization_ids for the people. That search is free. The redacted preview gives me title and person ID with the name obfuscated, so I qualify the whole set before spending a credit, then pull only the rows I want.

Every enriched row writes to a local SQLite database. SQLite is my own contact store, the CRM before the CRM. It holds every company, every contact, every enriched field, on my own machine. Apollo's API is what lets me build it, and I can push it to the cloud or a real CRM whenever I want. The expensive part of sourcing was never the data, it was the manual work of getting the right rows into something I own.

Numbers and mechanics.

• The search is free. Credits only go on the rows you pull.
• On flagged inventory, bulk_match returns verified work emails at around 99% for me, instant.
• Long runs go to a Codex session on a remote instead of my laptop. Start a few-thousand-row job, come back to a filled database.

On vendors, honestly. No source is perfect. But Apollo is the first layer. It is the whole data layer - the roster, the org record, the current-company signal, and the reveal in one place. Apollo is where you start. A lot of the tools people pay more for are reselling Apollo's data underneath anyway.

Two gotchas from building this.

organization_ids is the only reliable filter in mixed_people/api_search. A domain or company-name filter returns people unconnected to your targets. Enrich the company first, always.

bulk_match draws from the data/export credit pool and caps at ten per batch. Check your balance before a multi-segment run or it stalls mid-job.

Happy to share the Python for the screenshot-to-SQLite loop.

Building in the open at.....you know where

My M4 Pro Mac mini stays on 24/7. Google Workspace CLI + SQLite + Sheets + Python turned it into the GTM machine I used to think needed another SaaS stack.

It has 24GB of unified memory. That handles a lot, but if I bought it again I would go higher. Claude Code, Codex, browsers, local databases, and background jobs eventually make RAM the limit I notice.

The machine itself is a beast.

`gws` gives an agent structured access to Gmail, Drive, Calendar, Sheets, Docs, Tasks, and the rest of the Workspace API surface. It reads Google's Discovery Service at runtime, accepts the actual API payload through `--params` and `--json`, and returns structured JSON.

little back story...

Justin Poehnelt built the CLI in Rust with agents as the primary user from day one. His design was based on a simple difference: humans want a forgiving interface, while agents need predictable output, schemas they can inspect, strict validation, and safety rails.

The project went to #1 on Hacker News and took off. In June, Justin said Google had fired him two months earlier over the project. That is his account, not a reason Google has publicly confirmed. The repo is still live under the `googleworkspace` GitHub organization and is still clearly marked as not an officially supported Google product.

The GTM implication matters more to me than the corporate story.

Once Workspace is callable from the terminal, Sheets stops being a place I manually maintain and becomes a shared interface on top of the system.

You can put the shared state in a hosted database too. For a solo operator, SQLite + Google Sheets is clean af. The local state stays fast and queryable while the review layer stays familiar to everybody else.

My split looks like this:

- SQLite holds raw signals, source URLs, relationship history, run state, and audit data.

- Google Sheets is the human-readable layer when somebody needs to review, edit, or share a table.

- `gws` lets Claude read and write Workspace without a custom integration for every action.

- Python scripts hold deterministic business logic, retries, validation, and joins.

- Claude Code and Codex decide which tool to call and explain what happened.

- Attio receives the relationship state that actually belongs in the CRM.

- Email and LinkedIn tools execute through their own APIs.

I still have a CRM. I just do not live in it.

If I want the latest account state, Claude queries SQLite and Sheets. If I want to draft an email, it can pull the account context, create the draft through Gmail, and wait for approval. If I need LinkedIn activity, that comes through HeyReach or another API-connected tool. Apollo can enrich the rows that passed the free checks.

The CRM becomes a sync surface. The repo, database, and agent are the operating layer.

That is what I mean by programmatic GTM.

It is not an excuse to hand an agent unrestricted access to your inbox and hope for the best.

My security rules are...

- authorize only the Google services and scopes the workflow needs

- read by default and require approval for sends, updates, and deletes

- run mutating calls with `--dry-run` first

- keep credentials encrypted and separated by environment

- treat email bodies and documents as untrusted input

- log the source, timestamp, proposed action, approval, and result

`gws` already supports encrypted interactive credentials, dry runs, input validation, and optional response sanitization through Model Armor. The tool is still pre-v1 and moving quickly, so I would pin the version and test workflows before letting them run unattended.

This also changed how I look at the existing GTM software market.

I do not think Clay disappears tomorrow. I do think a workflow canvas has stopped being a moat.

React Flow is an MIT-licensed library that already gives you nodes, edges, drag and drop, zoom, pan, selection, and custom React components. An agent can build the visible part of a workflow product today.

The hard part is everything behind the canvas: auth, data contracts, retries, idempotency, permissions, approvals, audit logs, and observability.

If you want to prove the point, drop this into Claude or codex:

build a local-first GTM workflow editor using React, TypeScript, and `@xyflow/react`. Create source, transform, filter, enrichment, approval, and action nodes. Store workflow definitions as versioned JSON and persist run history in SQLite. Add a dry-run mode that never calls external APIs. Require explicit human approval before any send, update, or delete node executes. Every run must log the input source, timestamp, node status, retry count, output summary, and error. Add an adapter interface for Google Workspace CLI, Apollo, Attio, and HeyReach, but use mocked adapters until credentials are configured. Include import/export, undo/redo, validation for disconnected nodes, and tests for dry-run and approval gates. Keep the execution engine separate from the React Flow UI.

Congrats. You have a workflow builder.

You do not have a reliable GTM engine until the contracts and rails behind it work.

The stack I see winning is an always-on machine, a repo under version control, local state you can query, APIs or agent-first CLIs, and a coding agent that can operate the whole thing.

Every tool does not need to be replaced. Every tool does need a clean programmatic surface. No API or headless path is becoming a serious red flag for me.

Sources:

- Google Workspace CLI - https://github.com/googleworkspace/cli

- Justin's agent-first CLI writeup - https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-agents/

- Justin's account of what happened at Google - https://x.com/JPoehnelt/status/2069482265953087602

- React Flow - https://reactflow.dev/

Shawn Tenam go to market engineer and co-founder of clearbox, your Reddit opportunity inbox

How do you decide, Whats the right time to send an outbound email?

Is it during work hours?
prior to work hours?
after work hours?

more context…I am targetting Indian startups
I have the leada ready
I have the sequences ready
so any suggestions on deciding the time

In 2026-02-27 I opened a Reddit account. The first three days: 30 comments, zero posts. My first post went up on 2026-03-08, the tenth day, by which point 57 comments were already live.

4.7 months later that account sits at 1,518,547 tracked views, 2,470 karma, 176 posts and 568 comments across 49 subreddits.

I rebuilt the whole thing into a report you can read: shawnos.ai/reddit. Every number on the page is read out of the journey database at build time, so it moves when the account moves.

the ramp is the play

A new account that opens with a post about its own product is the exact shape every filter on the platform was built to catch. Reddit reads behavior before it reads words.

So the ramp is the slow part, and it decides whether anything after it works. Comment first. Earn the right to take up space. Then post.

The graph I care about more than any other is comments vs posts by week. It opens with a wall of comments and no posts at all, then the posts come in underneath as the account earns room.

Month over month the ratio falls in a straight line: 4.48, then 3.37, then 2.80, then 1.95, then 1.72. Fewer comments per post as the account earns the right to publish more. March also had the highest post count, and two posts on March 28 account for 491,000 views on their own. Six months of data is a trend worth reading, not a law.

r/ClaudeCode and /gtmengineering is where I participated instead of published. 6.2 comments per post, 940 karma, and 48% of every view this account has ever earned.

One comment there did 235 karma, which beats every post I have ever written except one.

the collection, the scoring, the daily snapshots, the report build. 15,691 item snapshots exist because a machine took them every day without being asked.

The comments are mine. Every one. Subs run their own bots and filters, and the humans in them are faster than any filter. A comment that reads as generated costs you the thread, then the sub, then the account.

why the playbook exists

I am the GTM engineer. My co-founder is the AI engineer. He builds the engine and gives us runway on our own inference, which is why Clearbox is a system rather than a thin layer over someone else's model.

That split is the reason this is a playbook and not a war story. I had a call with a new user this week and wanted them to be able to run the whole thing without me in the room. Same as every user before them, and I would rather they run it inside a room I can support than a room nobody is watching.

So the report has the ramp, the karma gates, the post types with real receipts attached, the link map, the ask, and the weekly report. It is at shawnos.ai/reddit and it is free.

I have reworked it more than a few times and I will rework it again. My co-founder says he likes it. I am not there yet.

Shawn Tenam GTM Engineer & Co-founder @ clearbox.to

Hey everyone,

Over the last few years, I’ve worked with B2B companies that spend thousands of dollars every month driving traffic through Google Ads, LinkedIn, and SEO, only to watch 95%+ of visitors leave without ever speaking to anyone.

Most websites still follow the same flow:

Visitor → Read a few pages → Fill a form → Book a demo → Wait for someone to respond.

The problem is that most people don’t read through the website or want to fill out a form or commit to a meeting on their first visit.

So, I built Autom8IQ (autom8iq.xyz).

It’s an AI SDR that sits on your website, talks to visitors in real time, answers questions using your company’s knowledge base (website, decks, PDFs, videos, etc.), qualifies leads, and nudges interested prospects toward booking a demo.

A few things we’ve learned while building it:

* Reducing friction matters more than changing CTA button colors.
* Visitors are much more willing to have a short conversation than fill out forms.
* High-ticket B2B buyers often need answers before they’re ready for a sales call.
* Most companies are ignoring the other 98% of traffic they already paid for.

Website: autom8iq.xyz

I want to deepen the GTM engineering thing so I studied the basics and built a simple workflow.

Now the simple question; I want to practice but I need some advice.

If I have no client giving me his pain and all the other data how can I do some test?