Hi Fausto,
Great questions! Here are some thoughts based on working with Architect flows in enterprise environments.
On reusable tasks vs separate flows - We tend to use Reusable Tasks for logic that's repeated within the same flow, such as queue lookups, validation, and common integration logic. This keeps the main flow cleaner and avoids duplicating logic. I'd only consider separate flows when there's a clear separation of functionality or ownership.
On naming conventions - We use meaningful names for flows, tasks, variables, and Data Actions so their purpose is immediately obvious. Variables such as Task.IDNumber, State.queueId, and State.isComplaint make flows much easier to understand and troubleshoot.
On menu levels - We don't follow a strict rule, but we generally align with industry best practices of keeping IVRs as simple as possible. Our current design has five options at the main menu, with only two options leading to a second level. If a journey starts requiring more levels, we see that as a good opportunity to simplify the experience or redesign the flow.
For me, consistent naming, modular design, and reusing common logic have made the biggest difference in keeping Architect solutions maintainable over time.
------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------