Direct answer
The systems' APIs, not the logic, usually set the pace of a workflow automation project. Writing the rules for what happens when a form arrives or a status changes is straightforward once the process is agreed. What takes calendar time is finding out what each connected system will actually let an integration read and write, getting the right access, and testing against real data and real failures. So we do not publish a fixed duration. We describe phases and dependencies, and we name which of them sit with you. This page is about sequence and pace. For budget see workflow automation cost, and for one popular tool see n8n automation.
Phase 1: discovery
Discovery turns 'we want this automated' into a written process: the trigger, each step, who does what today, the data that moves, and the exceptions. Its pace depends on whether the process is documented or lives in someone's head, and whether the people who do the work are available to walk through it. Discovery ends when a builder could follow the description without asking you anything. If two people describe the process differently, that disagreement is the first thing to resolve, and it belongs to you rather than to the build.
Phase 2: access
Access is the phase most often underestimated. For each system the workflow touches, someone needs to confirm what it exposes to integrations, create a dedicated account or credential for the automation, and grant the right permissions. Some systems offer generous programmatic access; others restrict it by plan, by role or by approval process. We confirm what each system actually exposes before promising a design, and we do not assume any ready-made connector exists between two given tools. Our access checklist is in AI automation agency access requirements.
Phase 3: build
The build turns the agreed process into working steps. Its length follows the number of systems, the number of decision branches and how much data must be reshaped between systems. Field names, formats and identifiers rarely match across tools, and mapping them is most of the work. A workflow with few branches over well-behaved systems builds faster than a short-looking one that has to reconcile inconsistent records.
Phase 4: test
Testing uses realistic data, not a single clean example. Run the workflow with typical records, with unusual ones, with the same event twice, and with missing fields. Test in a safe environment or with test records where the systems allow it. Testing takes longer when the systems offer no sandbox, because every run touches live data and must be checked more carefully. Decide who signs off and against what before testing starts.
Phase 5: exceptions
A workflow that only handles the expected path is unfinished. Decide what happens when a system is unavailable, a record is incomplete, a value is not recognised or a step fails halfway: who is told, how the item is held, and how it is retried or resolved by a person. Exception design is a decision task first and a build task second, and it is where an honest timeline differs from an optimistic one. See workflow exception and escalation design for how we approach it.
Phase 6: handover
Handover means your team can run and change the workflow without us. That includes accounts and credentials in your name, a written description of each step, a note of where errors appear and who watches them, and a walkthrough with the person who will own it. It is quick when it was planned from the start and slow when it was left for the last day.
What slows a project
Look for these early, because each can be checked before build begins:
- A system with restricted or plan-limited integration access
- Credentials tied to a named person who is unavailable or leaves
- A process that differs between team members
- No test environment, so every check touches live records
- Requests added mid-build that were not in the written scope
- Nobody named to approve decisions promptly
- Data quality problems in the source system that the automation exposes
Scoping a first workflow
A first workflow that is small and complete is more predictable than an ambitious one. Choose a process with a clear trigger, a small number of systems, and a visible cost when done by hand. Define the finish line as a working workflow with its exceptions handled and a handover, not as 'automation of the department'. The Automation Opportunity Finder can help you pick which process to start with. A single workflow across a small number of systems can fit the fixed-scope Automation Sprint (€1,690); larger designs are custom scope, quoted once we map the process. LATYNEX is a remote English-language vendor, and the scope and price are agreed in writing before work starts. The wider service is workflow automation and systems integration.
Questions
Why don't you give a standard duration for automation?+
Because the pace depends on the systems' access limits, the state of the data and how settled the process is, none of which can be known without looking. We describe the phases and dependencies so you can plan, and we agree a scope in writing once we have seen your setup.
Which phase most often surprises people?+
Access. Systems differ widely in what they allow integrations to do, and getting the right credentials and permissions can involve people outside the project. Confirming it early removes the most common source of delay.
Can testing be skipped for a simple workflow?+
We would not skip it. Even a simple workflow can create duplicates or fail silently when a field is empty. A short test with realistic and awkward records is cheap compared with repairing bad data afterwards.
Is a second workflow faster than the first?+
Often it is, because access, naming conventions and handover habits are already in place. It still depends on whether the second workflow touches new systems, so treat it as its own scope.
What do you need from us to start?+
A description of the process as it runs today, a list of the systems involved with an admin contact for each, examples of typical and awkward records, and one person who can approve decisions.