FAQ

IWAB packages are tiered around scope, integrations, and governance. You typically see a setup phase plus predictable monthly automation capacity. Exact numbers depend on your workflows, use the AI packages matrix or ask us for a tailored quote.

We agree on outcomes up front: time saved, quality of handoffs, error reduction, and adoption by your team. Where possible we track before/after metrics and review them in steering checkpoints.

Most engagements begin with a short discovery: current tools, repetitive tasks, risk boundaries, and budget. From there we propose a package tier and a phased rollout so value lands early.

No. Many clients start with a problem statement rather than a SKU. We help translate that into the right mix of web, automation, AI, and operations support.

Teams who feel growth stalling behind manual steps, not necessarily those hunting another campaign. If handoffs, approvals, or data sync eat the week, automation usually pays back before you spend on louder marketing.

Packages describe delivery depth (workflows, governance, rollout). Hosting describes runtime (shared or dedicated environment, operations, backups). Keeping them separate makes budget decisions and responsibilities clearer.

We usually start from your existing stack. IWAB maps flows between your CRM, support, finance, marketing, and internal tools first, then proposes only the changes that unlock reliability or speed.

No, but n8n is often the practical orchestration layer. If you already run another engine, we can adapt the pattern as long as trigger logic, retries, observability, and ownership stay clear.

We work with explicit ownership per layer (build, runtime, operations), role-based access, and production safeguards such as logging, retry, and alerting. For data-related concerns, we align with your policy and compliance requirements.

Yes. For teams with locality requirements, hosting can be set up with a Swedish datacenter chain through Cygrids. We clarify this early so legal and procurement teams can review with the right context.

Post-launch support is defined in scope and handover notes. We set routines for monitoring, issue response, and updates so flows stay stable when volumes, teams, or integrations change.

Most engagements are phased to create an early win first, then expand. Typical first outcomes are less manual follow-up, fewer handover errors, and better visibility in one to four weeks depending on access and stack complexity.

Both. We can start with an advisory sprint (map, prioritize, decide), then execute delivery with the same team so strategy and implementation stay connected.

We track agreed indicators such as turnaround time, handover quality, throughput, and adoption. Reviews are tied to checkpoints so stakeholders can decide whether to scale, adjust, or pause.

Scope includes the agreed delivery track, implementation steps, and handover artifacts. Optional parts are clearly listed as add-ons, so you can approve essentials first and expand without hidden bundle pressure.