ServiceNow Flow starts when someone asks

ServiceNow has reached a conclusion I agree with: work starts in conversations, and once someone handles a straightforward request, nobody should have to handle a similar one by hand again. On October 1 it announced Flow, which it calls “a new conversational AI-native service desk” and runs as “a startup within ServiceNow”. Its premise is that employees “expect help in the conversations they’re already having”, rather than in a portal or a ticketing system.

Snowflake and Databricks came to a version of this conclusion from the warehouse, and Google concluded the same thing for Gmail and Docs. I wrote about them in The context your warehouse can’t reach and Google’s company memory is personal. ServiceNow reached the same conclusion about the service desk.

What ServiceNow built

Flow works inside Slack and Microsoft Teams. An employee asks for something in chat, and according to ServiceNow, Flow “doesn’t just answer repetitive requests. It closes them or automatically escalates if needed.”

Then it learns from the answer. “When users resolve a request correctly, they can automate that workflow with a single click,” and the next time the same issue comes up, Flow handles it automatically. ServiceNow’s own summary is “No knowledge base articles needed.”

ServiceNow says Flow can be “up and running in a day, with no implementation project and no infrastructure required”, and that it “integrates into any existing knowledge, assets, ticketing, and AI usage”, with the ServiceNow platform behind it for auditability and governance. New customers can buy it as a standalone product. ServiceNow customers already licensed for its AI products can use it through consumption-based pricing, at no additional procurement cost. Early access is open at letsflow.ai, and ServiceNow expects general availability in North America and EMEA in Q4 2026.

Keith Kirkpatrick at the Futurum Group calls it a calculated bet that the next wave of buyers of IT service management software will refuse implementations that take months, and names BMC, Ivanti, Freshworks and Atlassian as the competition. Flow is built for the internal service desk: answering employees quickly in the chat tools they already use.

A service desk sees requests

Flow’s loop, as ServiceNow describes it, starts with an employee asking for something in chat.

But internal requests differ from external ones. A lot of what a company has to act on doesn’t arrive as a structured request or ticket or even a short, clear message. It often arrives from outside, in an email or a thread.

Imagine a customer’s controller replies to last month’s invoice. She’s moving to a new role, and Priya on her team will handle accounts payable from now on, so invoices should go to her. The account manager reads it and means to pass that information on, but gets pulled into a renewal call. Next month’s invoice goes to the controller, who has moved on, and it goes unpaid. Six weeks later someone in finance asks in Slack why the customer hasn’t paid. That’s the first request anyone makes. Nobody filed one when the controller wrote, so nothing about it reached a service desk. The answer is buried in an email to the account manager.

The same goes for a commitment made in a reply-all, a vendor’s invoice sent to whoever placed the order, and a partner mentioning a reorg in passing. Each one is already written down in a message, but it stays in somebody’s inbox until someone remembers to copy it into a ticket, the task list, the address book or the knowledge base.

What Flow learns from a resolved request is how to resolve the next one like it. What the controller’s email contains is a fact about a customer, and it changes what several people should do next.

Starting from the message

A service desk handles what people send to it. The controller’s email went to a person, so a system that catches it has to read the inboxes and chats your team has connected, where messages are addressed to people rather than to a desk, and decide whether anything in each needs doing or needs remembering. Here, two things should happen: Priya should be in the address book as the customer’s accounts payable contact, and someone in finance should have a task to change where invoices go.

Flow’s loop applies here too. The first time a customer changes who gets their invoices, a person handles it. After that, a workflow can recognize the next message like it and route it to finance for approval.

That’s what we build at this+that. Our product reads every message the moment it arrives, in whichever of Gmail, Outlook, Slack, Microsoft Teams, and Google Chat you connect. DoBox turns what needs doing in a message into a task, whether or not anyone asked, and routes it to a workflow or a person. Contacts builds the address book from the channels you’ve connected and keeps people’s details current from their messages. The brain holds what the company knows, and workflows write back to it as they run, with a person approving or editing each update. Workflows act on all three. We’re building toward a brain that keeps most of itself current from the message stream through one maintenance workflow, but that part isn’t finished.