Existing software, automation or custom AI?

An email queue can contain several kinds of work. Someone reads a request, works out what the sender means, asks for missing information and copies the approved details into a business system. From a distance, it is one repetitive task. Up close, each step suggests a different way to reduce the effort.

Imagine a team handling that queue. A form might save the retyping. A rule could route a request once its department is known. AI might help interpret a long message whose relevant details are scattered through an attachment. This is a hypothetical example, but it gives the choice between buying and building a more useful starting point: the part of the job that still needs help.

We think that question should come before any comparison of products. The sections below take this queue through three options: the software the team already has, a fixed rule and a custom AI integration. They then describe a comparison that gives each option the same test. They do not rank products or recommend a vendor.

Difficult requests show which part of the work needs help

An incomplete request and a request that could go to two teams reveal more than a clean example. The person handling them has to make decisions before entering a record. Those decisions show what the software would need to do, or what a person would continue doing alongside it.

Perhaps the existing product already captures requests but cannot send the approved fields to their destination. The missing piece is a connection. Perhaps it routes requests perfectly once someone has interpreted the message. Then interpretation is the part worth investigating. Sometimes a setting is missing; sometimes the process itself leaves a decision unresolved.

If nobody knows who approves an exception, another system will inherit that ambiguity. We start from the current work for that reason: it helps distinguish a software limitation from a decision the organization has yet to make.

An advertised feature still has to work in your account

A request form and a connection to the destination may already be available in the team's software. Whether they are usable in this organization is a separate question. An advertised feature can depend on a different plan, an administrator's permission or a connector that has not been enabled.

We would evaluate the product in the actual account, using representative inputs, because that brings those conditions into view. The evaluation also shows how the product handles exceptions, which data it can reach, what can be exported and who handles changes or incidents.

Buying software can still leave configuration and integration work. Making that work explicit helps explain what a purchase would solve and what would remain for the team or an implementation partner.

Where a rule is enough, a model adds work to maintain

If a form asks the sender to choose a department, a rule can route the request there. Another rule can hold it until a required field is filled in. The reason for either decision is visible in the rule itself.

For that kind of step, adding a model introduces another behaviour to evaluate and maintain. Ordinary rules still need tests, permissions and failure handling, but their decision can be inspected directly. If a rule can handle the step, we would use it, because custom AI may add unnecessary cost.

Rules and AI can also work together. A model might read the email and propose a department, a person could check the choice, and ordinary code could route the approved request. Only the interpretation step would depend on the model.

Free-form inputs can justify a custom AI integration

Now imagine that the requests must continue arriving as free-form emails. One sender puts the service address in an attachment. Another describes two separate problems in the same message. If the existing software cannot turn those inputs into a usable record, a draft prepared by AI may be worth testing.

How would the team know whether that draft helps? The person who knows the work is central to that test. They can judge whether the draft is accurate and whether checking it is practical. A draft that takes too much effort to verify may offer little help, even if it looks convincing.

The design also depends on access to the systems, permission to use the data and someone who will operate the result. A tool that prepares a draft can have a smaller set of responsibilities than one that sends messages or changes records. If an agent chooses actions, its available tools and limits need enforcement outside its instructions. Human approval has to cover the action actually taken. Conditions for stopping or asking for help also belong in the agreed design.

A fair comparison uses the same sample requests

The same sample requests give each option a common test. We suggest asking these questions of each one, because they connect the result to the team's daily work:

• Can it handle the formats and exceptions you actually receive?
• Which mistakes can a reviewer correct, and which actions must the system prevent?
• Can it reach the right data under permissions you can approve?
• Who checks the output, and is there time to do that at the expected volume?
• What needs changing when your process or a provider's interface changes?
• Who will monitor it, fix failures and pay the continuing costs?

Answers to those questions may favour a modest change to an existing product, or they may establish a reason to build. If none of the options has an owner or an acceptable way to handle errors, we think continuing with the current process is a reasonable result. It gives the team time to resolve those gaps before committing to a wider change.

A short description makes unnecessary features easier to spot

For the email queue, a short description might be enough to establish the work: read requests from one mailbox, prepare a draft record, and send the fields to one destination after a reviewer approves them. Missing information goes back to the reviewer. A duplicate request must not create a second record, and a destination failure must leave the approved work available for recovery.

That description also makes unnecessary features easier to spot. Reading other mailboxes or making unrelated business decisions would add access and responsibility without helping this task. If a form and a routing rule meet the requirements, the proposed system can be smaller still.

Which of our engagements fits each starting point

We cannot choose between these options without seeing the work. The answer depends on the account, the requests and the exceptions a team actually has.

Where the usefulness of AI is still uncertain, our proof of concept investigates whether a use case works on the organization's data. Its prototype and evaluation inform the next decision; production requires a separate scope.

An AI integration connects one workflow across named systems. A production build takes a proven use case through to a deployed application. The five engagements cover those and other starting points, and the integration cost guide explains how the work around a model affects a quote.

A conversation about the task can establish whether a defined paid engagement would help. A non-sensitive description is enough to begin; confidential documents and credentials should stay out of email.