XBA is a New Zealand consultancy working across five areas: digital presence, AI, automation, integration, and Accredo Saturn customisation. Nine offerings sit under those five. Most engagements start in one of them and end up touching a second, because the problem a business can see is rarely the whole problem.
Personal reply from Andrew within one business day.
A pillar is a kind of problem, not a product line. They are numbered in roughly the order a business meets them: you get found, the enquiry arrives, the work gets done, the systems agree with each other, and the ledger underneath stays correct.
Grouping the work this way is deliberate, and it is not how most consultancies present a service list. The usual arrangement is a menu of technologies — a page for each platform, each integration, each product partnership — which is useful if you already know what you want to buy and close to useless if what you have is a symptom. Almost everyone arrives with a symptom.
The pillars are ordered by dependency, not by price. Presence sits first because it is the one that decides whether any of the others are ever needed: a business nobody can find has an expensive problem that no amount of internal automation will touch. Accredo Saturn sits fifth not because it matters least — it is the deepest specialty here and the one with the longest track record behind it — but because it is the furthest down the stack. It is the ledger everything else eventually settles into.
Nobody buys all five. A typical engagement is one pillar, sometimes two where they genuinely touch — a rebuild that also needs the enquiry form to reach a CRM, or an integration that turns out to need a small app at one end. Being told you need a programme across five areas is a reliable sign that somebody is selling a retainer rather than solving a problem.
A rebuild that changes what the site does rather than how it looks: one page for each thing you sell, proof sitting beside the claim it supports, and speed and accessibility measured rather than promised.
Technical search work, question-led content, and the structured data and consistent naming that let an AI assistant quote you accurately instead of approximating you from whatever it can find.
Workflows that read unstructured input — email, documents, free-text notes — classify it, and hand anything carrying judgement or money to a person before it commits to anything.
Which two or three uses genuinely pay for themselves in your business, which are demonstrations, and what the honest sequencing is. Frequently the recommendation is to do fewer things.
The re-keying, the chasing, and the standing weekly task that exists only because two systems will not talk to each other. Automated so that the trail somebody can audit afterwards survives the change.
The report that costs somebody a morning every month, replaced by a scheduled query that produces the same numbers and can be checked line by line against the version it replaces.
Two systems that ought to agree and do not. One source of truth per data type, connected through documented interfaces, and reconciled in parallel before anybody is asked to trust it.
For where no product fits the way the work actually happens: a small application that captures the job where it is done and posts it into the systems you already run, with nothing re-typed.
The deepest specialty on this list: business rules enforced inside the transaction, documents that carry your own logic, and data reaching the systems around Saturn without anyone re-keying it.
The five exist because a customer passes through five stages between having a problem and appearing correctly in your ledger. Each stage can fail independently, and the stage that is failing is the one worth spending on.
Somebody with the problem you solve goes looking — in a search engine, or increasingly by asking an assistant. If nothing of yours is there, nothing further down this list is ever reached.
pillar 01 · presenceThey land, and decide in a few seconds whether this looks like a business that could do the job. Credibility at this point is structural, not decorative.
pillar 01 · presenceThe enquiry arrives somewhere it will actually be answered, carrying enough detail to price it without three emails first.
pillars 01 · 04The work gets done without three people typing the same information into three systems, and without the job stalling because one of them was on leave.
pillars 02 · 03It reaches the ledger correctly, once, so the month-end numbers are right without a reconciliation weekend to make them right.
pillars 04 · 05Reading the chain from the left is the useful exercise, because the earliest failing stage is nearly always the one to fix. There is no return on automating stage four while stage one is producing two enquiries a month — the work gets done faster and there is still almost none of it. Equally, a business drowning in enquiries it cannot process does not need more presence; it needs stages four and five to stop leaking, and more marketing at that point actively makes the experience worse for the customers it already has.
Most businesses can identify their failing stage in about a minute, which is why the homepage leads with a list of symptoms rather than a list of services. If you already know which stage is broken, the pillar cards above map to it directly. If you do not, the free audit exists to establish that and nothing more — it is a written opinion on where the loss actually is, and it is worth having even if the answer is that nothing needs building.
| Start with presence | Start with automation | Start with integration | |
|---|---|---|---|
| The symptom | Enquiries are scarce, or arrive knowing nothing about what you do. | People spend hours on work a system should be doing unattended. | The same information is typed into two systems, and they still disagree. |
| What it is costing now | Opportunities that never became conversations. Invisible, and the largest of the three. | Salaried hours, plus the errors that come with doing the same thing by hand every week. | Month-end reconciliation, and decisions made on numbers nobody fully trusts. |
| Typical first piece of work | A structural rebuild, or the SEO and AEO half if the site is already sound. | One process, end to end, run in parallel with the manual version until it agrees. | One data flow, in one direction, with the reconciliation built before the cutover. |
| What it will not fix | A business that cannot yet say in one sentence what it sells and to whom. | A process that should not exist. Automating it just makes the wrong thing faster. | Two teams that disagree about which system is right. That is a decision, not a build. |
| How soon you can tell | Slowly. Search and citation shift over months, which is why it is measured monthly against a fixed question set. | Immediately. The hours either come back this month or the automation is not finished. | At the first reconciliation. Either the two sides agree or they do not. |
| Where the effort goes | Deciding what each page is for. The building is the short part. | Edge cases and the exceptions nobody documented. Never the happy path. | Agreeing which system owns each field, before a line of code is written. |
A service list is a poor place to be honest, which is exactly why it is worth doing here. Four situations come up often enough to name, and in each of them the correct recommendation is to spend nothing.
The volume is too low to matter. Automation earns its keep on repetition. A task done twice a year, however tedious, is cheaper to keep doing by hand than to build, document, test and maintain — and the maintenance is the part people forget when they compare the two. The threshold is lower than most people expect, but it is not zero.
The process is the problem. If a step exists only because of an old decision nobody has revisited, automating it preserves that decision permanently and adds a system to look after. Sometimes the deliverable from an audit is a paragraph explaining which step to delete, and there is nothing to build afterwards.
The organisation is about to change underneath it. A business mid-way through changing what it sells, replacing its ERP, or restructuring who does what is not a good candidate for anything built on top of the current shape. Waiting six months is often the cheapest advice available.
Nobody internally will own it. Everything on this page ends up as something a team has to run. If there is no one who will look at the log when a run fails, or update the page when the offering changes, it will decay — and a decayed automation is worse than the manual process it replaced, because people stop checking it.
The same four steps regardless of which pillar the work sits in, because the risk in every one of them is the same: building the wrong thing confidently.
It starts with a free process audit. That is a written review of where the time and the errors are actually going, and the deliverable is an opportunity map that you keep whether or not any work follows. It is genuinely free and it is genuinely yours — the reason it is offered is that the alternative is quoting on a description of a problem rather than on the problem.
From there, one piece of work is scoped and priced as a fixed number against a written scope. Delivery runs against a real environment early rather than a demonstration, because the surprises in this kind of work live in the data rather than in the design. Where anything touches a live ledger, the old process and the new one run in parallel until they agree — for a fortnight at minimum, and longer where the numbers are month-end sensitive. Nothing is cut over on the strength of a successful test run.
Handover is documentation plus credentials plus the code. Andrew does the work personally; there is no team to be passed down through, which is a genuine constraint on how much can run at once and is worth knowing before you start. The approach section on the homepage is the short version of all of this, and the field service case study is what it looks like carried through end to end.
Not sure which of the five you need? Describe the symptom and the audit will tell you — including when the answer is that nothing needs building.
Book a free process auditNo, and almost nobody does. A normal engagement is one pillar, occasionally two where they genuinely overlap — a rebuild whose enquiry form needs to reach a CRM, or an integration that turns out to need a small application at one end. If you are being told you need a co-ordinated programme across five areas, that is usually a retainer being sold rather than a problem being solved.
Work is quoted as a fixed price against a written scope, so the number comes before the work rather than after it. There is no published rate card, because the honest range across these nine offerings is wide enough that a number on a page would be misleading in both directions. The free process audit exists to produce a real figure: it establishes what the work actually is, and the quote follows from that.
No. XBA holds no reseller agreement, referral commission or partner status with any vendor named on this site. That is a deliberate position rather than an oversight: it means a recommendation to keep your current system, or to not build something, costs XBA nothing to give. Where an engagement touches a product you license through somebody else — an Accredo partner, for instance — that work sits alongside theirs and co-ordinating directly with them is normal.
Yes. Four of the five pillars are product-independent, and presence, AI, automation and integration work sits on whatever a business already runs — Xero, MYOB, Microsoft 365, HubSpot, or a spreadsheet somebody has kept alive for a decade. Accredo Saturn is the deepest specialty on the list and the one with the longest history behind it, but it is one pillar of five rather than a prerequisite for the others.
It depends heavily on the pillar, and any single answer here would be a guess dressed as a commitment. What is consistent is the shape: the audit is written within days, the scope and the fixed price come before anything is built, and anything touching a live ledger runs in parallel with the existing process for at least a fortnight before it is trusted. That parallel-running period is not padding and it is not negotiable — it is the step that catches the problems a test environment cannot.
