AI assistants, invoice readers and WhatsApp enquiry handlers for the questions, documents and messages your staff still deal with by hand

It depends on the work. AI suits tasks that involve language, judgement or messy documents, such as answering varied customer questions, reading bills that arrive in many formats or sorting complaints by urgency. If a process is a fixed rule that always gives the same outcome, a rules-based workflow or a plain integration is simpler to build and easier to audit. The assessment makes that call. It happens before any spend on a model.

It uses only the data the client approves. Documents and records go into a retrieval store held in the client’s own cloud account, or in infrastructure we run, under access controls the client defines. An NDA is signed before discovery begins. Personal data is redacted where the task does not need it, and the provider that processes each item is documented in writing. Where data must stay on the client’s own servers, self-hosted open models can replace hosted ones, though cost and capability change. The trade-off is explained before anyone decides.

Yes. This is the default design. The assistant is restricted to a defined set of documents and records, each with an agreed current version and a named owner. When a question falls outside that set, it says it has no answer and offers to connect the person to the team. Topics that must be refused, such as clinical advice, legal opinions and pricing exceptions, are blocked by explicit rule, and the block is tested.

Accuracy is measured against an evaluation set built from real questions and documents, with correct answers agreed by the client’s own team. The assistant is scored against it before go-live and again after each significant change, with the failures shown beside the successes. No assistant is right every time. The design therefore covers what happens when it is wrong: low-confidence responses hand over to a person and risky categories never answer alone. Every reply carries its source. The conversation log is mined for weak areas.

Yes. For anything that commits the business, review by a person is part of the design, and the client sets the line. Some let the assistant answer routine questions, sending only pricing and refunds for approval, while others start with every outgoing message reviewed by an agent and relax that later. Draft-and-review is a normal mode, where the assistant prepares the reply with the relevant record attached and an agent presses send.

Yes. Any system with an API, database access or a scheduled export can be connected, and that covers most accounting and ERP software in use. Common starting points are QuickBooks, Xero, Zoho, SAP Business One, custom ERPs, SQL databases and helpdesk tools such as Freshdesk and Zendesk. The assistant can then look up a live order, consignment or invoice status and write captured enquiries back as proper records. A closed or very old system can still be reached through file exchange or a database bridge, and assessment confirms what is possible.

No. Such material is expected and planned for. Typical cases include a current rate list sitting in one person’s mailbox, several versions of the same SOP in a shared drive, and policies that were never written down. During knowledge preparation the existing material is collected, duplicates and superseded versions are identified, and one owner confirms what is current. The one real blocker is knowledge never written down. It must be created first. That effort can be scoped separately.

Cost and timeline depend on the scope. The main factors are the number and complexity of tasks, the condition of the documents and data, and the channels, connected systems and amount of human review involved. Hosted or self-hosted models change the price too. Timeline depends on how quickly document owners confirm approved versions and how quickly reviewers clear the evaluation results, which is usually the slower part. A single-task assistant on one clean knowledge base is a smaller job than a multi-channel assistant wired into three systems. An itemised proposal follows assessment.

There are three parts. Model usage is billed by volume, such as messages answered or pages read, so the bill rises with adoption. Hosting and storage are a steadier monthly item. Support covers monitoring, content refreshes and accuracy re-testing. During assessment the expected monthly volume is estimated from actual enquiry and document counts, and usage caps and alerts keep spend within an agreed limit. Where volume is high or data must stay in-house, self-hosted models move the cost from per-use to fixed infrastructure, which suits steady heavy use. Crossover is worked out on the client’s own numbers.

Yes. The client receives the full source code repository, the prompts and configuration, the retrieval setup and the evaluation sets, with intellectual property ownership. Cloud and model provider accounts are created in the client’s name and billed to the client, so ownership is never in doubt. Changing vendor or model needs no permission from GullySystem.

Four things are needed. One decision-maker who can approve scope and settle disagreements. Access to the people who do the work. The real material, including documents, past chats and sample bills, with the messy examples as well as the clean ones. Last, two or three reviewers. Delays usually come from unavailable owners or reviewers. The technology is rarely the cause.

Yes. Training covers what the assistant is reliable at, what it must not be trusted with, how to read a cited source and how to take over a conversation. Training is short sessions. The team keeps plain-language guides for new joiners. After launch there is a warranty period. Optional support follows, covering conversation monitoring, correction of weak areas, content updates when documents change, re-testing when a model version changes, and cost and usage reporting.

For a first set of questions, yes. Testing an off-the-shelf tool is worthwhile before paying for a custom build, since a generic chatbot can answer FAQs from an uploaded document. It falls short once the assistant needs the business’s own records, such as a live order status, an outstanding balance or a specific policy exception. It cannot read CRM, ERP or accounting data. It cannot be limited to approved answers. It cannot enforce escalation rules either. If the tool answers what customers ask, it stays. If it keeps improvising, a build around the business’s own data is the next step.