Signs you’ve bought a project, not a product

If developers are required, you have a project, not a product.

That one test explains most integration pain. The moment an “integration” needs scripts, custom logic, or a technical owner to keep it working, you’re no longer buying something your team can operate. You’re inheriting an integration program.

For enterprise IT teams and service providers working across different platforms, that distinction matters. The work does not stop at “go live”. Workflows change, platforms update, and ticket volume exposes every edge case.

Here are the five clearest signs you’ve bought a project instead of a product.

1) Developers are required to make it work

This is the biggest tell.

If someone needs to:

• write scripts

• implement custom transformation logic

• maintain “rules” that look like code

• manage a repository or deployment process

• be the person who “can tweak it when it breaks”

…then you are not configuring a product. You are commissioning a bespoke build.

A productised integration is designed so an operational owner can configure it via guided setup, mappings, and controls, without engineering involvement after initial connection.

Project signal: “We’ll just write a small script for that.”
Product signal: “Choose the mapping and workflow rules in the UI.”

2) Setup takes weeks, not hours

If your onboarding plan looks like:

• discovery workshops

• requirements capture

• build sprints

• test cycles

• deployment windows

…you are running a project.

A true product may still require scheduling across two organisations, but the integration work itself should not be measured in weeks. Time should be spent aligning stakeholders, not building glue.

Project signal: timelines are driven by build and test cycles.
Product signal: timelines are driven by stakeholder availability and approvals.

3) Every change becomes a change request

Your integration will change. That is a certainty, not a risk.

Workflows evolve:

• new ticket types

• new status models

• new assignment groups

• new customer-specific routing

• new fields required for reporting, billing, or SLA compliance

If changes require logging a ticket, waiting for a sprint, and re-testing a deployment, you’ve created an ongoing integration backlog. That is a project with a permanent operating cost.

Project signal: “Log it, we’ll schedule it for the next release.”
Product signal: “Update the configuration and apply it.”

4) It only solves ticket creation, not the ticket lifecycle

Many “integrations” demo well because they focus on a single event: ticket created.

Real service delivery is coordination. Tickets move through dozens of touchpoints: comments, status changes, reassignments, escalations, approvals, and priority shifts.

If the tool only handles the easy first step, the “integration” becomes an illusion and the humans absorb the rest.

Project signal: event-based automations that stop at creation.
Product signal: end-to-end, bi-directional flow across the full ticket lifecycle.

5) Services fees or retainers are required to keep it alive

Services are not inherently bad. Sometimes they accelerate a rollout.

But if the vendor’s default commercial motion includes:

• a professional services statement of work

• billable implementation hours

• a maintenance retainer

• “managed integration” fees as standard

…then treat it as consulting, even if the marketing says SaaS. The commercial structure usually reflects the operational reality.

Project signal: services are assumed.
Product signal: services are optional and primarily for acceleration.

A practical rule of thumb: the “developer test”

If your integration plan includes any of the following as ongoing requirements:

• developer involvement

• recurring services hours

• a permanent technical owner

• regular rebuilds when workflows change

Then you have not bought an integration product.

You have bought an integration project.

Where Support Fusion fits

Support Fusion is built by IT integration experts for the IT industry.

We focus on visual, configurable ticket integrations designed to be operated day-to-day, without scripts and without developer dependency. Time to value is measured in hours, not weeks, because the goal is not to “get tickets across once”. The goal is to keep work flowing between organisations, reliably, through the full ticket lifecycle.

If you want to sanity-check your current approach, get a demo of Support Fusion. We’ll map your workflow quickly and show you what productised integration looks like in practice.