Connect the business systems you already use.

Information should move without the copy and paste. We check what your systems allow, then build the connection.

Systems we have already brought together.

We connect existing business systems after checking the access each one allows. Rooftop, live at a Melbourne dealership, brings several systems into one reporting view.

Sources

  1. Dealer management system
  2. Sales log
  3. Phone call records
  4. Trade-in valuations
  5. Website leads

Brought together

Rooftop checks and combines them through the day.

Illustrative screen · sample content

Seen on office screens, phones and the showroom and workshop TVs. Demonstration data, made-up names

More examples and screen sizes

One implementation: dealership systems into Rooftop.

Rooftop reads information from the dealership's existing systems, checks and combines it, and presents it in reporting views.

Illustrative screen · sample content
Illustrative screen · sample content
Rooftop on a workshop TV
Showroom and workshop TVs

This example demonstrates reporting connections. A connection that writes changes back into another system needs its own scope and access check. Demonstration data, made-up names

Decide what moves, then build the link.

The scope depends on the records, rules and access involved. These are the things we settle before building it.

Illustrative sample
  1. What moves, and where

    which records, in which direction, how often

  2. The source of truth

    for each piece of information

  3. The access each system allows

    checked before we quote

  4. Missing or wrong data

    we agree how it is spotted and what happens to it

  5. When a connection fails

    how it is noticed, and who is told

  6. Read-only where that is enough

    we do not write to a system unless the job needs it

Common questions

Do we have to replace the software we use?

No. The point is to keep what works and connect it. Rooftop, for example, reads from a dealership's existing systems rather than replacing them.

Will it change data in our systems?

Only if the job needs it, and only what is agreed in the written scope. Where reading is enough, the connection is read-only.

What happens if a connection breaks?

Support, and who looks after what, are set out in the proposal before go-live, so there are no surprises afterwards.

How much does an integration cost?

It depends on the job. You get a written scope and a fixed price before any development starts, and nothing is built until you agree it.

Then build, test, release and handover. See how custom work runs

Can you connect our systems?

Sometimes the honest answer is no: every system allows different access, and some allow none. Before we quote, we look at your systems, the access they allow and what you want to move, then tell you plainly what we can connect, what we cannot, and what it costs.

Custom integration, or a ready-made connector?

Check a ready-made connector first: does it support the records, fields, direction, frequency and failure handling you need? Custom integration earns its place when no connector exists, when the standard one leaves out fields you rely on, or when the information needs checking on the way through. Our system integration checklist lists what to write down first.

Tell us which systems should be talking.

A rough description is enough.

Mark Hanna
Mark Hanna
Jordan Smale
Jordan Smale