"We have APIs" is a sentence that can start a customer-service AI project without settling any of it. An API proves that a system can be reached. It does not prove that the field the workflow needs is populated, that it is fresh enough for the question being asked, that it means what the agent assumes, that it is the authoritative version, that the customer asking is entitled to it, or that the action at the end of the workflow is allowed.
This guide gives you six tests for exactly those questions, applied to the kinds of workflows service teams automate first. It is the operational companion to the knowledge-governance guides already in this archive; where those explain which sources to trust, this one asks whether the connected data can carry a workflow from the customer's question to a finished outcome. If it cannot, the vendor you choose does not matter.
Where this comes from. The six tests come from five conversations Typewise held in 2026 with teams scoping AI for order, invoice and account workflows: a discovery conversation with a furniture retailer, a discovery conversation and a proof-of-concept kick-off with a wholesaler, a demo for a B2B software company, and an implementation workshop with a consumer-goods manufacturer's order desk. I was in two of them; colleagues ran the other three. The cases below are anonymised and marked as what those teams reported or planned; the tests and the checklist are our recommendation.
Test 1: completeness, for the cases that matter
A field being present in the schema is not the same as it being filled for the cases the workflow will meet.
Worked case: where is my order. The happy path is a shipped order with a tracking number and a delivery date. The cases that generate contacts are the others: an order with no delivery date because a supplier has not confirmed, a tracking number that exists but was never mapped into the service view, a carrier event that was received and discarded. Agents work around these gaps today by logging into carrier portals, which is exactly the step nobody mentions when the integration is described. The furniture retailer's service lead told me they had tracking numbers in the ERP and were pulling carrier events, but not all events were mapped, so whatever was unmapped was effectively thrown away and agents still logged into carrier portals, simply because nobody had needed that data before. His broader point was blunter: if they could not deliver the right information to the automation and provide endpoints that execute actions, it would not matter which vendor they connected. He already had rule-based automation covering a share of simple cases, which is a different thing from an AI deployment and belongs in the baseline.
Before automating, sample real tickets, not the data model, and count how often the needed field is empty, stale or wrong for that ticket type. If a quarter of "where is my order" contacts have no delivery date, the workflow needs a branch for that case, including who chases the supplier and how that chase is tracked, or it will hand off most of what it was meant to handle.
Test 2: freshness, set by the age of the question
Live connectivity is not always necessary; the right refresh cadence depends on what customers ask about.
Invoice and tracking questions usually concern events that are days or weeks old, so a daily refresh may serve most of them while a live connection is still being built. That is how the wholesaler's team sized it in the proof-of-concept kick-off a colleague ran: their IT contact judged a daily export enough because invoice and shipment questions concern events already days or weeks old; the agent hands off when it cannot find the record, and someone in IT owns the morning upload while the live connection is built. They also agreed that if handoffs became frequent, once a day was not enough. Stock questions for a large customer are different, because the answer can change within the hour. Decide the freshness requirement per intent, write down what the AI does when the data it finds is older than that threshold (typically: say so and hand off), and name who owns the manual refresh during any interim period. A refresh cadence chosen for a proof of concept is a compromise, not a production service level; revisit it before expanding.
Test 3: meaning, not just values
Two systems can both hold a field called "status" and disagree about what the values mean. The agent needs the semantics the service team uses, which are often undocumented.
Worked case: stock and delivery promises. "In stock" in the ERP does not mean a shipment can be promised tomorrow. Large-customer commitments depend on allocation and logistics decisions the ERP does not express. Shipment tracking, by contrast, needs only a linked document and a tracking number, and can be answered from the data as it stands. Both are "order data"; only one is ready for an autonomous answer. The wholesaler's back-office lead drew this line himself: for large customers he cannot look at a hundred items in stock and promise shipment tomorrow, because that needs agreement with disposition and logistics, mostly by phone; a shipment-tracking question, by contrast, needs only the delivery-note number and the tracking number behind it.
The practical fix is to base analytics, AI and operational integrations on one modelled view of the data, so a definition changes in one place. The same company's IT lead was already heading there: one semantic model of the ERP intended to serve reports, AI and integrations alike for reads, with writes treated as a separate question. That was his plan, not a measured result. Until something like it exists, document per field what the service team actually infers from it.
Test 4: authority, and where the relationship really lives
The system of record for the product is not always the system of record for the relationship.
Worked case: B2B orders. A distributor orders by sending a list of a hundred of its own product codes. The mapping from the customer's codes to your SKUs, and the customer-specific lead times, may live in a local spreadsheet maintained by the service team, not in the ERP. An agent connected only to the ERP will read everything correctly and still be unable to interpret the order. Similar product names and dozens of customer-specific forms make the local file the real authority. This is the manufacturer's order desk as the team described it to us in the workshop: distributors send long lists of their own references, the mapping from customer codes to the company's SKUs is held locally rather than in the ERP, and when a product reference changes, someone opens each customer-specific order form and updates it by hand.
Map the workflow first, then ask which system holds each piece it needs. Where the answer is "a spreadsheet", the readiness work is to give that data a home the agent can read, with an owner, before any integration is written. For the workflow side of this case, see AI for B2B order processing.
Test 5: identity, enforced where the data lives
Public help and authenticated account information need different data scopes, and the boundary has to be enforced by the system that serves the data.
If a visitor on the public site asks for the contract value of a named account, nothing in the agent's instructions should be the only thing preventing an answer. That was the founder's own concern in the software company's demo: someone opens the chat and asks for a named account's contract value. He wanted a logged-in session as a hard barrier before any account data is served. Our recommendation today goes a step beyond what that demo settled: a login authenticates the visitor, and authorisation, which records this visitor may see, has to be enforced by the system serving the data rather than by an instruction to the agent. The backend should refuse unless the session is authenticated, because the same backend can be called from outside the conversation. Instructions can tell the agent to require login; they cannot establish authorisation. Design the read scopes per workflow: what an anonymous visitor may see, what a logged-in customer may see about their own records, what nobody may see through the AI at all. Our permissions guide covers the execute side of the same boundary.
Test 6: permitted actions, and whether the remaining manual step is the whole job
A workflow is only automated when the final action is both possible and allowed.
Worked case: returns. A return request needs eligibility checked, a label generated and a short email sent. If the agent can draft the email but a person still has to generate the label in a separate tool, the agent has automated the easy minute and left the three-minute step in place. That is what the wholesaler's logistics contact concluded about return labels: generating the label PDF and writing a two-line email is already quick for him, so an AI that still needs him to generate the PDF adds little, and the case was parked until the carrier connection exists. Parking a case like that until the label step is connected is a reasonable call. Conversely, an action that the API supports may be forbidden by policy, like changing a delivery address once a parcel is with the carrier; the data is ready and the action is still off the table.
For each workflow, list the final actions, mark each as possible, allowed, or neither, and estimate the manual time that remains if the agent stops short. Automate the wrappers only where the core step is covered.
A readiness checklist per workflow
Run this for each intent before it enters a pilot.
- [ ] Sampled real tickets: share with the needed fields complete, stale or wrong.
- [ ] Freshness requirement stated, with the AI's behaviour when data is older than that and an owner for interim refreshes.
- [ ] Field meanings written down as the service team uses them, including what the data does not express.
- [ ] Authoritative source named for every piece the workflow needs, including local files, with an owner.
- [ ] Read scopes defined for anonymous, authenticated and never-through-AI data, enforced by the serving system.
- [ ] Final actions listed as possible, allowed or neither; remaining manual time estimated.
- [ ] Exception branches designed: missing data, failed lookup, stale answer, unmapped record.
- [ ] Validation for customer-supplied evidence where an action depends on it (a claims process that accepts any uploaded image is a rule problem, not an AI problem).
Who does this work
Readiness is not purely technical. The people who distinguish mandatory fields from nice-to-have ones, and who know which local file is really the source, are the frontline team in contact with customers. The manufacturer's project lead was working through exactly that with the customer-service team, because they were the ones who knew which columns were mandatory and which were nice to have. Their calendar governs the pace: a readiness review scheduled over month-end will not happen. Pair one service expert with one integration engineer per workflow, and expect the first pass to take longer than the integration itself.
Limits
These tests tell you whether a workflow can run on the data you have; they do not say whether it is worth running. A rule-based system may already automate a share of simple cases, and that baseline belongs in the business case before any AI figure does. The tests also assume you can sample real tickets; where you cannot, treat every "ready" verdict as provisional until live traffic confirms it.
Related reading
- How to map your AI customer-support sources: the source hierarchy and governance this guide builds on.
- what a customer-service AI should be allowed to do: identity and action rights, enforced in the system.
- Taking a customer-service AI agent live: where readiness evidence feeds the pilot design.
FAQ
Do we need live integrations before piloting?
Not always. Choose the refresh cadence from the age of the questions customers ask: invoice and tracking questions often tolerate a daily refresh, stock promises for large customers usually do not. State the cadence per intent and what the AI does when data is older than that.
Our data lives partly in spreadsheets. Is the workflow still automatable?
Only after that data has a home the agent can read, with a named owner. Customer-specific code mappings and lead times are often the real authority for an order workflow even when the ERP is connected, so the readiness work is to move or expose them before integration.
Can we rely on instructions to keep account data from unauthenticated users?
No. Instructions can tell the agent to require a login; the system serving the data must enforce it, because it can be reached outside the conversation. Define read scopes per workflow and enforce them at the source.
