Faster, or Different?

There are two ways to bring AI into a workflow: make the existing process faster, or change the process itself. Both can be the right move. The harder part is knowing which one a situation actually needs.

AI summarizes documents, drafts replies, classifies requests, and retrieves information faster. Used this way, it makes the existing process quicker while leaving it intact, and that creates real gains. The alternative is to step back and change how the work arrives and gets handled in the first place. One is not automatically better than the other. They suit different situations, and they come with different amounts of effort and change.

Incoming customer requests

To make the difference between optimizing and redesigning concrete, let's use a workflow almost every company knows: incoming customer requests.

Requests arrive from various sources: customers, brokers, partners, suppliers, and internal teams. They also arrive in many shapes. Some are clear and complete. Many are not. A single message can require someone to read it, understand the intent, classify it, check internal systems, ask follow-up questions, draft a reply, and update the relevant tools.

This is where the cost builds up. It is not only the time spent answering requests. It is also the time spent turning unclear or incomplete messages into something the company can actually act on. Before the real work can begin, employees often first have to figure out what is being asked and what information is missing.

For this reason, it helps to separate incoming requests into two types: simple and complex. The dividing line is human judgment: complex requests still need it, simple ones do not.

Simple requests are the ones that can be answered from information the company already has:

• "Which documents do I need to submit?"
• "How long does this process usually take?"
• "What is the status of my request?"

Complex requests are the ones that need context, documents, interpretation, or someone to take responsibility:

• "My employer terminated my contract during my sick leave. Am I covered, and what should I do next?"
• "My basement flooded after heavy rain. Is it covered by my building insurance, and what do you need from me?"
• "My income has dropped and I want to restructure my mortgage. What are my options?"

That difference is what makes the choice of approach matter. There are two ways to handle these requests with AI: optimize the existing process via the inbox, or redesign the intake. For simple requests, both work well. For complex ones, they lead to noticeably different results, so the choice is worth getting right.

Let's start with the more familiar move: making the existing inbox faster.

Optimize the inbox

In this model the process largely remains the same: the customer still sends an email, and the request still lands in the same inbox or ticketing system. What changes is what happens next: AI works alongside the employee on every message that arrives.

When a message comes in, the assistant reads it, classifies what it is about, and pulls the relevant context from the systems behind it: the knowledge base, customer data, and business policies. From there, the two request types split.

For a simple request, where the answer is already known, the assistant can draft a complete reply or send one directly, so the customer gets a response in seconds rather than having to wait.

For a complex request, the assistant does the preparation, not the decision. It summarizes the case, checks whether any required documents or details are missing, and hands the employee a clean summary instead of a raw email. The employee reviews, decides, and replies, now with most of the groundwork already done.

The appeal here is that it fits the way people already work. Employees stay in their familiar inbox, the customer journey is untouched, and there is little process change to manage, which usually makes this approach faster and cheaper to put in place. The gain is concrete: less time spent reading, searching, classifying, and drafting on every message.

What it does not change is how requests arrive. The company still receives unstructured emails, and an incomplete request is still incomplete when it lands. Optimizing the inbox makes handling those messages faster; it leaves the shape of the incoming request as it is.

Let's now see how this differs in the redesign approach.

Redesign the intake

In this model, AI is not only used after an email has already arrived. Instead, AI becomes the first point of interaction. This changes the customer communication from an asynchronous email exchange into a conversation that happens in the moment.

The customer no longer has to formulate a complete request upfront and wait for a response. The AI assistant can react immediately, understand what the customer is trying to achieve, and continue the interaction accordingly. Simple requests can often be resolved directly. More complex requests are not necessarily solved automatically, but the assistant can guide the customer through the required steps, ask further questions, collect missing information, and create a structured case for an employee.

The appeal here is that the request is shaped before it becomes internal work. Customers are guided to provide the right information the first time, fewer cases arrive missing a document or a key detail, and employees spend less time chasing what is incomplete. Simple questions are taken off the queue entirely.

What this approach asks for in return is more change. The point of contact itself moves: customers interact through a chat rather than an unstructured email, and that shift in the customer journey takes more to design, integrate, and roll out than supporting the existing inbox does.

How the two approaches compare

How to decide which approach fits

The right choice depends on the situation, not on which approach sounds more advanced. A few questions usually settle it.

Where is the bottleneck? If the slow part is internal handling — employees reading messages, searching the same systems, drafting similar replies, and routing cases — then the inbox approach targets exactly that. If the slow part starts earlier, before an employee can even begin, because requests arrive incomplete, unclear, or missing documents, then improving the intake addresses the real constraint. An insurer that receives claims by email, where customers often forget documents or describe the incident vaguely and several rounds of back and forth follow, has an intake quality problem. A brokerage that sends complete, consistent requests where only volume and turnaround are an issue has a handling speed problem.

Would the request benefit from a conversation? Some requests are hard to get right in a single message, because the next question depends on the last answer. With "my basement flooded, what should I do?" or "my employer terminated my contract, am I covered?", the customer often does not know upfront which facts matter, and a guided conversation can lead them step by step. When a request is complete on its own and the customer already knows what to provide, a single message handled well in the inbox is enough.

Are the request types predictable enough to guide? Guiding a customer means knowing the common shapes a request takes: a damage claim, a contract cancellation, an address change, a document submission, a mortgage change. When those patterns are known, an intake flow can ask the right questions for each. When requests are too varied or unusual to anticipate, there is less to guide, and supporting the existing inbox is the more practical place to start.

How much change can you take on right now? The inbox approach fits into tools people already use, so it is usually quicker and cheaper to introduce. Redesigning the intake moves the point of contact, since customers interact through a chat instead of email. That can deliver more, but it asks the organization to change how requests reach it. Readiness for that change takes real effort.

None of these are permanent choices. One common path is to start with the inbox approach for a quick reduction in workload, watch which request types recur and where they break down, and use that evidence to decide whether a guided intake is worth building for the cases that come up most often. A company that already knows its request patterns and is ready to change its front door may go straight to the intake redesign. The point is to match the move to the situation rather than to a default.

How we approach this at Voviva

At Voviva we build both, from straightforward inbox assistants to fully custom guided intake systems. Having built both is what lets us say which one fits a given case. So before writing any code, we look at where the process actually slows down, because the aim is to build something that addresses the actual problem, not something that looks good in a demo. The system we deliver should match the problem in front of it.

The takeaway

We used incoming customer requests to make this concrete, but the underlying question travels. Almost any workflow faces the same fork: it can be made faster, or it can be reshaped. That holds for document processing, claims handling, internal approvals, and reporting, and in each case the better choice is rarely obvious from the outside. Asking the question is how you avoid the two easy mistakes: redesigning something that only needed to be faster, and speeding up something that should have been rethought.

If you want to put one of these approaches into production, that is what we do. Tell us about your process and we will help you land on the version that fits, then build it.