👋 Hey, this is Artem and this is The Blueprint. At WIQ, we spend each day forward deployed at Fortune 500 companies working through the hairy journey of AI transformation.
An engineer can connect an agent to the vendor system. They can't decide, on the customer's behalf, who is allowed to approve a new vendor.
I thought about that decision when I read Accenture and Google Cloud's September 8 announcement. The companies plan to establish a workforce of 1,000 forward-deployed engineers through their new Gemini Enterprise business group.
More engineers should help with implementation. In our own conversations, getting started means getting IT and the business to agree on the same project. IT may have a platform ready but need a process worth automating. The business team may have a painful process but no authority to commit the technical resources.
The engineer needs the process owner to define the work and IT to provide access.
The customer still needs to make time.
“Automate vendor onboarding” leaves a lot undecided
Suppose this is the first assignment. Does the agent collect documents? Check that the application is complete? Create the vendor record? Activate it so the company can make payments?
Those are different jobs. An agent that prepares a complete application might be useful without permission to activate anything. An agent expected to finish onboarding will need that permission, or a person who can perform the final step.
The process owner needs to settle the scope with the engineer before the build. They know which records make an application complete and which exceptions need their judgment. They also know whether preparing the application removes enough work to justify the project.
A kickoff interview won't answer everything. Once real cases arrive, somebody has to review the agent's output and resolve the ambiguous ones. That takes time from the person who already knows the job, usually someone the team relies on for other difficult work.
We need to set aside their time in the project plan. If we leave it at “we'll ask them when we need them,” the engineer may have to wait until they are available.
Access changes what the pilot can prove
IT needs to confirm how the agent can access each system and what it can do there. Reading a vendor record and creating one are separate permissions. So are creating a record and approving it.
If the team can retrieve documents but can't write to the vendor system yet, test whether the agent can prepare a complete application. The operator can review and submit it.
A demo that stops at preparation cannot tell us how much time we would save on the whole job. The remaining approval, data entry, and exception handling still take somebody's time.
An engineer can propose ways around a technical constraint. The business owner has to decide whether the resulting workflow is worth using. And someone with the right authority still has to approve any access it needs.
Decide who can say yes to the next step
I want a pilot to end with a decision the sponsor can actually make. For the vendor example: does preparing the application save enough operator time, at the required quality, to justify running and maintaining the agent?
To answer that, record the operator's remaining work, including corrections. Agree on who reviews the result and who can commit the people and budget needed to continue.
If the operator spends as long repairing applications as they used to spend preparing them, we may need to narrow the assignment or stop. I want the sponsor to agree before we start that those are valid outcomes of the pilot.
When we book the engineer's time, I want us to book time with the person who knows the process too. When an ambiguous application arrives, the engineer needs that person's answer before continuing.
We work with many Fortune 500 companies on this. Let's talk through the workflow, the people it needs, and whether WIQ can help.
|
The Blueprint. Stories and lessons on AI transformations from founders and operators making it happen.