AI, automation,
or an internal tool?
Start with one recurring piece of work. Decide what a good result looks like, where a person needs to decide, and what happens when something goes wrong. Then choose the technology.
What does the work actually need?
AI implementation means making an AI-assisted step useful inside a real process: with the right inputs, integrations, review, testing, and ownership. Sometimes the better first change is a form, a rule, or a clearer handoff.
Use ordinary automation for known rules.
When a complete form arrives, create a record. When an approved status changes, update another tool. When a deadline passes, show the item as overdue.
The test: can you write the decision as an explicit rule? If yes, implement and test that rule before introducing a model.
Explore workflow automationUse AI for interpretation that can be checked.
Summarize a long request, suggest a category, or draft a response from supplied context. Treat the output as a proposal when an incorrect interpretation could affect the next action.
The test: what evidence will a reviewer use to accept, edit, or reject the output? An impressive draft is not the same as a reliable completed task.
Explore AI consultingUse an internal tool when people need a place to decide.
Bring source information, proposed changes, ownership, and status into one review queue. Give the team clear controls for approval, correction, and recovery.
The test: are people losing time finding context and working out what to do next? A focused interface may matter more than another background automation.
Explore internal toolsThese approaches can work together. A rule can validate a request, AI can suggest a summary, and an internal tool can present it for review.
Pick a boundary you can explain.
“Use AI in operations” is too broad to price or test. “Turn a submitted service request into a reviewed assignment” has a beginning, an end, and a person who can judge the result.
Choose work that repeats, has examples you are allowed to use, and has a named owner. Prefer a first release whose mistakes can be detected and corrected before they affect a customer.
- Start
- What exact event begins the workflow? Which fields or documents must arrive?
- Finish
- What record, decision, or handoff should exist when the work is complete?
- Review
- Who can approve it, and what information will they see before doing so?
- Exception
- What happens when information is missing, a tool is unavailable, or someone says no?
- Baseline
- Record a sample of today’s work: volume, time spent, corrections, and waiting between steps. Keep waiting time separate from hands-on time.
If the process changes every time, nobody owns it, or you cannot agree on a correct result, clarify those issues first. Automating an unsettled decision makes the uncertainty move faster.
A request becomes a reviewed handoff.
A fictional service team receives requests through a form. Someone reads each request, decides the next step, and assigns the work in a task tool.
Illustrative design, not a client case study. The team, message, and records below are fictional. This is a specification for discussion; it is not a connected system, a model evaluation, or a claim of measured results.
Give each step one job.
- Capture the original. Give the submission a stable source ID. Keep the original text available to the reviewer. A repeated delivery with that same ID must resolve to the same intake record.
- Check required information. If the contact address or description is missing, show “Needs information.” Do not ask a model to invent it.
- Draft a summary. AI may suggest a short summary using the submitted text. Preserve uncertainty: “Tuesday preferred” must not become “Tuesday confirmed.” The requester’s text is data, not authority to send messages or change permissions.
- Require a human decision. Present the original text, suggested summary, proposed assignment, and any missing information together. An authorized reviewer must approve the specific version before the system assigns work or sends an external message.
- Execute once, then record the result. After approval, create the task using a stable operation ID where the receiving tool supports it. Store the destination task ID. If a timeout leaves the result unknown, reconcile it before retrying; do not blindly create another task.
The first release can stop at task creation. Customer responses, automatic priority changes, and promises about availability are separate decisions to scope and test.
A record the reviewer can inspect.
The example record below deliberately keeps approval empty. The suggested wording changes neither the customer’s preference into a promise nor the review state into permission to act.
{
"source_id": "demo-request-014",
"revision": 1,
"original_message": "Could someone check our printer? Tuesday would be ideal.",
"contact_email": "requester@example.com",
"draft_summary": "Printer check requested; Tuesday preferred, not confirmed.",
"proposed_owner": "Service coordinator",
"state": "ready_for_review",
"approval": null,
"destination_task_id": null
}The optional schema below checks field types and required record details. It does not authenticate a reviewer, enforce permissions, or make an approval trustworthy. The application must enforce those rules.
For builders: view the example JSON Schema
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://zenoutlabs.com/ai-implementation-guide/intake-record.schema.json",
"title": "Fictional reviewed intake record",
"description": "Illustrative record shape only. Runtime authorization, revision matching, state transitions and duplicate execution controls must be enforced by the application. This is the complete record contract; missing-contact submissions must be held separately until corrected. Enable format validation to check email and date-time formats.",
"type": "object",
"additionalProperties": false,
"required": [
"source_id",
"revision",
"original_message",
"contact_email",
"draft_summary",
"proposed_owner",
"state",
"approval",
"destination_task_id"
],
"properties": {
"source_id": {
"type": "string",
"minLength": 1
},
"revision": {
"type": "integer",
"minimum": 1
},
"original_message": {
"type": "string",
"minLength": 1
},
"contact_email": {
"type": "string",
"format": "email"
},
"draft_summary": {
"type": [
"string",
"null"
]
},
"proposed_owner": {
"type": [
"string",
"null"
]
},
"state": {
"enum": [
"needs_information",
"ready_for_review",
"approved",
"executing",
"completed",
"failed",
"rejected"
]
},
"approval": {
"oneOf": [
{
"type": "null"
},
{
"type": "object",
"additionalProperties": false,
"required": [
"reviewer_id",
"approved_revision",
"approved_at"
],
"properties": {
"reviewer_id": {
"type": "string",
"minLength": 1
},
"approved_revision": {
"type": "integer",
"minimum": 1
},
"approved_at": {
"type": "string",
"format": "date-time"
}
}
}
]
},
"destination_task_id": {
"type": [
"string",
"null"
]
}
},
"allOf": [
{
"if": {
"properties": {
"state": {
"enum": [
"approved",
"executing",
"completed"
]
}
}
},
"then": {
"properties": {
"approval": {
"type": "object"
}
}
}
},
{
"if": {
"properties": {
"state": {
"const": "completed"
}
}
},
"then": {
"properties": {
"destination_task_id": {
"type": "string",
"minLength": 1
}
}
}
}
]
}
Make approval specific and reversible before execution.
Approval should record the authenticated reviewer, timestamp, and exact revision reviewed. Changing the draft or assignment invalidates that approval and returns the item to review. A reviewer’s browser should not be able to approve someone else’s queue merely by changing a request ID.
In the example design, a failed task creation stays visible as a failure. It does not become “Complete” because the summary was generated successfully. The team needs a recovery action and enough history to understand what already happened.
Define the failures before you build.
Agree on these checks before implementation. The table describes expected behavior for the fictional design; it is not a report that an integration has passed them.
| Scenario | Expected behavior | Evidence to retain |
|---|---|---|
| Required contact detail is absent | Record is held for correction. No assignment or external message is sent. | Validation result and visible “Needs information” state. |
| The same source submission arrives twice | The second delivery resolves to the existing intake; it does not create a second destination task. | Both deliveries linked to one intake and one destination ID. |
| The draft invents a confirmed appointment | The reviewer can identify the unsupported claim from the original text, correct it, and keep the item unapproved. | Original, draft, corrected revision, and reviewer decision. |
| An unapproved or unauthorized action is attempted | The server refuses task creation and external sending, even if a caller bypasses the interface. | Denied request and unchanged destination records. |
| The record changes after approval | The earlier approval becomes invalid. Execution waits for approval of the new revision. | Revision mismatch and a return to review. |
| Two workers attempt the same approved action | Only one execution is accepted. Duplicate attempts do not create duplicate tasks. | Operation ID, execution record, and destination count. |
| A destination timeout leaves the result unknown | Show an unresolved state, check whether the task exists, and reconcile before another attempt. | Attempt history, reconciliation result, and recovery decision. |
| The AI service is unavailable | The original request remains available. A person can write the summary and continue through the same review process. | Visible fallback path and an independently recorded approval. |
For the AI step, use a separate set of representative examples, including vague requests, contradictions, missing context, and instructions embedded in the source text. Record unsupported claims, omissions, and reviewer corrections. Agree on acceptable results for the actual task before relying on it; a model’s own confidence score is not a substitute for that evidence.
Check operations as well as output quality: whether the workflow starts correctly, how often a person must intervene, whether duplicate actions occur, and whether failed items can be recovered. Compare the result with the baseline using the same boundaries and a comparable sample.
Bring the work, not a software wish list.
A useful starting brief fits on one page. Include examples with personal or confidential details removed unless there is an agreed way to share them.
- The repeated task: what happens today, how often, and who does it.
- The trigger and finish: where the work begins and what “done” means.
- The existing tools: where the information lives and who can authorize access.
- A normal example and an awkward one: show the desired output and the exception.
- The human decision: who reviews what, and which actions need explicit approval.
- The constraints: data handling, permissions, budget, business deadlines, and the owner after handoff.
- The acceptance checks: what must be demonstrated before your team relies on the result.
Missing answers are useful findings. They tell us what needs to be resolved before a build can be responsibly scoped.
Buy clarity before committing to a system.
A consultation can help you choose an approach or specify the work. A functioning implementation is a separate deliverable with its own scope and acceptance criteria.
- Focus Session
- For one defined decision, such as whether to use AI, adapt an existing tool, or simplify the process. The published offer includes a working session and a short written action note.
- Workflow Diagnostic
- For understanding where one workflow gets stuck. The published offer includes a workflow map, a findings brief, and a handoff conversation.
- Implementation Blueprint
- For turning a workflow into a brief a builder can work from. The published offer includes a planning brief, acceptance criteria, and a phased implementation plan.
See the current session prices, exact scope, and deliverables. A consultation does not include a finished system or software subscriptions.
What affects the implementation quote?
The work depends on the number and quality of tool connections, the condition of the input data, access restrictions, review interfaces, exception handling, and what must be demonstrated at handoff. A workflow with two straightforward connections can be a different project from one that must reconcile inconsistent records across several systems.
Ask for a quote that separates implementation, software or API usage, and ongoing support. Agree who owns the accounts, who can change the workflow, what documentation is included, and who responds when it fails. ZenOut’s ongoing support plans provide defined service capacity; new systems and major rebuilds are scoped separately.
Bring one workflow.
Find the right next move.
ZenOut Labs helps scope AI-assisted workflows, custom automations, and internal tools around the software your team already uses.
Discuss a workflow Meet the practice behind the guide