Ask every automation candidate the same 25 questions and score each answer from 0 to 3. Require documents or live evidence for discovery, authority, integration confirmation, failure handling, testing, credential security, ownership, export, support, change control, and project acceptance. Confidence without evidence receives no credit.
Interview for operating judgment—not software vocabulary
An AI automation builder can sound impressive while describing models, APIs, agents, webhooks, databases, and integrations. Those capabilities matter, but a small business should interview for a more important skill: can the builder turn an ambiguous business process into a reliable operating system without inventing rules, hiding dependencies, or trapping the owner?
The strongest answers will be specific about discovery, scope, data, authority, testing, failures, security, ownership, support, and measurement. Weak answers rely on “the AI will learn,” “we can automate anything,” or “the platform handles that.” This 25-question interview is designed to expose the difference before the deposit is paid.
Direct answer
Ask every Fayetteville AI automation candidate the same 25 questions and require examples, documents, or live demonstrations. Score the answer, not confidence. A provider that identifies limits, narrows scope, and explains failure behavior is usually safer than one that promises a fully automatic business.
Questions 1–5: discovery and problem definition
| # | Question | Strong answer indicators | Warning sign |
|---|---|---|---|
| 1 | How will you learn our current process? | Interviews, observation, recent records, workflow reconstruction, exception review, and employee validation. | A short onboarding form is the entire discovery. |
| 2 | How do you choose the first workflow? | Volume, rule clarity, data readiness, recoverability, customer value, risk, and measurability. | Chooses the provider’s favorite product. |
| 3 | What baseline do you require? | Raw counts for volume, delay, completeness, error, outcome, labor, and current cost. | Promises ROI without current performance. |
| 4 | How do you handle employees who do the process differently? | Document variations, identify why, settle policy, and keep valid exception paths. | Automate one employee’s version without review. |
| 5 | When would you tell us not to automate? | Unclear rules, bad data, low volume, high irreversible risk, no owner, or no measurable benefit. | Claims every process should be automated. |
Questions 6–10: scope, knowledge, and authority
| # | Question | Strong answer indicators | Warning sign |
|---|---|---|---|
| 6 | What will be explicitly included and excluded? | Named channels, users, customer groups, actions, integrations, limits, and deliverables. | “Complete AI solution” with no boundaries. |
| 7 | Which sources may the AI use? | Approved source register, hierarchy, versioning, update owner, and conflict resolution. | Scrapes whatever it can find. |
| 8 | What may the system do automatically? | Action-by-action authority matrix based on risk and verified conditions. | One broad permission for the whole assistant. |
| 9 | What always requires human approval? | Variable, financial, safety, regulated, exceptional, or irreversible decisions are named. | “The AI will know when to ask.” |
| 10 | How does it answer an unsupported question? | States the limitation, preserves useful context, and creates the correct handoff. | Guesses or gives a generic answer. |
Request a written scope before accepting a quote. The Fayetteville AI project-scope workbook provides a structure for triggers, inputs, actions, approvals, failures, ownership, tests, and acceptance.
Questions 11–15: data and integration design
| # | Question | Strong answer indicators | Warning sign |
|---|---|---|---|
| 11 | Where will the customer or workflow record live? | One authoritative system, consistent IDs, action states, ownership, and export. | Separate unlinked records for every channel. |
| 12 | How do you handle duplicate or conflicting records? | Identity rules, no silent merge, evidence review, and correction history. | Last write always wins. |
| 13 | How do you know an external action succeeded? | Destination IDs, delivery receipts, status events, or verified reads. | Automation step says “success.” |
| 14 | How do retries avoid duplicate actions? | Idempotency key, destination lookup, unique request ID, and controlled retry policy. | Simply runs the workflow again. |
| 15 | What happens when a vendor or integration is down? | Pending state, honest customer language, exception queue, alert, and manual fallback. | The workflow waits silently or reports completion. |
Questions 16–20: testing, security, and ownership
| # | Question | Strong answer indicators | Warning sign |
|---|---|---|---|
| 16 | What test cases will you run? | Normal, combined, corrected, incomplete, boundary, failed, handoff, recovery, and abuse cases. | A few scripted happy paths. |
| 17 | Who can change production instructions? | Role-based access, approval, version history, test-before-release, and rollback. | Anyone can edit prompts live. |
| 18 | How are credentials and sensitive data handled? | Server-side secrets, least privilege, separate accounts, retention limits, logging, and rotation. | Keys stored in public frontend code or shared personal accounts. |
| 19 | What does the business own? | Domain, phone number, customer data, core accounts, exports, business knowledge, analytics, and agreed work product. | Ownership will be discussed at cancellation. |
| 20 | Show us how we leave. | Export demonstration, credential transfer, number/domain control, documentation, retention/deletion, and timeline. | “You will never need to leave.” |
Ownership should be visible before launch. Use the business AI ownership register to record account owner, administrators, recovery, billing, export, and offboarding for every layer.
Questions 21–25: support, change control, and results
| # | Question | Strong answer indicators | Warning sign |
|---|---|---|---|
| 21 | Who monitors the system after launch? | Named business owner and provider role, review cadence, incident thresholds, and reports. | Nobody unless the customer complains. |
| 22 | What is included in support? | Response windows, channels, severity, fixes, knowledge updates, usage review, and excluded work. | “Unlimited” with no definition. |
| 23 | How are changes approved and tested? | Change request, impact review, version, regression tests, approval, deployment, and monitoring. | Edits are made directly after a text message. |
| 24 | How do you measure business value? | Baseline, operational metric, customer outcome, cost, known limitations, and attribution caution. | Conversations, tokens, or impressions alone. |
| 25 | What evidence defines project acceptance? | Passed tests, live destination evidence, ownership packet, documentation, training, rollback, and agreed thresholds. | The demo runs or the site is deployed. |
Use a 75-point interview score
Score each answer from 0 to 3. Give 0 for no answer, 1 for vague intention, 2 for a specific process, and 3 for specific process plus evidence such as a sample document, live demonstration, test report, contract language, or prior artifact. The maximum score is 75.
| Score | Interpretation | Decision |
|---|---|---|
| 61–75 | Production-capable candidate | Proceed to reference, ownership, security, and paid pilot verification. |
| 46–60 | Potentially capable with gaps | Require written corrections before proposal acceptance. |
| 31–45 | Tool operator more than systems builder | Use only for a narrow low-risk task with strong internal oversight. |
| 0–30 | High implementation risk | Do not place customer-facing or transaction work with this candidate. |
Some failures are automatic disqualifiers regardless of score: exposed credentials, false claims of completed actions, refusal to state ownership, no export path, no human escalation for high-risk cases, or no process for integration failure.
Require a live 45-minute micro-workshop
After the interview, give the strongest candidates one real but limited workflow. Do not ask them to build it for free. Ask them to map it. Provide three recent examples: one normal, one incomplete, and one exception. Watch how they ask questions and structure the problem.
Ten minutes: reconstruct the current path
The candidate should identify trigger, customer, required facts, systems, owners, and current failure.
Ten minutes: define the automation boundary
The candidate should separate retrieval, preparation, recommendation, automatic action, and human-only decisions.
Ten minutes: design failure behavior
The candidate should explain missing information, connection failure, duplicate prevention, customer language, and employee escalation.
Ten minutes: define proof
The candidate should name test cases, destination evidence, business metric, and acceptance standard.
Five minutes: expose unknowns
The candidate should list unresolved policy, data, account, or integration questions rather than pretending certainty.
The workshop reveals systems thinking more clearly than a prepared sales presentation. A strong builder leaves the business with a clearer process even before a technical solution is selected.
Compare the proposal to the interview
Providers sometimes give excellent verbal answers and then send a generic proposal. Verify that the document includes the discovery findings, exact workflow, exclusions, authority, data ownership, integrations, failure behavior, test plan, support, costs, milestones, and acceptance criteria discussed. Anything missing is not part of the deal unless added in writing.
The payment schedule should follow evidence: approved scope, prototype, integration proof, passed acceptance tests, ownership transfer or account verification, documentation, training, and controlled production validation. Avoid paying the full amount because a user interface exists.
Hypothetical comparison of three candidates
| Candidate | Interview score | Strength | Risk | Decision |
|---|---|---|---|---|
| Local managed provider | 66/75 | Strong discovery, handoffs, ownership, and support. | Higher quoted monthly cost. | Move to a paid narrow pilot and verify total cost. |
| National platform reseller | 48/75 | Fast setup and many standard integrations. | Business must own most configuration and exception review. | Use only if an internal operator is assigned. |
| Independent developer | 57/75 | Excellent custom integration and testing. | Maintenance and continuity are not included. | Proceed only with documentation, source access, and support agreement. |
These scores are hypothetical and are not ratings of any actual Fayetteville company. The example shows why the best choice depends on both capability and operating model.
The final hiring standard
Hire the builder who can explain what the system will do on its worst ordinary day: incomplete customer details, a full calendar, a confused employee, a changed policy, a failed message, a duplicate record, or a request outside the approved boundary. The provider should not fear those questions. Those are the questions that create a reliable business system.
Use the interview with Fayetteville Artificial Intelligence’s local automation team and every competing candidate. To put one real workflow through the 25-question standard, request an automation-builder interview session.
Frequently asked questions
Should I ask a provider to build a free prototype?
No. A paid discovery or micro-workshop is fair. The goal before hiring is to evaluate how the provider maps the workflow, exposes risk, and defines proof—not obtain unpaid production work.
What score is acceptable?
A score above 60 out of 75 can justify deeper verification and a paid pilot when no automatic disqualifier exists. Scores do not replace references, contracts, security review, or live tests.
What is an automatic disqualifier?
Exposed credentials, false completed-action claims, no ownership answer, no export path, no human escalation for high-risk cases, or no plan for integration failure should stop the process.
Should the proposal repeat the interview answers?
Yes. Scope, exclusions, authority, ownership, testing, support, costs, and acceptance discussed verbally should appear in the written proposal or contract.
Can a platform reseller pass this interview?
Yes, when it clearly explains the platform limits, business responsibilities, data ownership, testing, support, third-party costs, and what happens outside the supported features.
Interview the builder on the failures customers will actually create.
Fayetteville Artificial Intelligence can walk through the same 25 questions, map one real workflow, and show how scope, ownership, testing, support, and acceptance would work before a production commitment.
Editorial standard: practical, business-specific, customer-facing, and honest about limitations. Examples are illustrative unless explicitly identified as measured business data. Updated when technology, local operating conditions, or implementation standards materially change.