Use AI to solve one real business problem

An AI system can help structure research, draft content, compare options and organise repeated work. It cannot know the internal truth of a business from a vague request, and polished text is not evidence of a sound decision.

The four-step KEVOS working method

Interview: Ask for missing facts before giving advice. Confirm: Summarise what is understood, distinguishing facts from assumptions. Focus: Choose one problem and one measurable outcome. Check: Verify calculations, claims, compliance and proposed actions before use.

A prompt such as ‘help grow my business’ invites generic suggestions. A useful request says who the customers are, what offer exists, what resources are constrained, what evidence is available and what result would count as success.

Reusable context interview

Copy and adapt this prompt into a suitable business-approved AI service:

Act as a practical small-business analysis assistant. Interview me one question at a time before recommending action. Learn the business stage, offer, customers, current numbers, workload, goals and constraints. Do not request passwords, sensitive customer data or confidential supplier information. When the context is sufficient, summarise a concise business profile and label every uncertainty. Ask me to correct it. Do not give growth advice until I confirm.

Save the approved profile in an authorised internal knowledge location. Review it whenever strategy, customers or finances change. Do not assume AI memory is authoritative or complete.

Turn a question into a seven-day evidence test

Ask AI to propose an experiment with hypothesis, audience, offer, daily actions, maximum cost, evidence to collect, decision threshold and stop condition. It may help design the test; only customer behaviour validates the hypothesis.

For example, a hypothetical subscription business might interview five to ten actual customers, test a clearly priced trial and count genuine paid sign-ups. Replies such as ‘sounds good’ do not carry the same weight as orders. Maintain ethical, permission-based outreach.

Improving one repeat task

List routine activities by repetition, elapsed time, error cost and privacy sensitivity. Begin with a low-risk task such as transforming public product notes into a consistent internal checklist. Write the current steps, define acceptance criteria, draft an AI-assisted procedure and compare results across several real examples. Keep human approval for publication, pricing and customer commitments.

Measure benefit

Use a before/after log: task | baseline minutes | assisted minutes | review minutes | correction rate | cost | quality. Total assisted time includes fact-checking and rework. If a task saves four minutes but creates ten minutes of verification, it is not an efficiency gain.

Sample prompt for a repeated workflow

First interview me about one recurring administrative task. Ask where delays and errors arise, what inputs are available, who approves the result and what information must remain private. Propose a one-page standard operating procedure, a reusable template and a five-case pilot. Include a quality checklist, handoff owner, failure condition and a method to measure actual time saved.

Exercise

Choose one recurring task under an hour, low in sensitivity and easy to reverse. Establish a baseline, test a draft workflow, review five outputs and accept it only if reliability improves. Do not automate an undocumented exception process.

AI outputs are drafts and decision support, not substitutes for accountable owners or specialist advice.

Extended study: professional practice

Write a precise problem statement before opening AI

An AI request should begin with a management decision rather than a tool wish list. Write the current outcome, the desired outcome, the constraint and evidence of success. For instance: ‘Customer quotes take four days because technical details are missing. Reduce average quote preparation time without increasing specification errors.’ Specify what data may be shared and what requires approval. If the problem cannot be defined in ordinary language, AI may produce plausible-looking advice that does not address it. The first useful AI response is often a clarification question.

Interview before generation

Ask the assistant to question one topic at a time about the business stage, customers, resources, risks, operating process and goal. Require a confirmed profile containing only information relevant to the task. Mark each statement as confirmed, inferred or unknown, and correct mistakes before asking for a plan. A business profile might include sales channels and typical order sizes but omit confidential names and deal prices. Keep the version date and owner so stale assumptions can be detected. Avoid having the model invent detailed customer personas to fill gaps in real evidence.

Plan measurable small experiments

For a demand test, define the target group, exact offer, action sequence, maximum spend and success threshold. The plan should tell an operator what to do tomorrow, not just recommend marketing channels. In a seven-day trial, record how many eligible customers were approached, how many responded, how many requested prices and how many placed paid orders. Include the cost of running the test and the quality of delivery. Ask AI to propose several explanations for a weak result, then check those explanations against real observations. Never report a simulation as a commercial result.

Turn repeat work into an operating procedure

For a repeated task, document inputs, decisions, exceptions, outputs, acceptance criteria and reviewer before introducing AI. A draft purchase-order checklist might validate description, unit quantity, delivery address and approval evidence. Pilot on fictitious or approved records; compare with manual performance. If errors arise from missing source information, solve intake rather than simply rewriting the prompt. The best AI workflow often combines a clearer form, a deterministic spreadsheet formula, a human decision and optional generative drafting. Not every step needs a language model.

Measure economic effect after review

Suppose a monthly task occurs 80 times and requires nine minutes manually, or four minutes for AI generation plus three minutes of review. The gross savings are two minutes per instance, or about 160 minutes monthly, before software, setup and error correction. If review is bypassed, reported time savings are misleading and errors may become expensive. Track task volume, average elapsed minutes, exception rate, customer impact and net cost. Define an approval threshold and stop rule in advance. If the process fails important accuracy or privacy tests, do not deploy it regardless of attractive gross time numbers.

Make prompts reusable but not brittle

Store the business-approved task prompt with an owner, version, input schema, required output format, verification checklist and prohibited information. A useful prompt can request a structured table with columns: issue, evidence, option, risk, owner and next action. It should instruct the model to say ‘unknown’ when source information is missing and to distinguish assumptions from established facts. Test it using ordinary cases and difficult edge cases. A prompt is not a guarantee; outputs still need review, and changes in models or connected documents can change behaviour.

A reusable pilot brief

Write: Objective; business process; baseline metrics; permitted information; excluded information; input fields; expected output; rejection criteria; verification responsibility; pilot cases; budget; success rule; rollback plan. For example, a proposal-outline pilot could compare drafting time and the percentage of requirements accurately included, using public or synthetic project descriptions. Document what was corrected and why. The completed pilot brief becomes a decision record for whether the workflow should be used, revised or retired.

Primary learning references

• Australian Government small-business guidance.
• ATO for current Australian tax and super requirements.
• Fair Work Ombudsman for employment requirements.

Study note: Worked numbers and scenarios are educational illustrations, not actual client records or promises of commercial results.

Implementation laboratory: interview-first AI pilots

Define a realistic starting point

Before changing anything, create a baseline record dated at the beginning of the exercise. State what is currently happening, who owns the process, what happens when it fails, and what evidence is available. For this topic, give special attention to confident generic outputs that miss actual constraints. A single recent incident is not necessarily a representative trend, so look for several examples where available. If the process is entirely new, say that there is no observed baseline and use a synthetic rehearsal rather than describing assumptions as history.

Write a one-sentence objective in the form: “Over the next four weeks we want to improve [measurable outcome] while maintaining [quality or safety requirement].” Avoid using a vague outcome such as working harder, being more professional or creating growth. A useful objective contains an observable difference and a control that prevents apparent efficiency from concealing new problems.

Identify the people and decision boundaries

Consider the different responsibilities of the process owner, AI user, reviewer and customer representative. In a microbusiness one individual may hold several roles, but those roles should still be conceptually separated. Identify who prepares the information, who checks it, who approves a change, who carries it out and who records the result. If outside advice is required, identify the point at which the process must pause for that advice. Avoid giving software or an AI assistant implicit authority to make legal, financial or employment commitments.

Prepare a short responsibility table with the columns Input owner, Process owner, Independent check, Final approver and Backup contact. For a sole trader, the independent check may be a periodic external professional review instead of a second employee. The objective is accountability, not artificial complexity.

Build a small evidence package

An evidence package should contain the current procedure, one or more real or simulated examples, relevant figures, the expected output and a list of known exceptions. Remove confidential personal information from teaching materials. For a real business, store operational evidence in an approved private location with access limited to the people who need it. Link each figure to its source instead of copying it manually between documents without a reference.

Separate observed facts from forecasts and estimates. An observed payment date is a fact; a future customer’s payment is an assumption, even when it is a reasonable one. A change in accounting classification or business circumstances may alter which facts are comparable. Mark missing information explicitly and assign responsibility for collecting it.

Work through an exception rather than only the easy case

Normal scenarios are useful for learning the steps; exceptions test the quality of the process. Imagine that confident generic outputs that miss actual constraints occurs just before an important customer or statutory deadline. Which facts would you need immediately? Which decisions can be made under the existing authority? Which tasks could be paused safely? How would the customer, supplier, employee or adviser be informed where appropriate? What written record would be necessary to explain the response later?

Run the situation twice. First follow the present procedure. Then follow the improved procedure and compare clarity, elapsed time, error risk and confidence in the information. Note where the new approach merely moves work to another person. An effective improvement should not reduce one person’s workload by hiding costs or risk elsewhere.

Choose a review metric and define it precisely

The principal indicator for this exercise is net time saved after review and validated customer evidence. State the numerator, denominator, measurement period and data source where applicable. Decide what level of movement would be meaningful before seeing the results. Pair a speed or output measure with at least one quality indicator. For example, a process that closes actions more quickly but increases uncorrected mistakes has not clearly improved.

Review results using a small table: Period, Baseline or target, Actual, Difference, Reason, Corrective action and Owner. Do not infer causation from a single good week. Demand, seasonality, staff absence or unusual orders can affect outcomes independently of the process change.

Put an approval gate before an irreversible action

The major decision boundary is publishing customer-facing text or operational automation. Before crossing it, prepare a concise decision note: the available options, evidence, total cash exposure, dependencies, legal or customer obligations, reversibility, downside risk and the person authorised to approve. If information is missing, a smaller pilot may be preferable to a permanent commitment. Refusing to invent an uncertain input is a sign of a trustworthy process.

Agree a review date and an exit rule. An exit rule might limit an experiment to a fixed amount of money, a defined sample size or a certain number of weeks. The rule should be proportionate to the risk rather than copied from another business. Keep written approval evidence for consequential commitments and use specialist advice where required.

Complete a four-week practice cycle

First week: Describe the present method and collect baseline evidence. Do not redesign everything at once. Check whether the records can support net time saved after review and validated customer evidence and choose one narrow intervention.

Second week: Create the new procedure, checklist or template. Test it on a simple example and on a difficult exception. Document each correction and identify whether missing inputs or ambiguous responsibility caused the problem.

Third week: Conduct a limited live pilot where appropriate and authorised. An example of a suitably narrow outcome for this topic is testing an internal checklist on five synthetic cases. Measure time, quality and unintended consequences. Keep the ability to return to the prior process if the pilot fails.

Fourth week: Compare results, collect feedback from the people affected and write a decision: adopt, refine, retest or stop. Assign an owner and future review date. If no clear benefit appears, keep the evidence but do not claim success. The purpose of a pilot is to learn accurately, not to defend the original idea.

Reflection and transfer

Explain the principle to someone who has not read the chapter, without using jargon. Ask them to reproduce the calculation, review or process from your instructions. Any point requiring your verbal rescue is an opportunity to improve the documentation. Then consider where the same logic applies in another process: setting clear inputs, acknowledging uncertainty, naming decision rights, measuring outcomes and checking the effect on both money and people.

Completion evidence: a dated baseline, one-page procedure, exception test, recorded results and approved next action. These five records convert general business advice into a verifiable operating improvement.