ENZAXMost descriptions of an automation project's timeline are vague on purpose, because a specific answer is harder to sell and easier to be wrong about. This is an attempt at the specific version: what actually happens, in what order, and why each part takes as long as it does. GENZAX follows the same five-step process described on the homepage (Discovery, Strategy, Build, Deploy, Optimize), and this is what each of those actually looks like in practice.
Discovery: figuring out what's actually being asked for
This step is a conversation, not a proposal. The goal is understanding what's actually slow, repetitive or inconsistent in the business, which is often different from what the business owner initially describes. Someone might say "I need a chatbot," when the real underlying problem is that inquiries sit unanswered for a day. Discovery is where that gap gets found, before anything gets built around the wrong assumption. This usually takes one or two conversations, not a single rushed call, because the first version of the problem someone describes is rarely the complete picture.
Strategy: deciding what actually gets built, and what doesn't
Not every problem uncovered in Discovery is worth automating, and this is the step where that gets sorted out honestly. Some things genuinely need a system built around them. Others need a simpler fix, like a form field added or a process clarified, that doesn't require any automation at all. Strategy also means mapping the actual data involved: what system currently holds the information, what format it's in, and what would need to connect to what. This is where realistic scope gets set, instead of an ambitious wishlist that quietly shrinks later.
Build: the part that takes the longest, for reasons that aren't obvious upfront
Building the actual workflow is rarely the slow part. Getting it to handle real, messy input reliably is. A workflow that works perfectly on the five test cases used during development often breaks on the fifteenth real inquiry, because real data is messier than test data. Build includes writing the logic, but it also includes testing against genuinely unusual inputs on purpose: a message in a different format, a field left blank, an edge case someone remembers from experience with the business. This is also where integration work happens, connecting to whatever CRM, spreadsheet or email system the business already uses, which sometimes goes smoothly and sometimes reveals that a system's API is more limited than its marketing page suggested.
Deploy: turning it on for real, carefully
A workflow that's been tested in a sandbox still needs a careful first exposure to real traffic. Deploy usually means turning the system on in a limited way first, watching closely, and expanding it once it's clearly behaving correctly, rather than flipping it fully live on day one and hoping. For something handling customer-facing communication, this caution matters more than it might seem like it should, because a mistake made publicly is far more costly to fix than one caught in a controlled test.
Optimize: the step most projects skip, and shouldn't
A system that worked well in its first week doesn't necessarily keep working well forever. Business processes change, input patterns shift, and something that was rare during testing becomes common six months later. Optimize means actually looking at what the system is doing after launch: sampling its output, checking whether the classifications it's making still look right, and adjusting when they don't. Projects that skip this step tend to quietly degrade over months without anyone noticing until a customer complaint makes the problem visible.
What the business actually needs to provide
A project moves faster when the business can quickly provide access to the systems involved (CRM logins, form platform access, whatever the automation needs to connect to) and can answer questions about how the process actually works today, including the messy exceptions that don't show up in an official process document. Projects slow down most often not during Build itself, but while waiting on access or an answer to a question that only someone inside the business can give. Flagging this upfront tends to save more time than almost anything else, since it's rarely the technical work that stalls a project, it's the waiting.
How long does this actually take
It depends heavily on scope, and anyone who gives you an identical timeline for every project regardless of complexity is guessing. A narrow, well-defined workflow connecting two systems that already have solid APIs can move from Discovery to a working Deploy in a couple of weeks. A workflow spanning several systems, with genuinely messy data or unclear existing rules, takes longer, sometimes considerably longer, and rushing that kind of project to hit an arbitrary deadline usually just moves the debugging from Build into a much more expensive place: production, in front of real customers.
The honest version of a timeline is an estimate that firms up after Discovery and Strategy actually happen, rather than a number pulled out during the first sales conversation, because that's the point where the real shape of the problem is finally clear enough to estimate against.