Starting AI Adoption With a Single Week of Recorded Friction
Many operators begin AI adoption by looking at tools first and problems second. A more reliable starting point is the work itself. Before evaluating any model, assistant, or automation product, it helps to record where your team actually loses time, repeats effort, or waits on other people. This article describes a lightweight method for capturing that friction over one working week, then turning the record into a short list of candidate workflows. The goal is not to produce a perfect map of your operation. It is to replace assumptions with observations so that later decisions about AI rest on evidence your own team can verify.
Why Observation Should Come Before Selection
Tool-led adoption tends to produce a familiar pattern: a demo impresses someone, a trial begins, and only afterward does anyone ask which step the tool is meant to improve. The result is often a capability searching for a use, with unclear ownership and no agreed measure of success. Starting from observation reverses that order. You ask which activities are slow, error-prone, or repetitive, and you let the answers narrow the field before any vendor enters the conversation.
This matters especially for operators working across several Asian markets, where the same role may involve different languages, documentation habits, approval chains, and customer expectations. A task that looks uniform in a spreadsheet may vary considerably in practice. A week of recorded friction surfaces those differences in a way that a general buying guide cannot.
Running a One-Week Friction Log
Ask each team member to keep a simple log for five working days. For every task that takes more than ten minutes or that they repeat more than twice a day, record four things: the task name, the approximate time spent, the people or systems involved, and the point at which work stalled. Avoid trying to be exhaustive. Small, frequent interruptions, such as reformatting the same status update or copying figures between two tools, often reveal more than a single large project.
Keep the log in whatever format the team already uses. A shared document or a plain table is enough. The aim is consistency rather than elegance. At the end of the week, gather the logs and group similar entries. You will usually find that a handful of recurring patterns account for most of the lost time, and those patterns are the real candidates for AI assistance or for process change that needs no AI at all.
Separating Symptoms From Bottlenecks
A frequent entry in a friction log is something like "waiting for the weekly report." That is a symptom. The bottleneck may be that data arrives from three sources in three formats, or that one person must reconcile them manually before anyone else can proceed. Asking why a task stalls, and then asking why again, usually moves you from the visible delay to its structural cause.
Distinguishing symptoms from bottlenecks protects you from automating the wrong thing. Speeding up a step that is not on the critical path produces little benefit. A useful test is to ask what would change for the team if this one step took half the time. If the honest answer is "nothing much," the step is not a priority, regardless of how annoying it feels.
A Checklist for Shortlisting Candidate Workflows
Once the logs are grouped, screen each candidate workflow against a short set of questions. Is the task performed often enough that a small improvement compounds? Does it involve text, documents, or structured data that someone can describe clearly? Is the output checked by a person before it matters, or would an error reach a customer or a financial record unnoticed? Who currently owns the task, and would that person agree the task is worth changing?
Add operational questions as well. What information does the task require, and where does that information live? Are there confidentiality or regional data constraints that affect where it can be processed? If the workflow were automated tomorrow, who would notice a failure, and how quickly? Candidates that score well on frequency and clarity but poorly on oversight should usually wait until review steps are in place.
Asking Vendors the Questions Your Log Makes Possible
Once you have a shortlist grounded in your own records, vendor conversations become more precise. Instead of asking whether a product can "do AI," you can describe the specific workflow, its volume, its inputs, and the failure you most want to avoid. Ask how the product handles the data your workflow involves, where that data is stored, and what the vendor's stated policies say about retention and use. Confirm each answer in writing against the vendor's own documentation rather than relying on verbal summaries.
Be careful about accepting claims of accuracy or reliability without a test on your own material. A short pilot using a sample from your log, reviewed by the people who currently do the work, will tell you more than a generic benchmark. Record the results against the friction you originally measured, so that the comparison is between your baseline and the outcome, not between one vendor's claims and another's.