Give Your AI a Job Description
If you hired someone to help with customer enquiries, you would explain their responsibilities, show them the relevant systems, and agree when they should ask for help. An AI agent needs the same clarity about its work.
Digg’s AI coverage recently surfaced a discussion about thinking of AI as a coworker. For an SME, that idea has a useful practical consequence: write a job description before connecting AI to your operations.
The analogy has limits. An AI system does not take responsibility for an incorrect quote or a missed customer request. Your business does. But defining its role helps turn an impressive demonstration into a workflow that a small team can supervise and improve.
Choose a Job You Can Describe in One Sentence
“Help us with sales” leaves too much unresolved. A better brief is: “Prepare a draft response to each new service enquiry, using our approved service information, and flag anything that needs a person’s decision.”
That sentence gives you a starting point for implementation. It identifies a trigger, an output, a source of information, and a handover.
Consider a small maintenance company receiving enquiries through a shared inbox. Staff read each message, check whether the business covers the location, identify missing details, and prepare a reply. This is an illustrative example, not a Reliq client case study.
An AI workflow could prepare that first pass. It should not invent availability, promise a price, or confirm a booking. Those are separate responsibilities with different consequences.
Write the Operating Brief
For this enquiry assistant, the job description could fit on one page:
- Purpose: reduce the effort needed to prepare a correct first response.
- Inputs: the incoming enquiry, the approved service catalogue, and the coverage list.
- Output: a draft reply, extracted enquiry details, and a short explanation of any unresolved questions.
- Allowed actions: read the relevant information and save a draft for review.
- Approval required: sending a message, quoting a price, confirming availability, or changing a customer record.
- Escalation: complaints, conflicting information, unusual requests, and anything outside the approved services.
- Owner: the employee responsible for reviewing drafts and maintaining the service information.
These boundaries should be enforced in the integration. If the assistant only needs to create drafts, its connection should only permit that action. A written instruction to “never send” is weaker than withholding the ability to send.
Incoming emails also need to be treated as customer content. Instructions inside a message should not be allowed to change the assistant’s permissions or operating rules.
Make the Handover Useful
A polished draft is difficult to review if nobody can see what supports it. Give the reviewer the original enquiry, the relevant service information, and the details the assistant could not establish.
For example, the handover might say: “The postcode is within the coverage list. The customer has not supplied the equipment model. The draft asks for that detail and makes no availability commitment.”
This is more useful than a reassuring confidence score. The reviewer can check concrete evidence and resolve specific gaps.
Keep access narrow here too. An enquiry assistant may need a service catalogue; it does not automatically need the whole customer database. Decide which information the job requires before choosing how to connect it.
Test the Cases That Create Work
Start with a small, approved set of representative enquiries. Include incomplete messages, unsupported locations, multiple requests in one email, complaints, and contradictory details. Write down the expected handling before reviewing the AI’s output.
Run the assistant alongside the current process first. Record where staff correct it, where it misses an escalation, and whether reviewing its drafts takes longer than writing a reply themselves.
Repeated corrections are evidence about the workflow. They may point to unclear service information, a missing rule, or a task that should remain with a person. Changing the model is only one possible response.
Count Accepted Work
A generated reply is not yet a completed task. Measure the draft after someone has reviewed it.
Useful measures include review time per enquiry, the proportion of drafts accepted without substantial edits, missed escalations, and total operating cost. Compare them with the existing process, including the time spent fixing mistakes.
Suppose preparing a reply currently takes eight minutes. If AI preparation takes one minute and human review takes six, the saving is one minute. That is a hypothetical calculation, not a forecast. It shows why measuring generation speed alone can overstate the benefit.
Agree the conditions for expanding the pilot in advance. If quality falls or review effort rises, the team should be able to return to its normal inbox process immediately.
Expand the Role When the Evidence Supports It
Once draft preparation works reliably, the next step might be suggesting a service category or preparing a CRM update for approval. Each added responsibility needs its own boundaries and checks.
For SMEs, a useful first deployment is often a modest one: a clearly defined task, connected to the tools people already use, with an accountable owner and a visible result. That is a strong foundation for accelerating operations without creating another system the team has to babysit.
If you have a workflow that could benefit from this approach, talk to Reliq. We can help define the role, build the integration, and assess whether it earns its place in your business.