Using generative AI in business: use cases and prompts

The book puts it simply. Normal software is programmed. Generative AI is trained, tuned and prompted. A prompt is the text you give the model to get an answer or a task done (p. 182).

Prompt engineering is the skill of writing that input well. Better input, better output. A weak prompt wastes time and money (p. 182).

The book’s own example: a weak prompt asks for a business plan for an AI start-up that helps lawyers. A better one names the target (small and mid-size law firms), the focus (case research and documents) and what to cover: market, challenges, revenue model, risks and technology (p. 182).

The book prints a 22-point prompting checklist, twice (p. 153-154, p. 231-232). You do not need all 22 every time. Here are six of them:

• Act as. Give the model a role, for example an expert or a critic.
• Context. The background, data or document it should use.
• Objective. What the answer is for: to inform, to persuade, to entertain.
• Audience. Who will read it.
• Format. Bullet points, an outline, an essay, a dialogue.
• Tone. Formal, casual, informative, persuasive.

The A chapter shows the role idea at work: one line to set the role, then a known copywriting formula such as AIDA (attention, interest, desire, action) or BAB (before, after, bridge), then your product (p. 15-16).

You do not have to put everything in one prompt. The C chapter shows a chain: summarize a document, rewrite the summary so a sixth grader can follow it, make the tone more formal, then turn it into slides with one key point each. The book notes the chain could also be one prompt; doing it in steps is a way to learn the tool (p. 31).

Each step is easy to check. If one step goes wrong, you fix that step, not the whole thing.

Two more habits from the book. Give examples of the style you want and say when an answer is good or bad, the way you would brief a new hire (p. 216). And when facts matter, ask the model for its sources (p. 192).

The P chapter turns prompting into company practice (p. 184). Train every member of staff, not only the technical teams. Get business, IT and data people to write prompts together, because a good prompt needs the business context. Write down the prompts that work and the results they gave. Add a short security and ethics policy that says what staff may and may not paste into a tool. And keep the finance team close, because the goal is a gain you can measure.

The productivity prompts show where to begin for each job. For a financial analyst, the book suggests a budget review to find savings and a comparison with competitors (p. 71). For an HR manager, a training program for new managers and a simpler performance review (p. 96).

The F chapter maps use cases by type of content (p. 61). Text: personal marketing emails, interview questions, chatbots, search over a knowledge base. Code: faster development, quick prototypes, synthetic data to train other models. Image: unique visuals and fast personalization for marketing and sales. Video: short clips, training videos with avatars, dubbing into other languages, live translation.

Best practice guide #6 looks by industry: new drug compounds, garment design, learning material that adapts to each student, ad copy, customer service chatbots, building design and code generation (p. 210-211).

Daily work is where most people start. The H chapter takes email as the test: the model can draft, organize, check grammar and set the tone of a message (p. 97). The J chapter does the same for job seekers: inquiry emails, cover letters, follow-ups, reference requests (p. 112-113). The S chapter does it for sales: prospecting ideas, follow-up emails, proposal rewrites and trade show follow-ups (p. 212-213).

Best practice guide #2 is about proving the value (p. 73-80). Set KPIs before you start: cost saved, time saved, quality, customer satisfaction, adoption, fewer errors, productivity, new income and lower risk. Count the direct costs, like tools, hardware, data and integration, and the indirect ones, like risk management, legal support, training and maintenance.

Then prove it small. Run pilots and proofs of concept before you scale, and test what happens when your main assumptions change (p. 79). The H chapter adds a warning: do not build a sophisticated business case on day one. Start with focused, low-risk use cases, learn, and grow from there (p. 91).

Next: risks, ethics and adoption.