During an ERP implementation, the hard part is rarely entering one transaction correctly.
The hard part is making sure the next person handles the same transaction correctly next week, including the exception nobody mentioned during training.
That is why good implementations depend on more than software. They need a clear process, the right data, defined permissions, checks, and an owner who knows what “done” means.
The same is true when you bring AI into business operations.
A one-off prompt can produce a useful answer. It does not yet give you an operating capability.
The bigger opportunity is to take a workflow that already works, teach it to AI, give the AI the right tools and boundaries, and make the result repeatable.
My shorthand for this is simple:
Do it once. Skill it Up. Do it again.
What is a Skill?
In plain English, a Skill is a reusable set of instructions that teaches AI how to complete a task, use the right tools, and check its work.
It is more than a saved prompt.
A prompt might say, “Prepare the weekly sales report.” A useful Skill explains where the numbers come from, which accounts to exclude, how to handle missing data, what format the sales manager expects, which checks must pass, and when a human needs to review the result.
The difference is important.
One asks for an output. The other preserves an operating pattern.
A recent OpenAI article described three company-specific examples that make this progression concrete. Basis demonstrated an onboarding process and turned it into a reusable Skill. Clay used persistent workspaces and dedicated account agents to keep scattered deal context current. Exa defined a workflow that could move an integration opportunity from discovery to a tested pull request, while keeping human review before anything shipped.[1]
These examples do not prove that every workflow should be automated. They show three useful building blocks: reusable instructions, persistent context, and bounded execution with checks.
Start with work you already understand
Many teams begin in the wrong place. They ask, “What can the latest model do?”
An operator starts elsewhere: “Which process do we understand well enough to teach?”
That could be:
- onboarding a new employee;
- preparing a month-end exception report;
- updating a CRM after a sales call;
- checking an invoice before approval;
- assembling an account brief before a customer meeting.
The first candidate should be stable enough to describe, frequent enough to matter, and bounded enough to verify.
Do not begin with “run finance” or “manage sales.” Those are departments, not workflows.
Begin with a job that has a clear start and finish.
The eight questions that turn a process into a Skill
Before you ask AI to repeat a workflow, document eight things.
1. What triggers the work?
Be precise. Is it a new employee record, a closed sales call, an invoice entering the queue, or every Friday at 4 pm?
A vague trigger creates inconsistent execution.
2. What context does the AI need?
List the systems, documents, business definitions, prior decisions, and current records required to do the job.
For a CRM update, that may include the call transcript, account record, pipeline definitions, and rules for handling uncertain information.
Persistent context matters when the work changes over time. Clay’s example is useful here: account information was spread across CRM records, email, Slack, calls, presentations, and other conversations, so the workflow needed a consistent place to keep current evidence close to each recommendation.[1]
3. Which tools may it use?
“Access” is too broad.
Specify whether the AI can read a record, draft a change, write a field, create a task, run a test, or send something externally.
Reading a CRM is not the same risk as changing a discount. Drafting an email is not the same as sending it.
4. What must it never do?
Good instructions contain stop conditions.
Examples: do not invent missing customer data, do not approve a payment, do not change an account owner, do not send externally, and do not proceed when required evidence is absent.
These boundaries prevent a helpful assistant from becoming an uncontrolled operator.
5. What are the known exceptions?
The normal path is usually easy. The exceptions reveal whether the person documenting the process understands it.
What happens when the invoice has no purchase order? When the customer uses a different legal entity? When two records disagree? When the sales call contains a commitment outside the approved price list?
If the answer is “someone experienced decides,” identify that person and route the exception to them.
6. What does “done” mean?
Define the artifact and the state change.
“Report prepared” could mean a spreadsheet exists. A better definition might require the correct reporting period, reconciled totals, an exception list, named source files, and a review status.
A Skill needs a definition of done that another person can inspect.
7. How will the work be checked?
Use proportionate verification.
A low-risk internal summary may need a source check and formatting check. A CRM change may need field validation and a before-and-after record. A payment or public communication needs a human approval gate.
Exa’s example is useful because the workflow did not stop at generating an idea. It prepared a pull request, ran tests, and held the work for human review before shipping.[1]
8. Who remains accountable?
The AI can perform steps. It cannot absorb management responsibility.
Name the process owner. Name the reviewer. Name who decides when the Skill changes and who investigates failure.
That is how you get a digital coworker without pretending there is no human boss.
Domain experts become AI architects
The person best placed to design this system may not be the person who writes code.
It may be the finance manager who knows why two invoice totals never match. The operations lead who knows which customer exceptions require a phone call. The account manager who knows which CRM fields actually affect the next handoff.
These people understand the workflow, the exceptions, the permissions, the risks, and the acceptable outcome.
That makes them AI architects.
Technical teams still matter. They connect systems, enforce permissions, create tests, and maintain infrastructure. But the operating logic has to come from the people who know the work.
The shift is from describing a desired answer to designing a repeatable job.
Repeatability beats prompt cleverness
A clever prompt may save ten minutes once.
A well-designed Skill can preserve how a team works, make execution visible, and improve through repeated use. When an exception appears, update the instructions. When a check catches a failure, strengthen the test. When permissions are too broad, narrow the tool access.
That is how capability compounds.
Not because the AI becomes magically autonomous, but because the organisation learns how to delegate with evidence and control.
Pick one workflow your team already performs well.
Document the trigger, context, tools, exceptions, definition of done, verification, and approval point.
Run it once with the AI. Inspect the work. Fix what failed.
Then Skill it Up and do it again.