To brief an integration project well, write one page that answers nine things before the first call: which systems are involved, what should flow from where to where and when, who keys in what today, how much volume you deal with (in your own words), what "done" looks like, which awkward cases matter (credit notes, part payments, cancellations), which reports you need at the end, who owns the project inside your business, and what deadline or event is driving it. You don't need technical language or field names. A provider who gets that page before the first call can usually tell you quickly whether a standard connector will do, and can get to a fixed quote faster, without you paying for the same discovery twice.
Why a brief matters more than it looks
Most integration conversations start with a sentence like "we need Xero to talk to our job system". That sentence is true, but it hides almost everything that decides the cost: which records move, in which direction, how often, what happens when something doesn't match, and who fixes it.
Without a brief, the first call is spent finding those things out. Then a second provider asks the same questions. Then, if the project goes ahead, someone runs a paid discovery phase that covers the same ground again. You end up paying, in money or in staff time, to explain your own business three times.
A one-page brief fixes most of that. It doesn't have to be perfect. Its job is to:
- Show what matters to you, so the provider spends time on your real problem rather than a generic demo.
- Bring the hard parts out early. Exceptions such as credit notes and part payments are where integrations go wrong, and where quotes go up. If they're on the page from day one, they get priced from day one.
- Give you a test for "done". When the work is finished, you check it against what you wrote, not against what someone remembers from a call.
The one-page integration brief template
Copy this list and answer each point in plain English. Short answers are fine. "Don't know" is also a useful answer, because it tells the provider where the questions are.
- Business and contact. Your business name, what you do in one line, and who is filling this in.
- The problem in one sentence. For example: "Invoices from our job system are re-keyed into Xero every Friday and the totals never quite match."
- The systems. Every system involved, with the product name and edition if you know it (for example Xero, MYOB Business, MYOB Advanced, simPRO, Cin7, Deputy, HubSpot, a custom database, a shared spreadsheet). Note which one you think should be the "source of truth" for each type of record.
- What should flow where, and when. One line per flow: what moves, from which system, to which system, and how soon it needs to arrive. For example: "Approved invoices from the job system to Xero, same day. Payments from Xero back to the job system, overnight is fine."
- Who enters what today. For each flow, who does it now, how (re-keying, export and import, copy and paste), and roughly how long it takes them. This is the work the integration is meant to remove.
- Volumes, in your own words. For example: "around 400 invoices a month, busier in June", "about 60 active jobs", "three entities, one bank account each". Rough is fine.
- The exceptions. The cases that don't follow the normal path: credit notes, part payments, deposits, retentions, cancelled or changed orders, back orders, refunds, multi-currency, intercompany charges, records that get edited after they've been sent. List the ones that happen in your business, even rarely.
- Reports you need at the end. The reports or numbers people should be able to see once this works. Attach an example if you have one, even if it's a spreadsheet.
- What "done" looks like. How you'll know it worked. For example: "Nobody re-keys invoices, and the job system and Xero agree on what each customer owes at month end."
- Who owns it internally. The person who decides, the person who knows the process day to day, and who will look after it once it's live.
- Deadline or trigger. Why now. For example: a system being switched off, a new financial year, an acquisition, a staff member leaving, Payday Super, a new client contract.
- What you've already tried. Connectors, apps, workarounds or previous providers, and where they stopped.
- Anything that can't change. Systems you must keep, processes the auditors rely on, or teams who won't change how they work.
The people who do the work every day often fill in the gaps better than anyone else.
How to fill in the hard parts
A few points trip people up. Here is how to handle them without technical knowledge.
"What should flow where" when you're not sure. Describe the job, not the data. "When a job is finished, the office creates an invoice" is enough. A good provider turns that into fields and mappings. If you're unsure which direction something should go, say so. That is one of the most useful things to discuss on the first call.
Volumes when nobody counts. Pick a recent month and count roughly from your accounting system: invoices raised, bills entered, pay runs, new customers. If one month was unusual, say why. Volume affects whether a simple connector will cope, and whether the provider has to think about limits on the systems' interfaces.
Exceptions you'd rather not mention. Put them in anyway. A brief that only describes the tidy path will get a quote for the tidy path, and the messy cases come back later as variations. Credit notes, part payments and cancellations are usually the difference between an integration that works and one that only half works.
"Done" when you just want it fixed. Write the test you'd use yourself. "The bank reconciliation takes less than a day" or "the job report and the accounts agree" is a better definition than "it syncs".
What a good brief gets you
With the brief in hand, the first conversation changes. Instead of a general discovery call, you can talk about the specific decisions: which system owns each record, how exceptions should be handled, and whether a standard connector covers enough of it.
Sometimes the honest answer is that you don't need a project at all. A setting in Xero or MYOB, a marketplace app, or a small change to how your team enters data can solve the problem. A clear brief makes that easier to see, for you and for the provider.
When a custom integration is needed, a brief usually means:
- A fixed quote sooner. The provider can scope from what you've written, and the follow-up questions are about the gaps rather than starting from nothing.
- Less discovery to pay for. The ground the brief covers doesn't need a paid discovery phase to find it.
- Fewer surprises. Exceptions and reports that are in the brief are in the scope.
- A fair comparison. If you're talking to more than one provider, send each of them the same page.
If a provider can't say how they'll handle your credit notes or part payments, that's worth knowing early. Our post on questions to ask a software vendor about integration covers what to ask when a new system is part of the picture.
When you can't write the brief yet
Sometimes the brief stalls at point 4 or point 5. Nobody is quite sure how orders get from the sales team to the warehouse, or three people describe month end three different ways. That isn't a failure. It tells you the problem is the process, not the connection, and an integration built on an unclear process tends to automate the confusion.
That is what our $5,000 Process & Systems Audit is for. We map how work and data actually move through your business and your systems, find where things break or get re-keyed, and give you a written report. The report covers everything this brief asks for, and more, so you can take it to us or to any other provider and get a fixed quote. See the Process & Systems Audit for what's included.
If the brief comes together easily, you don't need the audit. Send us the page and book a free initial chat. It's a no-obligation conversation, and we'll tell you whether this looks like a standard connector, a custom integration or a process fix. For the kind of work involved, see third-party software integration, and for the wider picture of connecting and moving between accounting systems, the Xero and MYOB integration and migration guide.
Frequently asked questions
What should be in an integration project brief?
The systems involved, what should flow between them and how often, who enters the data today, rough volumes, the exceptions (credit notes, part payments, cancellations), the reports you need, what "done" looks like, who owns the project, and the deadline or event driving it. One page is enough.
Do I need technical knowledge to write an integration brief?
No. Describe the work in your own words: who does what, in which system, and where it goes wrong. Field names, mappings and interfaces are the provider's job. The most useful briefs come from the people who do the work every day.
How do I get a fixed quote for an integration?
Give the provider enough to scope it: the brief above, plus examples of the records and reports involved. Exceptions are the part most often left out, and the part most likely to change the price later. We scope every project first and give a fixed quote after a free initial chat.
What if our processes are too messy to describe?
Then start with the process, not the integration. Write down what you can, mark the gaps as "don't know", and consider a process review first. Our Process & Systems Audit maps how things actually work and produces a written report you can use to brief any provider.
Should I send the same brief to more than one provider?
Yes. The same brief makes quotes comparable, and how each provider handles your exceptions tells you a lot.
Ready to talk it through? Send us your brief, or just the parts you've got, and book a free initial chat.