ProcureCon: Who Owns the Outcome After the Contract Is Signed?

I've been taking A LOT of paper notes at ProcureCon East this week, courtesy of the new Moleskine Pen and calendar notebook I paid an embarrassing amount for in NYC last weekend 😇. Looking back through them, one question keeps showing up:

Who owns this?

The contract. The vendor. The category. The data an AI agent is about to use. The decision that needs procurement, finance, legal and the business to agree before anything can happen.

I wrote about it after Day 1, and the next set of notes made the question harder. We can name the teams involved. We can draw the org chart. We can describe the workflow. But when something changes after signature, who stays with it until the business gets the result it bought?

That's the ownership question I want to bring home from ProcureCon.

A green dashboard can still leave you doing the work

Chapter 9 of my Outsourcing Sales Playbook is called "How to Delight Your Client After You've Won Them (Hint, It's Not Always Hitting SLAs)." It was written for providers. The starting point came from being the buyer: I've fired vendors who hit their SLAs because managing them was a pain in my ass.

You know the kind of relationship I mean. The report arrives on time, but you have to chase the information you actually need. The ticket is closed, but the business still has the problem. The account team brings a beautiful quarterly presentation and you bring the list of things that haven't moved since the last one. My executive stakeholder who is paying the bills tells me they're his favorite vendor based solely on the report their AE gave him on the business but his own team members are literally asking me to put them on a PIP (they only get to meet this dude once a quarter and it didn't make the 30 minute office hours priority list).

The contract is being administered. The service still needs you to drag it across the finish line.

The chapter asks providers to make our lives easier. Flipping it back to our side of the table means asking a less comfortable question: have we made it possible for them to do that?

If our own teams disagree about priorities, nobody can approve an exception, and every urgent request arrives with a different definition of urgent, the provider can't solve that for us. They can flag it. They can suggest a fix. Someone on our side has to make a decision.

Spend under agreement still needs someone to manage it

One of my pages puts spend under agreement alongside spend ownership. Those are different questions. Knowing how much spend sits under a contract tells us something useful about coverage. It doesn't tell us who notices that demand has changed, challenges a renewal, or checks whether the business still gets what it needs.

I'd ask who owns the next decision about that spend, and when they're going to make it. Otherwise, we can have a very complete record of an agreement that nobody is actively managing.

The space between teams needs an owner too

In my notes from the ProcureCon operating-model panel discussion, I wrote "the space between" next to control and ownership.

That feels like the useful place to look.

Procurement may own the sourcing process. Legal may own the contract language. Finance may own the budget. The business owns the work it needs done. Each can be doing its job and still leave a decision sitting between them.

Take a simple, fictional example. An invoice-processing provider meets the agreed turnaround time for complete submissions. Meanwhile, invoices keep arriving without the information the provider needs, exceptions sit in an internal queue, and suppliers are still chasing payment.

The provider's dashboard is green. The business is frustrated. Procurement asks why the provider isn't performing, and the provider points to the definition of a complete submission.

Read the contract closely enough and you may discover that everyone is right. Very helpful.

The next useful conversation is about the whole journey. Who can change the intake requirements? Who gets the missing information from the business? Who decides when an exception is acceptable? Who checks that the invoice finally gets paid?

An owner needs a decision they can make, information they can trust, and somewhere to go when the decision is beyond their authority. Putting their name in a spreadsheet gives us a starting point. It doesn't give them those things.

For a service that crosses several functions, I'd want one person on our side to keep the overall outcome in view, with named people responsible for the specific decisions. That person doesn't need to do everyone else's job. They do need to know when the work has stopped between jobs and be able to get it moving.

Would you buy the process you're asking everyone else to use?

Today's notes made me turn the ownership question back on procurement itself. I wrote a question I probably need to ask myself more often: if the P2P process your team owns were a public reflection of YOU, would you be proud? Would you sell that product to someone new?

We talk about marketing procurement to the business. Our tools and processes are already doing that for us. Every confusing intake form, sensible answer, unnecessary approval and useful conversation is an advertisement for the team. Some of those advertisements are terrible.

Before we ask why people aren't following the process, I'd like us to try being the customer. What is the person actually trying to get done? Have we done that job, or at least sat with them while they do it? A salesperson trying to get a deal signed and a scientist trying to keep an experiment moving might have a different view of our beautifully designed workflow.

That doesn't mean every request gets a yes. It means we should be able to explain what our process helps them accomplish and own the work of making it usable.

What, specifically, are we asking the business to commit to?

The conversations about relationship building and stakeholder management also had me writing "sell, sell, sell" in the notebook. At some point, support has to become a specific commitment.

In the invoice example, that might be: can the AP director assign someone to resolve missing-information exceptions every day, starting Monday? Who is that person? What authority do they have? What happens to payment times if we leave the queue exactly as it is?

Those are things we can agree, decline or change. "The business supports this" doesn't tell the person stuck in the queue what happens next.

Then we need to check whether the change helped. Savings matter. So do fewer late payments, less chasing, reduced risk and whether the people using the service think it works. Data is table stakes. What we do with it is where ownership starts to show up.

If we ask for feedback, I'd want the next conversation to include what we changed because of it. An annual survey followed by an action plan that someone actually implements sounds obvious. I'd still rather see that than another presentation telling me how much everyone values the relationship.

Preferred supplier status has to survive Tuesday morning

Another line in my notebook: preferred supplier status must be earned AND maintained.

It's easy to explain why a supplier became preferred. We ran a process, evaluated them and agreed that more of the business should use them. The harder question is what happens afterward.

Does the business know how to use them? Are the requirements still current? Do the people running the service know what procurement promised? When someone needs an exception, can they get a sensible answer before they give up and buy around the process?

This is where a preferred-supplier program becomes an operating responsibility. Someone has to keep the buying path usable, the standards current and the exceptions visible. Otherwise, we have a preferred supplier and a growing collection of reasons nobody prefers using them. Out of respect for Chen Lin from Saint-Gobain who presented on this (it was my favorite presentation of the conference, and she has opened my eyes to the possibilities) and anyone else managing a PSP I'll hold my comments on the value of having a preferred supplier program to begin with based on my personal experience with this when I was at Google...tldr it was an unmitigated disaster and I'm so sorry if one of my friends or former colleagues who was responsible for it actually reads this (it wasn't your fault).

The same applies to reviews. I don't think every monthly meeting needs a manufactured problem to justify its existence. I do think it needs to answer whether anything has changed that requires a decision: demand, scope, staffing, performance, a business priority or the way the service is delivered.

And if the answer is yes, who is doing what before the next meeting?

AI makes the ownership question more urgent

AI was all over my notes, unsurprisingly. The discussion of procure-to-pay as related but independent segments stuck with me. Mapping the steps helps us see where work goes. We still need to know who resolves the problem when it moves from one segment to another.

What caught my attention was how often the questions about technology ended up being questions about decisions.

Who sets the business target? Who checks the data? Who agrees that a change in the service is acceptable? Who can stop it if it starts going wrong?

An AI tool can help draft an SLA. The business still has to decide what good service means - "the SLA target" (I was slightly disappointed but not surprised at the lack of mention of "SLAs" at a procurement conference - another reason I loved Chen's presentation she actually presented her standard category level contract SLAs 😚🤌). Here is a hint - if you want to become an outsourcing EXPERT like me (self proclaimed) do what my outsourcing teachers (mostly angry old men / ex-EDS executives) taught me to do when you write a services contract: translate EVERY RATE OR BILLING UNIT INTO A VOLUME UNIT WITH A SERVICE LEVEL ASSOCIATED WITH IT. Said in another way - the only time your vendor ever bills you "per hour" for anything better be a fucking world war 3 level emergency - everything else is a fixed price (tied to a volume level or scope of work) or priced per unit of OUTCOME - not unit of supplier effort.

Sorry for that rant. Back to the point here... Someone has to know whether the information behind that recommendation reflects what the company actually uses (the unit of outcome - the thing you are theoretically forecasting for). It can route an invoice exception faster. We still have to decide who is allowed to resolve it.

And when a provider introduces AI into the service, "we're using AI now" isn't enough of an explanation. I'd want to understand what work changes, what data is involved, what happens to quality and staffing, what we're paying for, and who has agreed to it on our side.

That connects to last week's rate-reduction article. Productivity can show up as a lower bill, more capacity, faster service or less work for our own people. We need to agree which benefit we're buying and how we'll recognize it. Otherwise, the provider can celebrate the rollout while we keep waiting for the benefit.

If we can't answer those questions for the manual process, automating it will make the unanswered questions move faster.

Ownership is also how you behave when something goes wrong

The relationship discussions were a useful reminder that this isn't solved entirely with columns and approvals.

My notes keep coming back to early communication, admitting mistakes, asking vendors what we're doing wrong, and treating a partner well before we need them in a crisis.

In the book, I describe the difference between hearing on Friday that a target will be missed and hearing on Tuesday that there's a problem developing. Tuesday gives me time to help. By Friday, I'm explaining it to somebody else.

We should want the Tuesday call. We should also notice how we respond to it. If every early warning earns the provider an interrogation and every request for help becomes proof that they're incompetent, we shouldn't be surprised when the warnings get later.

I'd ask two questions in the next review: what are you worried about that hasn't shown up in the report yet, and what are we doing that makes it harder for you to deliver?

Then I'd listen to the answers. Including the inconvenient one about us.

Today's notes gave me a useful way to put it: ownership includes anticipation. If we can see the deadline slipping, the policy becoming outdated or the approval getting stuck, we should start the conversation while there is still time to change the result. Being the person who explains the failure afterward is a much less useful job.

The CPO panel brought this back to the business

The final notes I wrote during this morning's CPO keynote panel belong in this conversation too. Don't assume your executives know what procurement does. And don't assume a savings number tells them why they should care.

My notes include a much more immediate test: what happens when the business can't get what it needs? Inventory, laptops, service capacity. The consequence is felt by someone trying to do their job. That's the conversation I want us to be able to have before we show the savings slide.

I also wrote down the idea of creating a shared vision for vendors AND stakeholders. We can agree a commercial package and still have three different pictures of what success looks like. The supplier is optimizing one thing, procurement is reporting another, and the business is waiting for something else. We need to get those people looking at the same result.

The public-sector discussion was a useful reminder that the purpose has to fit the organization. We need to understand what that organization exists to deliver, then explain how our work helps it do that.

And the leadership advice in my notebook was refreshingly straightforward: be a servant leader. Be humble. Be thoughtful. No ego. Successful executives still have to be good managers. Go figure!

That feels like ownership to me. Understand the work, make the commitment clear, and help the people doing it succeed.

Pick one service and follow it all the way through

You don't need to redesign the company to start this.

Pick one service where people spend too much time chasing. Write down the result the business expects in a sentence a business user would recognize. Then take the last real problem and follow it from the first warning through the decisions to the outcome.

For each point where it stopped, record the decision, the person authorized to make it, the evidence they needed, the person doing the next action and the date you'll check the result. If an exception was approved, record when it expires. Temporary workarounds have an impressive ability to become permanent operating models.

That's the ownership review I'm adding to the Buyer Negotiation Blueprint. The contract and Rate Bridge sections help us agree what we're buying and what a price change gives up. This extension asks who will keep those agreements working once everyone leaves the negotiation.

My biggest takeaway from ProcureCon so far is that procurement has an opportunity to connect the decisions that otherwise get separated by function, system or contract clause. We don't have to own every task to insist that the outcome has an owner.

When something falls between procurement, finance, legal and the business in your company, who stays with it until it's resolved?

I'd love to hear how you've made that work.