Digitizing Fee Schedules

 Note: This is a transcript of my video “Digitizing Client Fee Schedules-- From Sales to Legal Contracts to Billing in an Hour.” Reading this is infinitely better than falling asleep watching the video, especially if you operate heavy equipment.

—

Good morning!

A couple of days ago, a subscriber asked if I could do a walk on the data management of client fee schedules. How to digitize and maintain updates on PDF documents. I've, or I will, throw it up... you know, the question... up here somewhere.

So let's get into it.

Whenever someone asks me to digitize something, I pull the process version of Google Maps.

I start by pulling the camera up from the local problem, the problem I've been asked to solve, to the shot that shows its immediate, you know, neighbors. To the shot that shows the neighborhood, the city, the state , the country, the continent. You get the picture. So, when someone asks, "How do you digitize a client fee schedule?"

I keep going upstream, process-wise, all the way back to the Big Bang, if I have to, and I map out every impacted process downstream. So upstream, in a borderless way, past my institutional boundaries... all the way into the client's process-- stuff we usually think is their problem, when it's really ours.

And downstream, again in a borderless way, past my institutional boundaries. That idea needs an example. So let's use client fee schedules and Google Map It. Before we start though, for those of you that didn't ask the question, What? What's a client fee schedule? Now, I'll use custody as an example throughout this walk, but you can apply the idea to any business function that bills for a service or product.

In custody, a client fee schedule is a contract between the client and the custodian that says what every aspect of the service is going to cost. Think of it as a detailed menu at a restaurant in contract form. Everything should be on it.

Is there an account setup fee that the client has to pay?

How much?

Transaction fees for buying or selling securities. How much?

Asset custody fees based on, you know, the total value of the assets held. How much?

Safekeeping fees for storing physical securities. How much?

It's all the explanations that are missing from your, from your cable bill. Taking the mystery out of all, all those service charges.

Are there reporting and statement fees for providing regular reports and statements to the client? How much?

Transfer fees for moving assets in or out of the custody account. Fees tied to corporate actions-- we did a walk on those-- for handling events like dividend payments or stock splits. How much?

Foreign exchange fees for converting currencies. Compliance and regulatory fees for ensuring you don't, you know, land in jail.

Any fees for any additional services that might be requested by the client. Like, what'd I miss? Tax reporting or proxy voting services. How much?

The point is that if the client is going to pay for anything in that relationship, if that charge is going to land on a client bill down the road, it's on the client fee schedule. Or should be.

Again, I made that very custody specific, but a bill's a bill, right? So, you can apply the idea of a client fee schedule and it's automation and it's digitization to any business you're in, not just custody. Not just financial services, any business.

Okay. So let's Google map this baby.

If you pull the camera up, right, you see that the immediately upstream thing from the creation of a client fee schedule, the process is the internal legal process that crafted that contract with the client.

And downstream from the creation of a client fee schedule is your client onboarding program. If you keep pulling the camera up, you see that even further upstream from the legal contracting is your larger sales process. And even further downstream from your client onboarding is operations doing their day jobs and eventually billing that client for the services they're providing. And, you know, hopefully charging for those services based on the client fee schedule.

Okay. That might've been confusing 'cause I kept going back and forth, back and forth. So let me give you the Google Earth view of that end-to-end process. And again, I'm going to be intentionally borderless going past your institutional walls, right?

Your client's clients.... have a problem that needs your client's services. For instance they need to manage their investments. That's way outside your current view of the problem, but it's the right place to start. So your client provides their clients with a solid service, like the ability to buy and sell stocks for a small, reasonable commission.

But! Your client, or potential client, needs to custody those assets-- all the stuff that their clients are buying and selling. Enter your sales process, which basically says, "Hey, we can service those assets and we're more, you know, pleasant than the other servicers." BAM! The sale happens. Never that quickly.

And your client-- which up until now has been just a sales prospect-- now becomes an actual client. Yay.

The lawyers are pulled in at that point. Contracts are drafted and approved by both sides. And in those contracts is our lowly little client fee schedule. You with me? Cause I gotta make sure I don't get hit by a car.

After the digital ink dries, or as it's drying, really, the client is onboarded to your company. KYC is done. KYC is an acronym for Know Your Clients(KYC) which is basically just guidelines and regulations in financial services that require every firm to verify, identify suitability and risks involved with maintaining a business relationship with that customer.

Think like anti-money-laundering or counter terrorism or financial regulations, etc, etc, etc. After all that, your client starts using your services, right? And every time the client uses that service-- or someone in Ops does something for that client-- a little message is sent to your billing platform that says, "Hey, I charged this based on the client's fee schedule."

Although at that point, it's usually based not on the client fee schedule, but you know, on tribal practices within Ops... because who the hell knows what's in the client's fee schedule other than the salesperson and the lawyer? That data is far away and locked in a pdf. Not useful at all.

At the end of every month, your bill goes out to your client and many, many, many months later, your client pays you for the services you provided.

So that's the Google Earth end-to-end. From the client's "problem to solve" to sales, to onboarding/KYC, to service provision, to billing. It's the full, full world, right? Rinse and repeat for every new client, or whenever our contract is renewed with an existing client. High level, useful, but never enough.

So, you need to get into the details of each step.

Next level down. A lot closer to the Earth on Google Maps. How is custody sold? And again, custody is a broad example. Well, step one: some smarmy salesperson makes initial contact with the prospect. In custody, they're actually never smarmy. They're dry, if anything. They're not selling Ferraris, they're selling utility services, you know, one step up from selling self storage units.

Anyway the sales process begins with that interaction between the potential customer and the sales rep. This can be from an intro, a reference or just cold calling, right? And it's done through various channels, not just cold calling-- through phone calls, emails or in-person meetings. But mostly in-person meetings.

Step two: there's some kind of needs assessment done. The sales rep will get to the prospect and, start getting them to complain about their problems. So that the rep can understand the customer's requirements and objectives.

That's a polite way of putting it, right? Because almost everyone needs the same thing, but listening to the client helps the rep tailor the solution to the customer's specific needs. None of this is custody specific. It's just good sales. Listening.

Step three: a proposal is is put together by the rep based on the needs assessment or an RFP-- a Request For Proposal by a client or a potential client-- and hopefully the salesperson is using a product or service master. I'll come back later. That's an exhaustive list of anything that can fall into the client's fee schedule. Think service catalog or restaurant menu. The point of this step is for the sales rep to outline for the client.

[Nice jogger waves. Hello. How are you? Doing well.]

The point is for the sales rep to outline for the client what they've got to sell, right? The custody solution, pricing, features, benefits, etc. I should be jogging like that guy. Step four: negotiation, because everyone needs to feel special. The sales rep and the customer engage in "No, no, not that clause, this clause!" to address, you know, any and all concerns or questions and to come to a mutually agreeable contract.

Step five would be client onboarding done differently at every shop and somehow-- it's always the same kind of painful to the client and to everyone in Ops. The onboarding process involves gathering all the necessary data and documents from the customer, setting up all their accounts, configuring the internal systems and processes to meet the customer's requirements.

I should probably add a step 5a. training, both client training and internal training, depending on the complexity of the solution that's being sold. The sales rep or a dedicated training team may do like a little puppet show for the customer staff or for internal staff for that matter on how to use the solution effectively or how to manage the client properly-- you know, one side, other side.

Then there's the the go live date-- for the service to begin, and everyone runs around like headless chickens, and ends the day with a note about how smooth everything went, how all the customization or integration work was done, and how clearly it's all systems doing the work, not a bunch of overwhelmed Ops people.

And then, the final step-- seven-- billing, which as a digital bundle might arrive at the client shop a month later. But it takes a ton of time to get right because it's usually very Ops heavy. Why? Because of how much work is done manually for new clients. And with manual work comes the challenge of, like, "hey, are we actually billing this work?"

A testament to the complexity of getting the client fee schedule right, you know, four steps earlier... or if you want to time travel back a lot getting the product master right years earlier.

Okay, so, this is probably a good point to transition to talking about data management.

First, quick definition.

Again, a product master-- I mentioned it earlier-- a product master is a little database, usually an important part of a reference data ecosystem-- that includes like a client master (a list of all clients), a securities master (a list of all necessary reference data about financial securities and all asset classes), and you know, a bunch of other bespoke masters that depend on who the company had as a data steward years ago.

The point here is that the product master houses all the products that your company sells-- think comprehensive restaurant menu. And more importantly all the variants of each product (or restaurant menu item) that they sell And hopefully how much they sell each variant for.

It's important to be exhaustive in the product master if for no other reason than to highlight to your business partners that they need to simplify their operating model. Because if you have like 10,000 clients and each one is a special snowflake, you fail at scale. I'll say that again because I don't know if you heard me over the car.

You fail at scale.

Simplicity in your products and reducing the potential number of variants helps you and your system scale. But, let's park that because we'll go into that in a bit.

Product Master. Does every client at a custodian pay the same transaction fees? No. The size and depth of the relationship matters. The contract with the client matters. The client fee schedule matters. The business context always matters.

Does every client at a custodian pay the same custody fees? No, they're based on the total value of assets held again, right? The size and depth of the relationship. I could go down the full list of fees and the answer would be the same. Safekeeping fees? The size and depth of the relationship.

Transfer fees, corporate action fees, foreign exchange? The size and depth of the relationship ...

This begs an interesting data management question-- not about the product master but about how it's modeled against the firm's client master? That list of all the firm's clients? That client master's design should be so much more than like name, address, phone number for every client.

It needs to include metadata that classifies each client into the smallest set of common groups possible. Something called client segmentation. A dumb example would be like, you know, your company has 10,000 clients, but each one of them is classified as only one of three groups: small, medium, large... like the bears.

So, instead of having 10,000 snowflakes, each one needing to have, you know, a bespoke fee schedule, and bespoke rules in every system, and bespoke processes-- your company has three variants. Highly unlikely, but let's, let's pretend. Three variants! Small, medium, and large.

This is the one time in life where, where size matters.

Obviously, relationships are more complex to model than size, which is why small, medium, and large as the only client classification or segmentation doesn't work well. The, the point here is that the intersection of your client master's design, if you're into data management, and your product master's design is one of the best indicators of whether you have a scalable business.

The fewer the number of client classifications, the fewer the number of your products-- or more accurately-- the fewer each product has price variance, the more likely your business will be profitable and growing.

Okay, so far, we've covered the high level, end-to-end, the next-level-down worth of process details and we know what reference data can... how it can help: client masters and product masters. And, we know that, just having, you know, those two databases aren't particularly useful, without simplifying your operating model-- without, for instance, taking out as many product and pricing variants as you possibly can.

That's not a tech or data ask. That's an operating model transformation that the business needs to own and drive.

Now, with that table set, for lack of a better metaphor, we can finally talk about the question that was asked: how to digitize client fee schedules.

Three word answer. Data supply chain. If your goal is to digitize client fee schedules, you need to start by mapping the data supply chain at the Google Earth level-- your larger end to end process.

We just did that. Not well, but we did it. Right? Your results may vary. And should vary. It should be a lot more, you know, in depth and comprehensive-- from the minute a salesperson identifies a prospect or potential client in your sales platform (think Salesforce, Microsoft Dynamics, SugarCRM, whatever).... all the way to your billing systems (think Oracle, Fiserv, Salesforce, whatever). And, everything in between those two, those two system or process poles. So, from your sales process and systems to your legal contracting process and systems to your client onboarding process and systems to your KYC and AML process and systems, to your day-to-day service delivery, all your transactional systems, to your billing process and systems.

The data in every one of those systems needs to be modeled as part of one coherent end-to-end process and ecosystem. And they all need to be anchored in the same well kept, high quality product master and client master.

Now, if you work in the, in the master data space, if you own a reference data platform, you're probably nodding your head, feeling pretty good about yourself with that last statement. Stop. Every reference data platform, every reference data person I've ever met is under the false impression that just offering a product master or a client master or a securities master is enough.

They think their only job is to have high quality relevant data in their data source and to, you know, encourage all enterprise systems to use it.

Lame bordered thinking.

Your job is nothing short of a full operating model transformation on the business side and a wholesale rethink of how every platform in your larger ecosystem is connected to one another, not just to your masters.

For instance, let me cross the road, someone internally owns your CRM platform. When they, back in the day, modeled their data for that CRM system, they gave a majority of their focus, if not all their focus, to how to serve your salespeople. Great! That's client centricity. Hard to blame them. Or is it?

Maybe their real clients aren't their salespeople. Maybe that owner should have focused on how the CRM fits into the larger end-to-end enterprise process: sales to billing... from the company's client all the way back to the company's client. Client to client. Maybe that CRM's owner, maybe their real client, is their company, not their salespeople.

As much as you love your salespeople, your, your internal clients. It's not who your real clients are. And that example could have been about the owner of your legal and contracting platforms... the owner of your client onboarding platforms... your KYC and AML platforms... every transactional system used during service delivery.. the owner of your billing platforms. You get the picture.

Whose job is it to deliver end-to-end platform integration? Hello. Whose job is it? The first platform, you know, what I mean by platform integration is, is how that first platform connects to the next one, and to the next one, and to the next one, from a data supply chain perspective.

I'll tell you one person whose job it isn't. The person who thinks their only job is to provide their firm's reference data, their, their high quality masters. Now, I do get the occasional enterprise architect who watches one of my walks. And if that's you, you're probably thinking, wait, that's my job!

Is it though?

Because you and the owners of the masters and the owners of all the associated systems in that data supply chain should look at how well you're doing that job.

The largest inefficiency in every enterprise that I've worked at, bar none, is that sales process. The data and process funnel that could feed every system after it, in every end-to-end, client impacting flow... That sales process, could be designed to ask for all the information that the firm needs... once!! At the very beginning. And yet, no enterprise does that. CRMs are for salespeople. Every process after that initial sales process... that initial client interaction... has to fend for its own data needs.

Which is at the heart, by the way, of why every client hates every financial institution. Because... When we don't intentionally design the end-to-end data supply chain, every process after that initial client interaction has to go back to the client and ask that now annoyed client for either the same data or missing data that we should have asked for the first time.

So when you're doing the data model for your masters or your CRM or any of the dozen systems in that end-to-end flow, you're actually implementing one Google earth level metamodel.

You'll know you've gotten it right when you don't have to go back to the client for the next process in that end to end.

You'll know that you've gotten it right when your downstream people aren't re-keying and 📍 re-verifying. Okay, enough preaching. What else do you need to digitize client fee schedules? Well, we need to 📍 end our focus on PDFs.

Part of the question that was asked, right? Like, how do you do it with PDFs? You don't.

We need... Data. Not documents. It's still kind of shocking to me that digitally sophisticated folks continue to think in analog terms even when they're leading digital transformation efforts. Here's a statement that should feel intuitively correct, at least.

There is no place for a PDF or any document, really, in an end to end digital process. There is only data. All the information in that contract is data. The only potential use of the document form of an actual contract is for real world, real ink signing... if you still haven't moved to digital signatures, and I don't know anyone who hasn't, unless they're legislators are full-on technophobes.

So, every time you come across a company with a document management system-- Let me say this again, because it's counterintuitive-- every time you come across a company with a document management platform... well, you've found analog thinking masquerading as digital transformation.

All those millions and millions of contracts saved as documents, PDFs that are sitting in your contract management system-- that's a testament to your company's lawyerly commitment to live in the last century, the last two centuries held the last 10 centuries. So your company's lawyerly commitment to live in the last millennium.

It's an excellent signal of the lack of a digital imagination. Document management, what we all take for granted, is an excellent signal of the lack of a digital imagination.

Okay. An end-to-end flow-- now this is going to sound obvious, but we don't live this way-- an end-to-end flow is built around a data supply chain. System/process number one-- CRM-- feeding data. to system/process number two-- legal contracting-- which, by the way, transforms the data and feeds it to system/process number three-- Client onboarding-- which transforms the data and feeds it to systems four, five, six, seven, and on and on and on.

Now, think about how ridiculous that end-to-end digitalization and automation aspiration becomes if your CRM system is finally modeled to feed downstream processes with all the data they need and the next system in that flow, the legal contracting system, goes all, you know, analog with a commitment to PDFs and traditional document management.

You have a massive break in your data supply chain. Instead of digital, digital, digital, data, data, data, front to back, you have a hard stop. Analog thinking, even when it masquerades as a digital platform, is a...

A full stop. A massive fail. So, what's the alternative?

I wish I could say that there are a bunch of great contract management platforms you can buy for the enterprise that aren't rooted in the legal world analog thinking-- their insistence on traditional document management. But, I can't.

All the big document management companies that I grew up with at least-- Documentum, OpenText, etc, etc-- have slowly died since Microsoft SharePoint allowed lawyers to not change their analog operating model, their analog operating discipline.

Every time you see PDFs, or file folders, or document metadata, you're seeing analog thinking masquerading as digital. Even the word, the word folder is analog. So that should give you a little bit of a hint. How does it need to change?

A contract-- I'm gonna get philosophical here for something like a contract-- a contract is just dozens of data sets posing as paragraphs of inscrutable legal text... as legal clauses that are minimally changed from client to client, from deal to deal.... Tables of bespoke data, typed into the contract... making that contract the worst possible golden source of client data.

What is a client fee schedule after all? It's a table, trapped in an immutable PDF with some legal clauses as garnish.

Remember how earlier, much earlier in the walk, we were talking about the need to transform your company's operating model, because if you have like 10,000 clients and each one is a snowflake, you fail at scale.

In that example, the operating model change was about having the smallest number of client classifications and the smallest number of product and pricing variants. Well, with the problem of your analog legal practices, your company needs a different kind of operating model change. With the help of your lawyers, you need to design-- not a document management system... not, you know, some really neat filing system for that document management system... a document metadata scheme.

You need to design a next generation legal data management platform. The word document shouldn't even be in your brain. So, your lawyers don't do what they currently do. When you design the system, that's your goal.

Your lawyers don't do what they currently do. When they need to draft a new contract. Which is to, you know, go to their SharePoint folder... the one that houses a similar contract... the one that only that specific lawyer knows is a similar contract... that they, and only they, used for some other client... and that they can now use as a template for the new client.

Hell, it could be worse than that, actually. Most lawyers also keep their contract templates on their personal share drives. Lawyerly tribal knowledge. God bless 'em, because that's tech savvy that you don't expect from lawyers, but it's also bad for the enterprise, for digitizing any end-to-end processes that has lawyers somewhere in the middle.

And honestly, like, what, what process doesn't have lawyers somewhere in the middle?

So, what you need to do is to work closely with those lawyers to propose a different operating discipline that starts and ends with data, not document templates. Because if you can articulate a new contracting process, Tech can build that system.

I'll give you an example. Imagine a contracting system that your lawyers use that starts with a long Turbo-Tax-like set of questions They're all bounded questions and for that I mean that every question's answer is limited by a range of data that's one-for-one mappable to product data in your product master... to client segmentation data in your client master... and pricing data-- that's the intersection of your product master and your client master. Imagine that while your lawyers are answering the Turbo-Tax-like questions on the left hand side of the screen, the right hand side of the screen is showing the impact of their selections in an old school contract, an old school client fee schedule.

Just to ease those friendly lawyers, you know, into the century. Once they're done with with the questions, they, in theory, have a PDF they can send to their client for negotiation.

But, and I hope you're ahead of me on this one, why would they send that PDF to their client? If they sent the PDF to their clients and asked them to mark it up, which is what they do today, they're just asking their clients to change all that digital goodness into an analog mess.

So instead of trading in PDFs, the data centric, Turbo-Tax-like interface would ideally be exposed to the lawyers on the client's side. The client's lawyers still get to challenge everything from deal terms to indemnity clauses. Because, you know, that's their job. They just have to do it by changing the answers on the Turbo-Tax-like interface.

The same one that your company's lawyers used in the first place.

That's digital negotiation. Negotiating not on the wording of the contract, at least directly. But on the data that drives the wording, the legal clauses.

Once both sides are happy with the terms, you do a ceremonial creation of a PDF, purely ceremonial, for the digital signing ceremony.

And you save, not the PDF necessarily, but the data that drove its creation. And can hello, and can reproduce it. Because, you know, you save the data and have the transformation logic that can turn that data into the exact same ceremonial PDF whenever you need. I mean, legally, you should also store the signed immutable document as a PDF.

But really, you should never reference it again unless litigation is involved. Okay, that is high level how you keep your lawyers from breaking everything digital that's downstream from them.

And you know that you're, you're doing it wrong when you make an exception for the contracting piece in that end-to-end.

What do I mean? When you're mapping an end to end, it's really tempting to say, "look, we don't need to digitize step 3, the contracting step... as long as we give the lawyers the data they need and let them do their thing their way." That's a fail. Giant F. Because every change to the terms in those analog PDFs... to the client's fee schedules, which we're talking about the entire walk... every change in those analog PDFs impacts downstream processes.

A data supply chain can't be like step one digital, step two digital, step three [some analog miracle happens], step four digital, step five digital.

There's no such thing as an analog miracle.

It's either digital, or every process after it has to re-key, re-verify, re-connect with the client, re-bother them with re-dundant tasks, or asks.

It's like getting driving directions from New York to Puerto Rico. Driving directions. At some point, you're going to drive into the ocean: your legal contracting process.

And, even if your [data supply] chain, your workflow is smart enough to employ a ship... your legal contracting process is the Bermuda Triangle of data.

You can't get to Puerto Rico without sailing through that.

All data enters, no data leaves.

Just a boat full of useless PDFs.

But now at least, you know, the alternative, right?

Not just a great product master, a great client master and operating model transformation that simplifies everything in those two reference data repositories from client segmentation to product pricing. It simplifies everything.

Not just the masters, but the digitization of your entire end-to-end flow from your sales process to your contracting process to onboarding and KYC, which I'll probably walk about and talk about next... To the service provision, that service delivery you do every day as a company, to billing, that final step, right?

It was a simple question. I'll put it back up here again so you can read it. How do I digitize client fee schedules and maintain updates on PDF documents?

Now you have a comprehensive answer, or at least as comprehensive as I can do in what, 40 ish minutes?

Okay, hope that was useful.