Partnering with TeamBlueSky provides your business with award-winning expertise and industry recognition through strategic alliances and professional collaboration
Choosing a NetSuite partner is one of the more consequential decisions a business makes and one of the hardest to judge in advance. Every partner presents well, every capability statement says broadly the same things, and every reference has been chosen because they will say something positive. The differences show up eighteen months later, in whether the system still fits the business and whether anybody can explain why it was built the way it was.
This article sets out how we work and why, so you can decide whether it matches what your business needs. It is not a claim that our approach is the only good one, because it plainly is not. It is an honest description of what we do differently and where those differences actually matter.
We are an Australian business working with Australian businesses, and in this domain that is more consequential than it is in most.
Payroll is the clearest example. Modern award interpretation, Single Touch Payroll Phase 2 reporting with disaggregated gross, superannuation guarantee obligations calculated on ordinary time earnings, long service leave that varies by state, and payroll tax with different thresholds and grouping provisions in each jurisdiction. None of these are configuration options in a globally designed product. They are domain knowledge, accumulated over years of dealing with the edge cases.
The same applies to statutory reporting, to Australian accounting standards, and to the practical realities of how local businesses operate. A partner learning these during your project is learning at your expense, and the cost usually appears as rework rather than as a line on an invoice.
Practically it also means same timezone. Design conversations happen in real time rather than across a twelve hour gap, and support arrives on the day you asked rather than the next. That sounds minor until you are three weeks from go live with a question that blocks a decision.
The most expensive implementation failure is not one that breaks. It is one that works and does not fit, because that is not obviously broken and it constrains the business quietly for years.
Avoiding it means understanding why a process works the way it does before deciding whether to preserve it. Sometimes the answer is that it exists because a previous system could not do better, and it should change. Sometimes it is a genuine source of advantage that nobody has ever articulated, and it should be protected carefully.
You cannot tell which without asking, and asking properly takes time that a partner working to a fixed template does not spend. It also requires being willing to hear an answer that complicates the plan.
The visible consequence is that our design phase involves more conversation and fewer assumptions. The configuration decisions end up with reasons attached to them, and those reasons survive the project, which matters enormously when somebody asks about them in year four.
NetSuite partners come in different structural forms and the differences affect the relationship in ways that are worth understanding before you weigh anybody's advice.
As an alliance partner, our business is implementation and ongoing services rather than reselling licences. The commercial relationship for the software itself sits between you and Oracle NetSuite, and we are not in it.
That has a practical effect on advice. A partner whose margin depends on licence volume has an interest in what you buy. A partner whose business is delivery has an interest in what you actually use, because the things you use are the things you will call about.
It is not a claim that solution providers give bad advice, and many are excellent. It is a structural difference worth understanding when you are weighing a recommendation about scope or modules. Our piece on solution providers and alliance partners sets out the distinction properly.
Implementation partners who disappear at go live leave the business at exactly the point where the real problems appear, which is the first month end rather than the cutover weekend.
We work across the full span. Advisory before the decision is made, implementation, training, ongoing support, managed services, and the outsourced processing for businesses that would rather have the transactional work handled than the system built.
The benefit is continuity of knowledge. The people answering your questions in year three know why the system was built the way it was, because they were in the room when it was decided. They know which configuration choices were deliberate and which were compromises.
The alternative, which is common, is support from people reading your configuration for the first time on each ticket. The difference in the quality and speed of the answer is substantial, and it compounds over the life of the system.
This is unusual among implementation partners and it matters more than it sounds when you look at what it produces.
Because we process payroll for clients as an ongoing service, we deal with award interpretation, legislative change and the genuinely awkward edge cases continuously rather than only at implementation time. The annual wage review is something we work through every year, not something we read about.
That knowledge flows directly back into how we configure payroll for implementation clients, because we know which pay code decisions cause Single Touch Payroll problems eighteen months later, and which leave accrual configurations produce errors that only surface at termination.
It also means that if what you actually want is the processing handled rather than the system built, that is available from the same relationship without introducing a third party. Our payroll and bookkeeping service covers both.
Every customisation is a permanent obligation. Somebody maintains it, somebody tests it against two releases a year, and eventually somebody tries to work out what it does without the person who built it being available to ask.
We push back on customisation requests, which is occasionally unwelcome in the moment and consistently correct over the life of the system. The conversation is usually about what problem the request is actually solving, because the stated requirement is frequently a solution somebody has already designed.
The order of preference is configuration first, then workflow, then a third party application built natively for the platform, and only then code. Most requests resolve well before reaching the last step, and the ones that reach it are genuinely worth building.
The result is a system that upgrades without drama and that a new administrator can understand, which is what actually determines your cost of ownership over a decade.
A partner benefits commercially from a client who cannot do anything without them. We think that is a poor way to run a business relationship and a worse way to run a system.
During implementation we build internal capability deliberately, through shadowing, documentation and a defined handover, so that somebody in your business genuinely understands the configuration rather than merely having access to it.
That person does not need to be technical. They need to be able to make routine changes safely, build a saved search, adjust a workflow, and judge when a request genuinely needs outside help rather than defaulting to raising a ticket.
Where that capability exists, small improvements happen in days rather than being batched into a quarterly engagement, and the business stops experiencing the system as fixed. Our guidance for system administrators covers what the role actually involves.
Training is the first thing cut when a project runs late and the thing whose absence most reliably determines whether the implementation delivers what it promised.
We scope it separately with its own budget and its own dates, so that it does not quietly absorb the slippage from everything upstream. Where training sits as a line inside the project, it always ends up compressed into the final fortnight.
We build it around processes rather than modules, because a person does not do accounts payable. They receive supplier invoices, match them, resolve the ones that do not match, and prepare a payment run, and that path crosses several parts of the system.
And we schedule it against first use rather than against go live, so that month end training happens in the week before the first month end rather than three weeks earlier when it will be forgotten. Our training service is built as an ongoing arrangement rather than a one off delivery.
Implementation timelines are frequently quoted optimistically, because optimistic timelines win work and the consequences arrive months later when the decision is already made.
We are direct about the parts that are usually underestimated. Data migration takes longer than the system configuration, consistently and by a wide margin. The internal time required from your team is substantial and has to be protected rather than found. And the design decisions that look administrative, particularly the dimensional structure, are usually the ones that matter most.
We would rather have an uncomfortable conversation at the proposal stage than a considerably worse one at week fourteen when the date is already public.
That occasionally costs us an engagement to somebody quoting a shorter number, and the projects we do run are considerably more likely to land where they were supposed to.
A meaningful proportion of our work is with businesses whose NetSuite is live and not working, and that experience shapes how we run new projects more than anything else does.
The failure patterns are consistent. Configuration that does not match the business, because nobody asked enough questions during design. Customisation that nobody can maintain and nobody can explain. Training that never happened properly. And a dimensional structure that makes the reporting the business actually needs impossible without a rebuild.
Having spent time inside those systems, we know which decisions cause them, which is why we spend disproportionate effort on design and on the dimensional model rather than on getting to the build phase quickly.
Our implementation rescue service exists for businesses in that position, and it is a genuinely different discipline from a fresh implementation because you are working around decisions you did not make.
Industry experience matters more in some sectors than others, and it is worth being specific about where rather than claiming everything.
Wholesale and distribution brings landed cost, consignment arrangements and rebate structures that complicate margin reporting in ways that are easy to get wrong and expensive to correct later.
Manufacturing brings work orders, bills of material and the perennial question of how far to take costing before the effort exceeds the value.
Professional services brings project costing, utilisation and revenue recognition, where the difficulty is usually capturing labour cost properly rather than the accounting treatment.
Not for profit and member organisations bring fund accounting, grant tracking and a reporting audience whose questions are not commercial. Where we have depth we say so, and where we do not we say that too, because a partner learning your industry at your expense is a poor arrangement. Our services and industry pages set out where we work.
Commercial structure affects behaviour, so it is worth being clear about ours rather than leaving it to be discovered.
We scope properly before quoting, which takes longer at the front end and produces a number that holds. A quote produced without understanding the data or the process complexity is a guess, and guesses become variations.
We are explicit about what is included and what would be a variation, because ambiguity there produces exactly the arguments that damage otherwise good relationships, usually at the point where both parties are already under pressure.
And our ongoing arrangements are structured so that asking a question does not feel expensive. A client who has stopped asking questions is a client whose system is quietly drifting, and that is bad for them and eventually bad for us.
Being clear about the limits is more useful than another list of strengths, and it saves both parties a conversation that was never going to work.
We are not the cheapest option. Businesses selecting purely on price will find lower numbers, and some of those will be perfectly adequate for a straightforward requirement.
We are not a large global firm, so a multinational implementation across many jurisdictions with local statutory requirements in each is not our natural territory.
We are not a software vendor, so we will tell you when NetSuite is not the right answer for your business. That happens occasionally and it is better said early.
And we do not take on work we cannot do well, which sometimes means a referral rather than a proposal. That is a commercial cost we accept because the alternative is worse for everybody.
People are often unsure what a first conversation with a partner should cover, and the answer is that it should be mostly us listening.
We want to understand what is not working now, what you have already tried, and what you want to be true in two years. Those three answers shape everything that follows and they are considerably more useful than a feature discussion.
We will also ask some awkward questions early. Who owns this internally, how much of their time is genuinely available, what happened last time you changed a major system, and what would make this project fail.
You should expect to leave that conversation with a clearer view of the problem, whether or not you engage us. If a first conversation is mostly a demonstration, that tells you something about how the engagement would run.
The right way to judge any partner is to ask the questions that reveal how they work rather than what they claim. What would you expect to be hardest about our project. How much of our people's time will this take. What do your projects that go badly have in common. What would you tell us not to do.
Partners with real experience answer those readily and specifically, and the answers tell you considerably more than any capability statement will. Partners who claim every project has gone well have either not done many or are not being straight with you.
Our pieces on our implementation process and working with a NetSuite partner cover the practical detail of how an engagement runs.
If you would like to talk about your own project, get in touch.
