SCOPE / ONE USEFUL RESULT
Choose a task with a clear finish line.
A useful first brief might be: "After a support call, prepare a summary and a draft follow-up task for our coordinator to approve." It names an input, an output and a reviewer. "Add AI to our business" leaves all three undecided.
Record how often the task happens, how long staff spend on it and which mistakes require rework. Agree on the examples a successful pilot must handle. Keep a sample aside for testing so a convincing demonstration does not become the only acceptance test.
Use ordinary code for fixed calculations, thresholds and permission checks. AI can help interpret a conversation or draft a summary. Anthropic's guidance on workflows and agents recommends starting with the simplest approach that fits the task; a predictable sequence may be enough.
OUR PRODUCT / NITRODIAL
Plan the work around the conversation.
We built NitroDial with configurable AI voice agents, campaign start and pause controls, live transcripts and prepaid credit accounting. Operators can follow calls and review recordings. Credit guardrails pause campaign work when the available balance becomes too low.
The product separates real-time voice work from campaign progression. That distinction matters when you scope a voice workflow: a conversation ending, a campaign stopping and a usage record being settled are different events. Each needs a defined outcome if a connection fails.
A proposed first integration could turn a completed call transcript into a draft CRM task. The scope would include matching the right record, showing the source transcript and asking a coordinator to approve the task before saving it. This CRM follow-up is an illustrative extension, not a published NitroDial feature.
What the product demonstrates
Voice processing, operator controls and usage accounting belong in the same delivery plan. A voice demo alone does not cover the campaign workflow.
What your proposal must settle
Name the events your phone provider exposes, the records the integration may update and the person who handles an incomplete call or disputed result.
OUR PRODUCT / ASYNC EMS
Separate observing a system from changing it.
Our Async EMS monitors optical network equipment through SNMP. Scheduled polling and threshold checks produce device status and alerts. Operators investigate through site and topology views; configuration changes require administrative access and leave an audit record.
EMS is an operations and monitoring product, not an AI agent case study. Its relevance here is the boundary between reading equipment state and changing equipment settings. An AI addition would need to respect that same boundary.
For example, a proposed assistant could draft an incident summary from selected alerts and an approved runbook. It would show the source readings and their timestamps, then pass the draft to an operator. Polling and threshold checks would remain rule-based. We are not claiming that EMS already includes this assistant or autonomous fault remediation.
DISCOVERY / ACCESS AND DATA
Inspect the integration before pricing the build.
A software logo on a proposal does not tell you what the integration can do. Ask the supplier to inspect the available API or export, confirm access with your system owner and name the limits. Budget for that discovery if the access is uncertain.
| Requirement | What to confirm | Why it changes scope |
|---|---|---|
| Input and trigger | The event that starts work, its record identifier and how late, repeated or missing events appear. | A repeated event must not create a second task or charge. Missing events need a recovery path. |
| API and test access | Supported reads and writes, rate limits, a test account and who can approve access. | A read-only export and a write-enabled API require different delivery plans. |
| Data and permissions | Approved fields, who may see each record, retention settings and which provider receives the data. | Removing private fields and preserving access rules can require work before a model call. |
| Failure and ownership | Timeout handling, a retry limit, a review queue and the person responsible for failed work. | A stalled integration needs a visible owner and recovery steps after handover. |
CONTROL / APPROVAL AND RECOVERY
Make approval a step the software enforces.
Show a reviewer the proposed change beside its evidence. Store the approved version and check authorization again when applying it. If the underlying record changes before approval, send the proposal back for review instead of applying a stale decision.
Limit the tools and permissions the model can use. Require human approval for consequential actions, and enforce those permissions in the receiving system. These controls follow OWASP's guidance on excessive agency. A prompt that asks an agent to be careful is not an access-control check.
- Show which input and source records support a draft; route missing or conflicting evidence to the review queue.
- Define an expiry for approval, a rejection path and a stop control that the workflow owner can use.
- Test duplicate events, permission failures, provider outages and misleading instructions inside incoming documents.
- Record the proposed action, reviewer, approved change and execution result without putting passwords or unnecessary private data into logs.
DELIVERY / TEST BEFORE EXPANDING
Agree on acceptance tests and a handover.
Start with approved sample inputs, then run the workflow in a mode that prepares drafts without making live changes. Your team can compare those drafts with the current process and identify the cases that need manual handling.
Measure the share of usable drafts, corrections per task and total handling time, including review. Agree on acceptable limits before the pilot. A fast generated answer is of little use if a person spends longer correcting it than completing the original task.
Pilot acceptance
Keep the agreed test cases and their results. Include difficult inputs, recovery after a timeout and a check that an unauthorized user cannot approve an action.
Production handover
Document account ownership, spending limits, monitoring, recovery steps and who maintains prompts and integrations. Agree which changes require another test run.
BUDGET / BUILD AND OPERATION
Price the workflow and its ongoing use.
Ask for an implementation estimate covering discovery, data preparation, integrations, the review interface, evaluation and deployment. A summary-only pilot has a different scope from a system that writes across several business tools. Specify exclusions, acceptance tests and the support arrangement alongside the total.
Operating costs depend on workload. Voice can involve call minutes, speech processing, model use and recording storage. Document workflows may add extraction or retrieval costs. Both also need hosting, monitoring and time from the people who review exceptions.
For a hypothetical workload of 1,000 tasks per month, two model calls per task would mean 2,000 calls before retries. If each task takes one minute of staff review, allow about 16.7 review hours. These are planning assumptions, not NitroDial or EMS usage figures, an Async quote or a savings forecast. Model charges still depend on the chosen provider's current billing units and the amount of input and output.
- Separate the one-time build from monthly provider usage, infrastructure and support. Confirm the invoice currency and taxes in the proposal.
- Estimate normal and peak workload, then specify retry limits and a spending cap. Include staff review in the business case.
- Compare the pilot with the original task's handling time and error rate before assuming a financial return.
NEXT STEP / YOUR FIRST WORKFLOW
Bring a workflow we can scope.
Send a short description of the task through our project enquiry form. An anonymized example helps us understand the input and the result your team needs. Do not send passwords, private call recordings or customer records through the form.
- Describe who does the task now, its frequency and the point where delays or errors occur.
- Name the source systems and the system that should receive the result. Note any confirmed API or export access.
- List the actions that must remain under human approval and who can review pilot results.
- State your budget constraints, review hours and any data-handling requirements your team has already identified.