Most "discovery" engagements produce a slide deck. Ours produces a decision: which workflow to automate first, which ones to leave alone, and what it costs to find out you were wrong. A good discovery week ends with a scoped pilot and a rejected list — not a roadmap that reads well in a boardroom and dies on contact with your actual data.
Here's what that week looks like when we run it, and what should be sitting on your desk at the end of it.
The wrong version of this week
The common failure mode is starting from the tool instead of the problem. Someone in leadership has seen a demo — an agent that reads inboxes, a chatbot that handles support tickets — and the brief becomes "build us that." Discovery turns into a requirements-gathering exercise for a predetermined solution. Teams skip straight to architecture diagrams and model selection before anyone has looked at the actual documents, tickets, or emails the system will touch.
It seems efficient. It isn't. A team that picks a vendor and a model before checking whether the source data is even structured enough to automate against can spend months on "inbox triage" that assumes clean subject-line categorization that doesn't exist — because the real emails are a mess of forwarded threads and inconsistent formatting nobody opened before scoping the build. The fix isn't a better prompt. It's going back to week one.
What we actually do
Day one is data, not tools. We ask for real samples — actual emails, actual support tickets, actual documents — not descriptions of them. When we built Email Triage, the category list came from reading real inboxes, not from guessing — people's mental model of their inbox and the inbox itself are usually two different things. You cannot scope an automation against a description of data. You scope it against the data.
Day two and three, we map the workflow as it's actually performed, not as it's documented. We sit with whoever does the task today — a recruiter screening CVs, an editor reviewing drafts — and watch where they hesitate, where they override the "standard" process, and where judgment calls happen that no SOP mentions. A phrase like "good fit" can mean different things depending on which hiring manager is asking — the kind of thing that never shows up in a requirements doc but breaks an automation on day one of production.
Day four, we rule things out. This is the part clients don't expect but end up valuing most. Not every workflow is worth automating with an LLM. Some are better served by a deterministic rule, a regex, or honestly, nothing — the volume doesn't justify the maintenance cost. Sometimes the actual volume is low enough that a human doing it manually costs less than building and maintaining a pipeline — and when the task is fully predictable, like AutoArchive Mail's scheduled mailbox archiving, plain rules beat a model. Ruling things out is the deliverable, not a failure to find work.
Day five, we write the scope. Not a roadmap — a single pilot: one workflow, a defined success metric, a cost estimate for both build and ongoing inference, and an explicit list of what we're not building yet. If you want to see how this plays out end to end, start a project and we'll walk you through what week one would look like for your specific stack.
Where this breaks
A full discovery week is overkill for a genuinely small, well-bounded task — if you already know exactly what the input and output look like and the volume is low, spend a day, not a week. It also breaks down when the client can't produce real data during the engagement — NDAs, data residency rules, or simply nobody having export access. A discovery week can stall on day one waiting for a data export that takes weeks to clear legal. If you can't get us real samples, tell us before we start, not after.
And discovery doesn't replace evals. It tells you what's worth building and roughly how well it needs to perform. It doesn't tell you whether your first prompt actually hits that bar — that's a second phase, with its own week.
This week
Before you brief anyone on an AI project, pull 50–200 real examples of the thing you want automated — actual emails, actual tickets, actual documents, not a description of them. Look at them yourself for twenty minutes. If you find inconsistencies your team hasn't mentioned, that's your actual scope. If it looks cleaner than expected, you've probably found your fastest pilot.