You can start Claude consulting with a business process you already understand. Build a Claude workflow for one part of that process, show the client the input and output, and explain how a reviewer will catch a wrong result.
A business analyst still needs technical skills, but the first skills depend on the service. To improve requirements work, you need to choose which documents Claude may read, write clear instructions, check every answer, control who has access and teach the team how to use the workflow. To build software with the Claude API, you also need to secure user access, record system activity, test failures, manage cost and support the application after launch.
Start with a service a client can understand. Name the job you will improve, the result you will deliver and the checks the client will use.
Start with a business process you understand
Claude knowledge on its own is easy to claim. Domain judgment is harder to replace.
A business analyst may already know how to run discovery, separate a symptom from a requirement, map a process, write acceptance criteria and challenge an unsupported assumption. An SAP consultant may understand order-to-cash controls. A QA lead may know how to turn release risk into a test strategy. These are useful consulting foundations because the client is buying a better work result. A demonstration of a chat interface does not establish that result.
Write down three things before choosing a course or credential:
- The work you understand. Name a process you can review without guessing what “good” looks like.
- The repeated friction. Identify a slow, inconsistent or difficult step in that process.
- How the client will check the work. Decide what a reviewer can examine: missing requirements found, document-review time, links to source passages, or instructions another person can follow.
This produces a narrower and more credible starting point than “I help companies with Claude.”
Choose one service you can deliver well
These three services require different skills and client checks.
| Service | What the client receives | Suitable starting point | Main risk to control |
|---|---|---|---|
| Workflow assessment | A documented current process, candidate use cases, constraints and a pilot recommendation | Strong domain experience; limited implementation experience | Recommending AI where the process or data is not ready |
| Team enablement | Role-specific exercises, safe-use guidance and a manager adoption plan | Strong facilitation and role knowledge | Teaching features without changing real work |
| Workflow implementation | A configured or coded workflow, evaluation evidence, operating instructions and support terms | Delivery experience plus the required technical skills | Reliability, data access, ownership and maintenance |
A workflow assessment is often the clearest first offer for an experienced practitioner entering AI consulting. You map one current process, identify where Claude may help and recommend whether the client should stop, train users or run a pilot. Team training works when you can teach with the client’s actual tasks. Offer implementation only when you can build, secure, monitor and support the workflow.
Do not sell all three as one vague “AI transformation” service. Each has different inputs, acceptance criteria and handover requirements.
Match technical skills to the service
The answer depends on the service.
For a workflow assessment, you should be able to explain what the model receives, what it produces, where sensitive information could enter, how a human checks the result and when the workflow should stop. You should also be able to distinguish a useful prototype from a deployable process.
For team training, create examples from the participants’ jobs. Show how the prompt uses named source documents, demonstrate a believable wrong answer and teach people how to check the result. A generic list of prompts is not enough.
For an implementation, add the relevant engineering skills: API use, authentication, permissions, data handling, error recovery, logging, evaluation, cost controls and deployment. Anthropic’s documentation recommends structured state for repeatable work and verification tools for autonomous tasks; its model-deprecation guidance also tells developers to test replacements before a current model retires. These are operating concerns that go beyond prompting. (Anthropic prompting guidance; model deprecations).
If these implementation skills are outside your background, collaborate with an engineer and define the division of responsibility. “I can prompt well” is not a substitute for someone owning credentials, logs, integrations and production failures.
Credential, partner status and portfolio proof are different
These three signals answer different questions.
- A credential says an individual completed the issuer’s assessment under its current rules.
- Partner status describes a firm’s relationship with the provider and may include program requirements, support or market visibility.
- Portfolio proof lets a prospective client inspect how you approached a problem and checked the work.
Anthropic’s June 2026 Partner Network announcement makes the distinction explicit: certifications belong to individuals, while service-partner tiers apply to firms and are measured using certified practitioners, production customers and public customer stories. New applicants begin at the program’s Registered level, while the published Services Track starts at Select with additional requirements. (Anthropic Partner Network Services Track, 3 June 2026).
That source does not say every independent practitioner must join the Partner Network before offering consulting. It also does not make a credential proof of successful client delivery. Check current provider terms and any client procurement requirement before making a platform or affiliation claim.
For someone starting out, the practical order is:
- Learn enough to perform one narrow service safely.
- Build a work sample using non-confidential material that a client can review.
- Deliver a pilot with a fixed task, time period and set of client checks.
- Pursue a credential or partner route when it helps a real buyer requirement or practice goal.
This sequence does not diminish certification. It prevents the badge from carrying a claim it cannot establish by itself.
Build a portfolio case a client can check
A useful portfolio case shows the input, action, output and check. A screenshot of a successful response supplies only the output.
Illustrative case: requirements-quality review
This fictional practice case uses no client material.
Input: A two-page brief for an internal leave-approval workflow. The brief contains six deliberate ambiguities: missing approval limits, no exception path, inconsistent role names, no audit requirement, an undefined response time and no owner for policy changes.
Action: Give Claude the brief and a review instruction that asks it to:
- quote the passage supporting each finding;
- separate an observed omission from an inferred risk;
- draft clarification questions rather than invent missing policy;
- return a table with source passage, issue, business impact and question.
Anthropic recommends asking Claude to ground long-document responses in source quotations. That pattern makes the reviewer’s job easier because each finding points back to the supplied material. (Anthropic prompting guidance).
Output: A requirements-review table and a short list of questions for the process owner.
Check: Compare the output with the six planted ambiguities. Record true findings, missed issues, unsupported additions and duplicate questions. Then revise the instruction and repeat the check on a second brief.
The portfolio page should show the fictional brief, the instruction, selected output, the score and the change you made after the first attempt. A client can then see how you found errors and improved the workflow. The example does not prove that the workflow will perform the same way on every client document.
Decide which service is ready to sell
Use the same fictional leave-approval brief to compare three offers before you advertise them.
| Offer | Deliverable | Acceptance check | Failure you own | Ready now? |
|---|---|---|---|---|
| Workflow assessment | Current-state map, six ambiguities, risk notes and stop/train/pilot recommendation | Process owner can trace each finding to the brief | Unsupported recommendation or missed material constraint | Yes, after the second unseen brief is reviewed |
| Team enablement | Role exercise, safe-use rules, facilitator guide and manager follow-up | Participants identify planted gaps and escalate policy questions | Training teaches prompts but leaves roles and approvals unclear | Conditional on facilitation evidence |
| Implementation | Working workflow, access design, evaluation record, runbook and support terms | Fixed cases pass and failures are visible to the owner | Incorrect output, exposed data or unowned operation | No, unless engineering and support ownership are present |
The second brief is the important check. Keep its planted ambiguities hidden while you revise the method on the first brief. Then freeze the instruction and score the unseen brief for true findings, missed issues, unsupported additions and duplicate questions. A good first result followed by a poor unseen result means the method is not ready to sell as repeatable.
This matrix changes the commercial decision. The analyst can responsibly offer an assessment before claiming implementation capability. Training becomes credible when the exercise and manager follow-up are complete. Implementation waits until the account, security, engineering and support duties have named owners.
Turn the portfolio into a credible first conversation
Do not lead with “I am a Claude expert.” Lead with the work problem and the proof.
After completing and checking that case, a useful introduction could be:
I help business-analysis teams review requirements for missing decisions and weak traceability. I built a small Claude-assisted review using a fictional brief, then checked it against planted issues. I can show you what it found, what it missed and how I would assess whether the method fits your documents.
That gives the buyer something specific to challenge. It also creates a natural discovery conversation:
- Which documents consume the most review time?
- What errors are expensive when they escape?
- Which information cannot be used in a pilot?
- Who decides whether an output is acceptable?
- What must the team operate after the consultant leaves?
The answers determine whether the next step is an assessment, training session or implementation pilot.
Decide who owns the Claude account and client files
A consultant may prototype quickly in a personal workspace, but client delivery needs a clear owner. The proposal should identify who owns the account or API project, who can access the source material, where instructions and evaluation cases live, and what the client receives at handover.
For enterprise work, retention, security and administration vary by product and contract. Anthropic currently documents custom retention controls for Claude Enterprise and distinguishes commercial products from consumer products in its privacy material. Those facts should be checked against the client’s actual plan and agreement, rather than generalized from a personal Claude account. (Claude Enterprise retention controls; Anthropic commercial-customer privacy collection).
If you cannot describe ownership and handover, you do not yet have a client-ready implementation offer.
A 30-day practice route
Use the month to produce evidence. Labels can wait.
Week 1: Choose one workflow. Interview two people who perform it, or use your own previous role knowledge. Write the starting input, expected output, common failure and reviewer.
Week 2: Build the case. Create safe fictional source material with deliberate edge cases. Draft the instruction, run the workflow and retain the outputs.
Week 3: Evaluate and repair. Use a scoring sheet. Count planted issues found, unsupported claims, missed constraints and reviewer corrections. Change one part of the workflow at a time.
Week 4: Package the service. Create a one-page scope for an assessment or pilot. State what the client supplies, what you do, what they receive, how acceptance works and what remains outside scope.
At the end of the month, you should be able to show how you work. That is the foundation for a consulting conversation.
What to do next
Choose one business process you already understand and build one case that a client can examine. Keep the source material fictional or properly authorized. Label every assumption, and give the reviewer a clear reason to reject a bad output.
Poorna Reddy writes practical guidance for professionals who want to turn AI skills into client work they can show, test and hand over. Follow Poorna Reddy and read the next guide on agreeing and pricing a first Claude or OpenAI pilot.