Boundary
What starts the work, and what exactly counts as done?
Name one trigger and one result your team can recognise.
Digital EmployeeHire a digital employee.
Hire a digital employee.
Not another chatbot.
A digital employee handles one repetitive internal workflow, such as purchasing, dispatch, or a daily operations report, within an agreed scope. We map the real records, rules, permissions, approvals, stop conditions, and action evidence. Routine steps can proceed; missing data, conflicts, failed writes, uncovered rules, and consequential actions pause or go back to a named person.
Example workflow using synthetic data. The business and records are fictional, not a client result.
If the workflow is a fit, the one-time paid pilot is NZ$999.
Scope, access, connection method, and timing are confirmed before payment.
The Everyday Pain
The work that never makes the to-do list.
It is not the big projects that drain a small business. It is the same internal jobs, every single day, that someone has to keep on top of. Buying in, sending out, and keeping score.
Restocking from memory
You re-order from three different suppliers, copy numbers between a spreadsheet and your email, and still find out a fast-mover is out of stock only when a customer asks for it.
Getting orders out the door
Match each paid order to a courier, print the label, update the tracking, message the customer, and fix the one address that was typed wrong. Every day, over and over.
The report nobody has time for
Yesterday's sales sit in the POS, the cash in the bank, the jobs in the booking system. Nobody pulls them into one view, so you run the week half blind.
What It Does
One workflow, run by agreed rules, with clear hand-offs
A digital employee is not a generalist. It is scoped to one internal workflow. When the records and rules allow, it prepares or performs the permitted step; when they do not, it pauses, stops, or hands the exception to the named person. Common examples include:
Purchasing and restock
It can read approved stock records, flag low items, and prepare a purchase order for a named person to review. Missing supplier details, conflicting stock records, or anything outside the rule pauses the workflow.
Order fulfilment and dispatch
It can prepare the courier booking, shipping label, tracking update, and customer message from approved order records. Physical handling stays with staff or the fulfilment provider, and an invalid address or failed update pauses the path.
Daily operations reporting
It can assemble a morning brief from approved fields in the systems named for the workflow. Missing, late, or conflicting records are shown as exceptions rather than silently filled in.
Supplier and inventory chasing
It can identify overdue purchase orders, missing invoices, and unconfirmed suppliers, then prepare a follow-up or send it only when the live scope permits that action. Anything outside the rule waits for its named owner.
Reference implementation using synthetic data
Inspect a complete daily operations run
Follow example records through checks, exception rules, a human approval, a failed writeback, human-led recovery, the morning brief and the action log. The business and every record are fictional.
Choose the first workflow
Choose a meaningful job you can bound
Start with a repeated hand-off or breakdown that matters to daily work. Among those ideas, bring the one you can define most clearly through these three boundaries. It does not have to be the biggest or the easiest.
Evidence
Which system or record will be used to verify that it is done?
Name the record your team trusts when information disagrees.
Control
What may a first version read or prepare, and what must wait for a named role to approve or take over?
BestAI confirms the actual access and controls during mapping.
Bring one candidate sentence
When [trigger] happens, the workflow should help [team] complete [job]. It is done when [result] can be verified in [trusted record]. At first it may [read or prepare]; [action] waits for [role].
Check the software you already have first
Your current software may already handle this step with a native rule or approval. BestAI checks that before proposing a connector or custom tool.
Completing these prompts only identifies one workflow to map; it does not show that the workflow is safe, feasible, compatible or pilot-ready, and it is not an implementation specification. BestAI may still recommend a native feature, a narrower scope or no pilot.
Not a Chatbot
A role, not a chat window.
The word AI covers a lot of very different things. Here is where a digital employee sits, and why it is the one that actually takes work off your plate.
General AI
Useful for ad hoc work
General AI chat is useful for questions, drafts, and one-off analysis. A person still brings the context, starts each task, checks the output, and decides what happens next.
AI Receptionist
A front desk for your customers
Answers enquiries, qualifies the lead, books the call. It faces outward, toward the people contacting you. Useful, but it is not doing the work behind the counter.
Digital Employee
A colleague on the inside
It follows one agreed internal workflow from trigger to confirmed result. It proceeds only inside the written permissions, pauses or stops on agreed exceptions, and hands important decisions or unresolved cases to named people. The agreed critical steps and confirmed outcomes are recorded.
Execution Tool vs Workflow SystemMap my first workflow
Codex can be the engine. The workflow is the business system around it.
Codex, Claude Code, or a custom agent can read authorised information, use connected tools, and carry out defined steps. They are capable execution agents, not simple chat windows.
BestAI defines the operating layers around the agent according to the written scope: trusted records, instructions, rules and exceptions, existing-system access, any connector needed for the verified handoff, permissions, approvals, triggers, agreed action records, and support boundaries. Native capabilities come first; a connector or small tool is added only when the gap and access are verified.
If your team already owns those layers, you may not need us. If not, BestAI can scope, test, and deliver the agreed implementation layers. Live use and any ongoing support remain separate written decisions with named responsibilities.
Execution agent
Codex, Claude Code, or a custom agent
Reads authorised inputs and carries out the steps defined for the job.
BestAI workflow implementation
The business system that tells the agent how to do the job
Agreed records, instructions, and business rules
Existing-system access and any verified connection
Scoped permissions and named human decisions
Triggers, agreed action records, and support boundaries
Run it manually, on a schedule, or from a business event. Send exceptions back to a person.
How We Build Yours
Map one workflow, test it, then decide what goes live
One bounded workflow is defined first. If it is suitable for a pilot, testing follows the agreed written scope. Any live use is decided separately in writing.
01
Discovery
We sit down with you and the person who does the job today. We learn how the work really flows, not how a manual says it should.
02
Define the first path
We agree where it starts, what “done” means, which records to trust, when it must pause or stop, and who decides exceptions. The written scope covers only this first path.
03
Test on approved data
If the workflow is suitable for a pilot, we agree the connection method and test data. We then check the expected result, approval and stop rules, and what happens when a result is missing, partial, or uncertain.
04
Make a separate live-use decision
Completing a pilot does not put the workflow into live use or expand its permissions. Before live use, both sides agree in writing on the scope, permissions, named owners, support boundary, and how changes are approved. High-impact decisions stay with people.
System decision guide
Keep it, connect it, extend it, or replace it?
Start with one representative workflow and the system that owns each trusted record. Choose the smallest safe change that fixes the real break.
Smallest safe change
Check in this order, system by system. One workflow may use more than one path after native features, access, approvals, writeback, and recovery are verified.
1. Keep2. Connect3. Extend4. Replace
- 01 / Keep
Use native capability
Leave a working system in place
Keep the system when it already owns the trusted record and its built-in rules, permissions, and approvals can complete this part of the job.
- Is this the record your team treats as final?
- Does the real problem happen before or after this system?
Practical next step: Configure and document the native workflow. Do not add a connector where none is needed.
- 02 / Connect
Repair the hand-off
Bridge systems that each do their job
Keep the source systems, then bridge the broken hand-off. BestAI maps the agreed fields and builds or configures a workflow-specific API connector.
- Are people copying or reconciling the same record between tools?
- Can we name what moves, when it moves, and who approves an update?
Practical next step: Test reading, writeback, duplicate handling, and a safe fallback before live use.
- 03 / Extend
Add one missing layer
Fill a narrow operational gap
Add a lightweight tool when the core system remains right but staff lack an exception queue, approval view, capture form, or morning brief.
- Does the existing system still hold the right core records?
- Can a small tool fill the gap without creating a second source of truth?
Practical next step: Keep the original record IDs and write the final status back only after access and safe updates are verified.
- 04 / Replace
Require evidence first
Move only when the core system fails the job
Consider migration only after a representative workflow shows that core records, permissions, or daily work cannot run reliably and no acceptable connection, export, or recovery path exists.
- Is the core system the problem, rather than the hand-off?
- Does the improvement justify migration, retraining, and rebuilt connections?
Practical next step: Treat replacement as a separate migration with permissions, rollback, and user acceptance checks.
These prompts scope the next check. They are not a compatibility verdict. We do not promise a connector until data access and safe updates have been verified. Replacing a system is not the default.
Governance & Control
Clear owners, permissions, and pause controls
Before live use, the written operating agreement names the accounts in scope, who grants and changes access, who can pause future actions, which decisions stay with people, and where support begins and ends.
Permissions match the agreed scope
Read and action permissions are set for the bounded test or live path in writing. Nothing is added because a pilot finishes; changes follow the named approval process.
Human in the loop
During the pilot, anything sent, spent, or written to a key record waits for your yes. You decide which tested, low-risk actions may later run inside agreed limits.
Critical actions stay traceable
The cross-system action record covers the agreed critical steps and confirmed outcomes. A connected tool may also provide its own activity history. Availability and coverage can vary by product, action, configuration, and subscription.
Agreed access, your business data
The workflow uses only the accounts, systems, and access agreed in writing. Your business data remains yours. The operating plan names who can pause future runs and how access is removed; pausing does not undo actions another system has already accepted.
Approval boundaries
What may run, what must wait, and what stops.
Approval follows the impact of an action. During workflow mapping, we agree the exact limits, the evidence a person sees, and who owns each decision.
May run inside agreed limits
Read allowlisted fields, compare records, classify, summarise, and prepare drafts. After testing, a narrow and reversible routine update may run only when every agreed check passes.
Examples: read stock, prepare a draft, create an internal exception task.
Must wait for a named person
During the pilot, anything sent, spent, or written to a key record waits. New payees, bank details, access changes, sensitive disclosures, material promises, regulated decisions, and destructive changes remain human decisions.
Examples: send a customer message, approve spend, change a key CRM record.
Stop and escalate
The workflow does not guess when sources disagree, required data is missing, an amount or party is outside policy, confidence is below the agreed threshold, or no approved rule covers the situation.
Examples: conflicting payment states, a new supplier, an unmatched customer.
What the approver sees
A decision arrives with the evidence needed to make it.
The approval request shows the proposed action, amount or recipient, affected fields, source evidence, rule, record version, and whether the action can be undone.
- Named approver and exact action
- Source records and rule that triggered it
- Before and proposed values
- Expiry or safe fallback if nobody decides
- Decision, time, person, and note recorded
- Fresh approval if the source record changes
Human approval is a control, not a guarantee. We also test permissions, data quality, failure handling, and the writeback before a workflow goes live.
BestAI review after mapping
What we confirm before recommending a pilot
Choosing a workflow to map does not decide whether a pilot is appropriate. After mapping, these four practical checks produce BestAI's go, narrow, or stop recommendation.
01
What starts the work and what counts as done
The trigger, owner, frequency, successful result, and the condition that should stop the workflow.
02
Which system holds the trusted record
What may be read, what may be changed, and whether the system's own features already solve this part of the job.
03
Where a person must approve or take over
The important decisions, representative exceptions, named approver, and person responsible when the workflow stops.
04
How the workflow will be tested and recovered
Suitable sample records, expected results, failure visibility, pause rules, and who confirms recovery before work resumes.
Possible next step
Suitable for a pilot
The workflow is narrow enough to test, the relevant records and access path are available, and approval and recovery owners are known.
Narrow or clarify first
Important rules, records, ownership, or test examples still need to be resolved before a safe pilot can be scoped.
A pilot is not the right next step yet
Safe access is unavailable, no accountable owner exists, the risk is too high, or the existing system can handle the job more simply.
BestAI may recommend a smaller first step or configuration inside the existing system instead.
A fit decision, not a compatibility promise
This step helps decide the safest next move. It does not guarantee a connector, live-system access, or a paid pilot. If a pilot is suitable, BestAI confirms the agreed scope, access, approvals, and test plan before paid work begins.
From pilot to live
A pilot goes live only with an operating plan.
Before ongoing service starts, both sides agree what evidence releases the workflow, who owns each decision, how health is judged, and what stops the next action.
01
Confirm the release gate
Approved examples reach the expected result in the trusted system. Approval stops, failed-write handling, and final readback work as agreed, and the named business owner confirms the evidence.
02
Open one bounded path
The live trigger, records, volume, permissions, actions, and approval points are written down. Broader access or autonomy is not inherited from a successful test.
03
Name who acts
Your business owner decides exceptions and consequential actions. BestAI's technical contact investigates run and connector evidence inside the agreed support scope.
04
Retest every change
A changed connector, rule, schedule, model, prompt, or configuration is treated as a new release: test it on approved examples, approve it, then confirm the agreed outcome before broader release.
Live operating states
Health means the business result, not just a completed run.
These state definitions are agreed before go-live. They are not a live dashboard or a performance claim.
Healthy
The expected run happens and the trusted-system result or readback matches the agreed outcome.
Needs review
The trigger or run completed, but the business result is late, partial, missing, or uncertain.
Paused
Access, source evidence, rule coverage, or a health check is missing or conflicting, so the affected actions do not continue.
Support coverage is agreed, not assumed
The alert route, review frequency, response target, support hours, and resume authority are confirmed in the chosen scope. This page does not promise 24/7 monitoring or unlimited changes.
Pausing and undoing are different
Pausing stops new automated work in the affected path. If an earlier configuration can be restored, it changes future runs; it does not unsend a message, reverse money already spent, or undo a record another system has accepted. Those actions need the agreed reconciliation, correction, or compensating step and a named owner.
Pricing
Start with one scoped pilot.
Confirm fit, access, controls, and the written scope before payment. Any ongoing service is a separate written decision after the pilot evidence is reviewed.
Paid Pilot
One scoped workflow, written down before payment.
We first confirm the workflow, source systems, available access, approval boundary, and safe writeback or hand-off. The written scope sets the test path, evidence, timing, prerequisites, external-cost handling, and exclusions. Only then does the NZ$999 paid pilot test the agreed workflow on approved data.
- One agreed workflow
- Connection method verified before start
- Approval boundaries and action log
- Written scope before payment
One-time
NZ$999
Map this pilot firstNo payment on this form. We send the paid-pilot link after fit, scope, and access are confirmed.
Written scope before payment
Know what the NZ$999 pilot is testing before you pay.
The written pilot scope is the boundary. It turns one workflow into a specific test with named records, controls, evidence, owners, and exclusions.
No public buy-now checkout
01
Before payment
Agree the workflow and test boundary
We name the trigger, trusted records, available access, connection method, approved test data, approval and stop rules, expected result, and the people who own exceptions.
02
During the pilot
Test one agreed path on approved data
We check the expected business result in the trusted system and keep evidence for the approvals, stops, failed or uncertain writes, and recovery steps included in scope.
03
Written, not assumed
State the commercial and delivery edges
The scope states timing, customer prerequisites, how third-party or API costs are handled, any connector or lightweight tool included, and what sits outside the pilot.
04
After the pilot
Make a separate live-service decision
A pilot does not automatically become production or a monthly service. Live scope, owners, support, change process, price, and start date are confirmed before ongoing work begins.
Do not assume the pilot includes: Production go-live, data migration or cleanup, extra workflows or systems, and ongoing support all require an explicit written decision.
After the pilot
Ongoing service is a separate decision, not a pre-set tier.
We first review the agreed test evidence, stop and approval rules, recovery, access, and both sides' responsibilities. If both sides choose to continue, a new written scope confirms one bounded live path, named owners, permissions, support boundary, change process, price, and start date. There is no automatic monthly commitment.
Map one workflow firstFAQ
Digital Employee, Answered
What is a digital employee, exactly?
A digital employee is an AI agent set inside a controlled workflow for one specific internal job, such as purchasing, order dispatch, or a daily operations brief. It watches for the agreed trigger and follows the tested path. It may complete permitted steps, pause for a named person, stop on missing or conflicting evidence, or hand an unresolved exception back to its owner. What it can read or do is set in the written scope.
If I already pay for Codex or Claude Code, do I still need BestAI?
Codex and Claude Code are capable execution agents. They can read files, change software, run commands, and use authorised tools. A subscription does not automatically map your real process, identify the trusted records, choose and verify the connection method, encode exceptions, set approval boundaries, test recovery, or define the live-use and support boundaries. If your team can own those decisions and the implementation, you may not need us. If not, BestAI can map, connect, and test the agreed workflow around the agent that fits the job. Live use and any ongoing support are separate written decisions.
What does the NZ$999 pilot include?
Before the paid pilot starts, we map one workflow and confirm the trusted records, available access, connection method, approval and stop rules, expected result, and recovery owners. The written scope also states timing, customer prerequisites, how external costs are handled, and what is outside the pilot. The NZ$999 pilot then tests that agreed workflow on approved data with its controls in place.
Do I need to replace my CRM or ERP?
Not by default. We first map one representative workflow and identify which system owns each trusted record. If the system's native rules, permissions, and approvals cover the job, we configure what is already there. If the break is between systems, we verify access and build or configure a workflow-specific API connector. A lightweight tool may fill a narrow operational gap. We only recommend assessing replacement when the core system cannot support the records, controls, or daily work and no acceptable connection, export, or recovery path exists.
Which actions must a person approve?
During the pilot, anything sent, spent, or written to a key record waits for a named person. New payees or bank details, access changes, sensitive disclosures, material customer promises, regulated decisions, and destructive changes remain human decisions. The workflow also stops when records conflict, required data is missing, confidence is below the agreed threshold, or no approved rule covers the situation.
What happens after the pilot?
A pilot does not automatically become a monthly service. We review the agreed test evidence: the expected result in the trusted system, approval and stop rules, and how failures were recovered. If both sides choose to continue, the live scope, owners, support boundary, change process, price, and start date are confirmed before monthly service begins. If you do not continue, there is no monthly commitment, and we agree how pilot-only access and test records are closed out.
Do I own it, or am I locked in?
It runs in the accounts and systems agreed for your workflow, and your business data remains yours. Where practical, we keep business instructions and connection logic separate from the execution agent to reduce unnecessary lock-in. Moving from Codex to Claude Code, or to another agent, may still require connector and workflow updates. We scope those changes with you before any move.
Public source
One public workflow review, shown with its limits
A short excerpt from BestAI's public Google Business Profile, kept separate from the product and process descriptions on this page.
Google Business Profile
Google display name
chanyuan
Original English. Excerpt.
chanyuan rated BestAI 5 out of 5 stars.
“They helped me build a personalised AI workflow tailored to my daily work…”
This public review is separate from the synthetic example workflows on this site. It is one review excerpt, not a case study, and it does not promise the same result for another business.
View the public Google sourceGive one job to a digital employee.
Bring one workflow candidate to map. We will map the records, access, exceptions, approvals, and safest system path before we recommend a paid pilot.
The public checkout stays closed until fit, scope, access, and controls are confirmed.