Free AI training: build, sell and deliver useful work

Start with a problem, not a tool. “What can AI make?” produces demonstrations; “which decision can I improve?” produces an offer. Map a visible situation, the person affected, the decision to improve and a controllable deliverable. A local business may need a clearer request path; a team may need a structured brief; a founder may need a qualified list of accounts. AI can prepare work around those frictions, but you must observe and validate them.

Build a short proof: a mock-up, a page, a procedure or an audit with three verifiable observations. Label assumptions, required approvals and exclusions. Never promise revenue, rankings or a deadline you do not control. A responsible offer also excludes unplanned sensitive data, critical integrations, automatic sending and decisions made without a person. Those boundaries make an experiment sellable.

Before producing anything, ask five questions: who owns the priority, which evidence supports the problem, what deliverable can be reviewed, what requires client or specialist approval, and what happens if the solution is not adopted? If the only answer is “AI can do it”, the offer is still too vague. A clear starting point, result, limit and owner create a serious basis for a conversation.

Keep a compact decision record. It should state the observation, source, interpretation, confidence level and next check. This protects you from turning public hints into claims about a business. It also lets a colleague understand why an account was selected or why a prototype was built.

Claude and Codex are useful when they receive usable context and a defined outcome. Claude can help structure a messy brief, compare options, review a proposal, summarise notes or prepare a FAQ. Codex helps with code and projects: exploring a codebase, proposing changes, explaining errors, creating web applications and structuring tests. Both require business and technical review.

Work in small loops: define users, authorised data, constraints and acceptance criteria; ask for a plan; review it; request a limited version; test real cases; correct it. For Claude, ask it to separate facts, assumptions and unanswered questions. For Codex, identify the relevant files, a testable task and constraints such as “do not alter payment integrations”. Keep a journal of the request, version, assumption, validation and next action.

When a draft is ready for review, compare it with the approved brief, identify who can approve business facts, and record the resulting decision. This is a practical safeguard for teams, not an extra administrative task.

Capabilities depend on the product, configuration and project permissions. Before selling an AI-assisted workflow, check the official Claude Code documentation and the official Codex documentation, then test the workflow in a non-critical environment. In this guide, Claude and Codex are work assistants, never autonomous systems that guarantee a commercial outcome.

Use a seven-step sequence: choose a narrow segment; research ten cases without contact; write three possible problems; define a micro-offer; use Claude to structure the brief and Codex for a prototype; test a real scenario; document what changes before increasing volume.

For example, an imagined service business receives incomplete requests. The offer is not an AI agent that doubles sales. It is a qualifying request page, a simple follow-up view and a response guide. Claude can propose questions from an approved brief; Codex can build and test the form. The business validates language, questions and data handling. Charge discovery when it is real work, and separate an exploration phase from an uncertain final outcome.

In the delivery procedure, retain the validation record with the client brief, the person who approved business facts and every open question still requiring an answer.

A professional website or application begins with a specification: audience, desired action, necessary pages, client-supplied information, forbidden claims, existing tools and definition of done. For an application, add user roles, data, security rules, failure scenarios and a rollback path.

Ask Codex to work incrementally: information architecture, static page, form and validation, then tests and accessibility. Check mobile rendering, links, mandatory fields, error messages and readability at every stage. Be specific: state the files, objective, acceptance criteria and constraints. Never move a demonstration into production simply because it works on one computer. Explain to the client what AI assisted, what was reviewed and what remains to be tested.

Before handover, use an acceptance checklist:

• content reflects approved information;
• every call to action works on mobile;
• form errors are understandable;
• the owner knows how to request a change;
• backup and support routes exist.

This is what separates an impressive prototype from a useful product. You sell implementation that can be reviewed and resumed, not just screens.

Use Claude before an outreach message, not as a substitute for a relationship. It can summarise research notes, identify questions, prepare two versions of a message or test whether a promise is clear. Give it sourced facts and ask it to flag gaps. A well-written sentence is not automatically true.

A responsible message contains a real context, a verifiable observation, a cautious consequence and a no-pressure invitation. Recheck the company name, link, trade and nuance. Tools such as SprintLead can help find and organise companies that fit useful criteria, retain signals and prepare a next action. The purpose is not more messages; it is a defensible reason to begin a conversation. Keep source, observation, confidence and next action in the CRM.

Keep each account’s source, observation, confidence, status and next action. CRM completeness for usable qualification is useful context: a record should support a human decision, not create a reason to contact someone automatically. Review names, links, role and wording before every send.

A micro-mission makes buying easier: clarify an offer page, prototype a form, clean up a content process, prepare a knowledge base or build a qualification view. It has a visible result, calendar, dependencies, price or estimation method and a decision point.

Do not sell “AI will automate your business”. Describe what you deliver and how conformity is checked: planned pages exist, the form was tested, business information was approved and the owner received a handover. Separate discovery, design, production, validation, launch and support. Record out-of-scope work, then offer a separate step. Never sell something you cannot explain, test and take over.

A simple proposal structure helps: observed context, mission objective, deliverables, exclusions, client responsibilities, validation calendar, acceptance criteria and next decision. Price uncertainty honestly: charge a diagnostic when the problem is undefined, a build when scope is clear, and a time-limited improvement stage when usage must be observed. AI speeds preparation, variants and tests; it does not replace validation, integration or accountability.

At first, track system quality before revenue: research time per account, reviewed messages, answers that confirm or challenge assumptions, meetings, refusal reasons, production time, scope changes and post-delivery corrections. Every week, review ten accounts and label them contact, observe or exclude. Re-read sent messages and confirm each observation. Change only one element at a time: segment, offer, opening question, checklist or delivery process.

For a clearer commercial workflow, SprintLead features can help centralise qualification and follow-up. The goal is traceable context for a useful follow-up and clean handoff, not high-volume outreach.

Use existing guidance on CRM fields for verifiable priorities to retain evidence behind a commercial decision. Training is useful only when it improves the next choice, not merely the next prompt.

Week one: choose a segment, observe visible frictions and test Claude on notes; make an internal Codex mock-up. Week two: write the micro-offer, build a labelled demonstration, test it on mobile and prepare your handover checklist. Week three: approach a small number of accounts that meet your criteria, verify every observation and record replies and objections. Week four: decide whether the segment understands the problem and whether delivery is clear; improve one component only.

This modest plan turns learning into practice. You earn through a held offer, not a fragile claim. AI becomes a quiet accelerator while your method, quality control and accountability remain the value.

Practice exercise one: write a one-page brief for a service you understand. State the user, moment of friction, current process, decision to improve, available sources and reviewers. Ask Claude for discovery questions and a deliverable outline; remove any detail it cannot justify. Practice exercise two: choose a non-critical page or internal form and write four acceptance criteria before asking Codex for code. Test keyboard use, errors, mobile display and unsupported inputs. Practice exercise three: show the example to a knowledgeable person and ask what problem they understand, what is missing and what they would validate before paying. These questions create an offer from evidence rather than vocabulary.

Moreover, write a quality rule: no Claude output is sent without review; no Codex change is delivered without suitable testing; no prospect is contacted without an exact observation; no project is called successful without an agreed criterion. Therefore the speed of AI protects rather than damages your reputation.

Turn each exercise into a five-line learning record: starting problem, tested action, observed result, limit and next improvement. This becomes a method library instead of a collection of prompts. When presenting an offer, show the reasoning: observation, deliverable, expected approval and next step. A client can then assess priority and risk without believing a technology promise.

Separate reusable components from work that must remain tailored. A page checklist, brief outline or form test can become stable. Business understanding, evidence, data approval and the next decision remain client-specific. This separation improves efficiency without treating companies as interchangeable targets. It also restores practical detail to the 30-day plan: in week one collect evidence; in week two validate a demonstrator; in week three review every message; in week four change one documented system component.