OpenAI Integration in New Zealand

Find out what your team is already doing

Before writing a brief, ask around. In most New Zealand businesses somebody is already using ChatGPT daily for something useful — rewriting quotes, summarising notes, drafting replies, making sense of a spreadsheet.

That habit is the best specification you will get. It tells you which task is genuinely worth automating, roughly how often it happens, and what good output looks like, because someone has been judging it by eye for months.

It may also tell you something uncomfortable: what has been pasted into a personal account. Worth knowing now rather than during an audit.

The API is not the subscription

These are different products with different terms, and people conflate them constantly.

ChatGPT is used by a person in a browser, priced per seat. Business and Enterprise plans exclude your conversations from training; the free and personal tiers historically did not.

The API is called by your software, billed by usage, and business traffic is excluded from training by default. This is what an integration uses.

Set the API account up in the company's name with company billing, not on a developer's personal card. Set a hard spend limit in the dashboard on day one — it takes a minute and prevents the only truly unpleasant surprise in this category.

Ask for cost per use, not a monthly guess

Pricing is per token, meaning per amount of text in and out. Most business features cost fractions of a cent to a few cents per use, so a few hundred dollars a month covers a lot.

Ask each developer for the cost of one use of the feature, and the figure at three times your expected volume. Then ask what they are doing about these, which are where bills escalate:

• Sending an entire document when only two pages are relevant.
• Resending a whole conversation history on every turn.
• Using the largest model for a task a small one handles perfectly.
• A retry loop that misbehaves at 3am.

Caching repeated context is standard and can cut the bill substantially on features that reuse the same background material. Ask whether it is being used.

Insist on structured output

Ask the model for prose and your software has to parse it, and that parsing breaks when the wording drifts. Structured outputs let you supply a schema and get a response that conforms to it or fails loudly.

That is the difference between a feature that degrades noisily and one that writes a plausible wrong value into your database. Ask whether structured outputs are being used; if the answer involves regular expressions, it tells you how the rest will be built.

Then validate anyway. The schema guarantees shape, not sense — your own rules still have to check that the invoice date is not in 2087.

Ask to see the evaluation set

Fifty to two hundred real examples from your business with the right answer recorded, scored before launch and after every change.

Without it nobody can tell whether last week's prompt change helped or quietly broke a category. This happens constantly: a tweak that fixes one supplier's invoices breaks another's, and nobody notices until a customer does.

The set costs mostly your team's time, because only they know the right answers. It is the first thing missing from a cheap quote and the best money in the project.

Working with your own documents is a bigger job

"Answer questions from our documents" sounds like one feature and is really two: find the right passages, then answer from only those.

Retrieval quality decides answer quality, and most disappointing results are retrieval failures rather than model failures — the model answered perfectly from the wrong three paragraphs.

What to insist on:

• Answers cite the source passage, so a reader can check.
• "I don't know" is an acceptable and expected output.
• Permissions are respected — someone must not be able to ask their way into a document they cannot open.
• There is a plan for keeping the index current as documents change.

Build so you can leave

Models change every few months, prices fall, and the best option for your task next year may be a different provider. That should be a configuration change.

Ask for the model and prompt in configuration rather than scattered through the code, a structured contract between your feature and the model, and an evaluation set that could prove a replacement is at least as good. None of that costs extra at build time and all of it is expensive to retrofit.

Comparing five quotes

Read for:

• Who asked what your team already does by hand?
• Who gave a cost per use and mentioned a spend limit?
• Who uses structured outputs and validates them?
• Who included an evaluation set?
• Who explained how you would move provider later?

Describe the task, how often it happens, what a wrong answer costs, and whether a person reviews the output. Developers who have shipped this will ask about evaluation before they ask about the model.