Three workflows. 20 tasks. A geography check missing from the map.
I want to tell you a story. We make labs for enterprise customers. A while back I sat down to map what actually happens between a customer's first call and a working lab on their users' screens. Three workflows. 20 separate tasks across our teams, the customer's IT team and cloud providers. Nine were missing from our job descriptions. A customer call also revealed a responsibility absent from all twenty: checking where users would access the labs.
You have probably heard this pitch
A services firm shows up with a deck. They want to automate one of your workflows. Twelve weeks. A bot. A dashboard.
The middle slide says "automate your hire-to-retire workflow" or "automate your AR workflow" or "automate your support workflow." The before-and-after picture looks clean. There is a price. There is a timeline.
A proposal needs to explain what happens to the cases outside that clean diagram. Who handles missing information? Who coordinates with customer IT? Where does a case go when the automation cannot finish it?
Our own delivery operation gave us a concrete reason to ask those questions. A workflow label concealed a missing task.
The three workflows in this delivery account
We use task intelligence with customers. I figured we should run it on ourselves first.
We build lab environments, practice projects and assessments for enterprise customers. Delivering them involves Sales, Sandbox, Learning Solutions, Support & Delivery and Engineering, as well as cloud providers and customer IT. We followed that work through HubSpot and Freshdesk tickets.
This account follows three workflows in that delivery operation.
- Lab Feasibility Review. Before any deal closes. Six tasks across Sales, Sandbox, and Learning Solutions.
- Lab Delivery. After the deal closes, until the lab is live. Eight tasks across Sales, Sandbox, Learning Solutions, Support & Delivery, and the cloud providers.
- Lab Support. Every day after the lab is live. Six tasks across Support, Sandbox, Learning Solutions, Engineering, and the customer's IT team.
Twenty tasks across our teams, the customer's IT team and cloud providers. 9 of the 20 tasks are hidden, meaning they do not appear in any job description we wrote. Missing these responsibilities can delay delivery or cause rework.
Here is the task list in order. The AI labels are proposed assignments for discussion, not evidence that agents have completed these tasks.
Workflow 1: Lab Feasibility Review
Before any deal closes. Six tasks. Three teams. Two of the tasks are hidden.
A customer asks Sales for a lab. From the outside it looks like one conversation. From the inside it is six tasks across three teams. One of those tasks is the most important decision in the whole flow, and it is not in any job description.
Lab Feasibility Review
Before any deal closesThe decision at task 2 is the one nobody talks about. The salesperson decides whether this is a Sandbox lab or a Learning Solutions lab. That decision picks the team that will scope the next two weeks. We discovered we even had a step like this only by tracing tickets backward.
Task 4 is the one I find funny. When Learning Solutions takes a lab that needs a sandbox underneath, Learning Solutions opens a fresh ticket back to Sandbox. The org chart says these are two parallel teams. The ticket trail says one of them is sometimes the customer of the other. There is no role name for that. Nobody is hired to be the one team that buys from the other team. The work happens anyway.
Workflow 2: Lab Delivery
After the deal closes, until the lab is live. Eight tasks. Five teams, including the cloud providers.
The HubSpot ticket flips to order closed and now the work moves through five teams. Five of the eight tasks are hidden. Task 11 shows where the geography check was missing, as the next section describes.
Lab Delivery
After the deal closes, until the lab is liveTask 9, the templating step, is interesting. After the lab is built, somebody saves it as a reusable template. That work is not for this customer. It saves time on the next twenty. Nobody is hired to do it. Either the engineer who built the lab decides to do it, or it does not happen, or it happens three weeks later when somebody else has to rebuild the same thing from scratch.
Task 11 is the hinge for the whole delivery. Support & Delivery has to find out how many users will be on the lab, when it starts, when it ends, and what the budget per user is. Some of this came in through the sales conversation. Some of it did not. They check the sales notes. They ask sales. They sometimes ask the customer. There is no job description for this step. If it is missed, the lab gets built for the wrong shape, and the wrong shape is what the customer feels later.
Task 13 leaves the company. If the lab needs more cloud capacity than the default account allows, somebody on the Support side opens a ticket with AWS or Azure. If the cloud provider does not lift the quota in time, the lab cannot launch. That is an external dependency, but the workflow diagram has it as a sub-step of "configure."
Workflow 3: Lab Support
Every day the lab is live. Six tasks. Four channels. Five teams.
Customers do not file issues through one queue. They file through Freshdesk. They WhatsApp the program manager. They email the partner manager. They get on a call with their account person. Whatever channel the issue lands in, support has to spot it, sort it into one of four buckets, and pull in the right team.
Lab Support
Every day after the lab is liveNotice the pattern. Workflow 1 had a hidden routing step at task 2. Workflow 2 had it again at task 7. Workflow 3 has it at task 16. Three workflows. Three hidden routing steps. None of them is in any job description. All three of them decide where the work goes next.
And the four buckets are not four versions of the same job. Bucket 1 is firewall coordination with a customer's IT team. Bucket 2 is internal routing back to the team that built the lab. Bucket 3 is teaching a person live on a video call. Bucket 4 is bug triage with our own engineering team. Four very different things hiding under one label called "issue resolution." A proposal to automate support needs to explain how those responsibilities connect and where people remain accountable.
The phone call
Last quarter, this is what happened.
A customer rolled out a lab to a global cohort. They told us how many users. They told us when it had to be live. They told us the budget per user. They did not tell us that a third of the cohort was based in India and a third in Singapore.
We provisioned everything in the US default region.
A week in, the customer's program lead called to report slow pages and labs that felt frozen. They had a session the next day.
Freshdesk had reports from users in India about labs not loading, slow pages and exercises they could not run. Support had triaged them as Bucket 1, lab not accessible. They looped in the customer's IT team, who checked the firewalls. None of it was the problem.
The problem was not a firewall. The problem was that somewhere upstream in our flow, nobody had a task that read "ask the customer where their users actually live, and provision regions accordingly."
Sales did not ask. User-geography is not a Sales qualification field. Support & Delivery did not check. The rollout-details task at workflow 2, task 11, does not include geography. Build did not branch into multi-region. Nobody had flagged regional spread upstream. The customer only found out we got it wrong when their users started complaining about lag.
We added two tasks: ask about user geography during sales qualification, and review the required provisioning regions at the build step. An AI assistant could help read the qualification answer and suggest a region split. That proposal would need approved regional rules, cost and capacity checks, and a delivery owner to review the suggestion.
The fix was not visible from the workflow diagram. The diagram says "configure lab." That is one box. The tasks underneath it are several. One of them did not exist until a customer call forced it into existence.
The shape of the work, summed up
20 tasks. Nine were missing from our job descriptions.
The number that surprised me when I drew this up was 9. Nine of the twenty tasks in this map were not in anyone's job description. In our case, experienced people absorbed those responsibilities. A proposal based only on the documented path could miss these responsibilities.
So what does this mean for an AI deployment?
The right decision depends on the task.
Look at what a quick scan of those 20 tasks tells me.
Task 1 suggests an agent that drafts a HubSpot ticket from a customer request. Task 2 suggests an assistant that recommends the lab type and refers uncertain cases to Sales. In this design, Sales owns closing the deal at task 6, and Support owns the live teaching call at task 19.
Each proposal needs examples and checks. A ticket assistant must preserve the customer's request. A routing assistant must recognize when information is missing and send it to someone who can decide. These checks sit inside the connected delivery workflow.
We would start with a bounded change, name its owner, and test the normal and exception cases before extending it. People need to practise their changed responsibilities alongside the proposed agent. Operating rollout and support need their own agreed scope.
What we do for customers
Use the same approach to scope your work, the proposed change and its checks.
Map the work
Compare job descriptions, SOPs, ticket trails, job postings and workflow frameworks with what the people doing the work describe.
Propose the change
Review candidate tasks with their owners. Record the reason for using AI, the required context and the work that stays with people. Estimate impact from an agreed baseline, with assumptions visible.
Build and check
Agree what your team will build or configure and what Nuvepro provides. Prepare people on representative work and check the proposed agent against defined cases. The operating owner decides on rollout using the resulting evidence.
Questions this story raises
Questions about delivery responsibilities, missing handoffs and what an AI proposal would need to check.