Short answer
Your first internal AI tool should be a saved custom assistant that does one narrow job, built inside an AI product your team already uses: written instructions, two or three reference files, and a fixed input and output format. Test it on 10 real cases, share it with a few colleagues, and give it an owner and a review date. No code or app builder is needed to start.
- One narrow job, with text in and text out, makes the best first tool.
- Fixed output formats make results easy to check and compare.
- Reference files teach your shorthand and tone better than long instructions.
- Sharing a tool can share its attached files; check before you share.
- Keep instructions and test cases in your own document, because features get renamed.
Goal: Build a saved AI assistant that does one narrow job reliably, test it on 10 real cases, and share it with colleagues safely. Who it is for: Team leads, office managers and operations staff who keep pasting the same long prompt and want a tool the whole team can use. Time: 60 minutes, plus three examples of the job done well and a business account in an AI tool that supports saved assistants.
Every team has a person who writes the good version: the job summary customers understand, the supplier email that gets a reply, the meeting notes people actually act on. A first internal AI tool captures how that person does one job, so others get a decent first draft in their style. It is not an app and does not need an app builder. It is a set of instructions, a few reference files, and a test you can rerun.
What a first internal AI tool looks like
A first internal AI tool is a saved custom assistant with five parts. As of October 2026 the feature goes by different names: OpenAI lists GPTs and Projects among ChatGPT Business features, Claude has Projects, Microsoft offers agents through Copilot Studio, and Google began replacing Gems with skills in Gemini on 30 September 2026, according to its release notes.
| Part | What it contains | Common mistake |
|---|---|---|
| Job | One task, one kind of input, one kind of output | “Helps with admin” |
| Instructions | Role, input, output format, rules, what to do when unsure | A page of vague tone advice |
| Reference files | Shorthand list, two or three good examples, standard wording | Attaching the whole shared drive |
| Test set | 10 real cases with what good looks like | Trying it twice and calling it done |
| Label | Purpose, limits, owner, review date, version | Nobody knows who maintains it |
Exercise: build a job-notes-to-customer-summary tool
- Pick one job and one owner. Choose a frequent text-in, text-out task where a person checks the result. Name the person who will maintain the tool.
- Collect three good examples. Ask your best writer for three real outputs they are proud of, with the inputs that produced them. Remove customer names and addresses.
- Write the instructions. Cover role, input, a fixed output format, rules and what to do when unsure. Adapt the worked example below.
- Attach two or three reference files. A shorthand list, the good examples and any standard wording. Nothing confidential, because people you share with may be able to see them.
- Test on 10 real cases. Use de-identified recent inputs. Mark each pass or fail with a reason, fix the instructions or files, and rerun the failures.
- Share deliberately. Share with two or three colleagues inside your business workspace. Check whether they can see the files or edit the instructions.
- Write the label. One paragraph in the tool’s description: what it is for, what it is not for, the owner, the review date and a version number.
Worked example: a plumbing firm’s job summaries
Illustrative example: a 9-person Whanganui plumbing and gas business whose technicians write shorthand notes in their job management system. The business and notes are fictional.
ROLE: You turn a technician's job notes into a short, clear summary
for the customer. A staff member checks every summary before sending.
INPUT: job notes pasted by staff, usually in shorthand.
OUTPUT, always in this format:
What we found: one or two sentences
What we did: bullet points
What we recommend: bullet points, or "Nothing further at this stage"
Follow-up: only if the notes mention one
Note for staff: anything you were unsure about
RULES
- Use only the notes. Never add prices, times, parts or warranties
that are not in them.
- Expand shorthand using the attached "Shorthand list". If a term is
not on it, write [check: term] instead of guessing.
- Gas and electrical safety: repeat what the notes say. Never add
safety advice of your own.
- Plain New Zealand English, no jargon, under 150 words.
Test input: “HWC 180L elec. TPR valve weeping, replaced TPR. PRV checked ok. Cyl approx 14 yrs, some corrosion at base, recommend replace within 12 mths. Cust aware. No charge for callout per Dave.”
Example output (illustrative, abridged):
What we found: The temperature and pressure relief valve on your
180-litre electric hot water cylinder was leaking.
What we did:
- Replaced the relief valve.
- Checked the pressure reducing valve; it is working correctly.
What we recommend:
- Your cylinder is about 14 years old with some corrosion at the base.
We recommend replacing it within the next 12 months.
Note for staff: the notes say "no charge for callout per Dave".
Confirm before mentioning it to the customer.
The useful behaviour is in the last line. The tool did not decide whether to tell the customer about a pricing concession; it handed that to a person.
Where first internal tools go wrong
- Files shared by accident. Sharing an assistant can expose its attached files. Attach only what every user may read.
- Stale reference files. Standard wording changes and the tool keeps using the old version. The owner and review date are the control.
- Scope creep. A summary tool starts being used for quotes or complaint replies. Write what it is not for in the label, and build a separate tool if the need is real.
- Treated as policy. “The tool said so” is not a reason. Keep a person reviewing every customer-facing output.
- Living in someone’s personal account. When that person leaves, the tool goes too. Build in a business workspace.
- Renamed features. Products migrate and retire features. Keep your instructions and test set in a document you control.
The instructions above are a structured prompt; building a reusable prompt library covers how to store and version them. If your job notes live in ServiceM8 or Simpro, those guides explain how tools can later read notes directly instead of relying on copy and paste, and our quote preparation from job notes workflow shows a related build. When a saved assistant is no longer enough, try building a no code AI prototype, or talk to our custom AI development team about a version connected to your systems.
Self-check
- The tool does one named job with a fixed output format.
- Instructions say what to do when the input is unclear.
- Reference files contain nothing that every user should not see.
- Ten real, de-identified cases were tested and failures fixed.
- Sharing is limited to your business workspace and checked for file access.
- The label states purpose, limits, owner, review date and version.
- Instructions and test cases are saved in a document you control.
Next lesson: Testing a business AI assistant.
Sources
- Gemini Apps release updates and improvements, Google, 30 September 2026
- ChatGPT Business: Overview, OpenAI, as listed 19 October 2026
Written by the Levy Street team in Wellington. Last updated 19 October 2026.