Metadata enrichment gives organizations the ability to quickly and easily manage data at a structural level. While numerous platforms enable enterprise-wide metadata enrichment, implementation is often hit-or-miss and labor-intensive.
Tweddle Group designed Service Portal to offer plug-and-play metadata enrichment, gathering vast stores of data under one centralized point of control without disrupting the governance of their disparate (i.e., previously siloed) environments.
In our first installment, we looked at how EU regulations drove Service Portal’s initial creation of Service Portal’s early development.
In part two we discussed the platform’s expansion, as well as its ability to open up new revenue streams for clients.
Now, in our final installment, we examine the subscription-based models behind those revenue streams, along with the metadata enrichment that makes Service Portal so effective in boosting operational efficiency.
Metadata enrichment in service portal
When an OEM purchases Service Portal, and then opts to resell curated sections of their portal information flow to various third parties—whether that’s dealerships, insurance companies or independent service outlets—how does Tweddle Group manage those third-party subscriptions?
None of those transactions pass through Tweddle Group. We’re not involved at all. Each OEM client handles their own reselling of information.
We can observe the activity in system reports, and that’s fun stuff, seeing how much value this information creates for everyone.
We use that insight to consult with our Service Portal clients—in many cases, that insight lets us educate our clients on the value of their information. We try to set them up so they can arrange their own additional revenue streams.
How does this reselling work out for our OEM clients?
It works out pretty well for them. Because it’s all subscription-based—running on a quarterly basis, usually—the revenue streams are continuous.
So, you know, imagine those payments coming in 4 times a year, per country, per market, per dealership, per outlet and so on. The revenue can start to add up pretty quickly.
For service outlets, you know, a lot of our clients will offer unlimited technician access. That often runs on an honor system.
Does the honor system create opportunities for people downstream to do their own reselling or their own information sharing?
It has had that effect once or twice.
We provide oversight in the form of ping reports. The OEM can see who’s pinging the information. They can see which IP address or location is accessing the information.
It hasn’t been an issue although funny things can happen. There was a situation in Russia where one of our clients had 300 dealerships, but we were seeing thousands of pings. Thousands. (Laughs)
You look at that and go, “Hmm. That doesn’t seem right.” (Laughs) Okay.
Or one client, you know, they had a single dealership in the middle of Mongolia, but we were seeing 17 different pings in the surrounding area. “Perhaps we should look into this.”
It’s always up to the OEM to regulate that, but in these cases, they did take note of our data. All they had to do was push back a little bit and the ping numbers went down to where they’re supposed to be.
Let’s say, for whatever reason, a company wants Service Portal, but they don’t want to create additional revenue streams through resale.
They just want to implement the system and use it.
What’s the broader business benefit for that sort of straight-ahead, internal-use-only approach?
Simply, cost savings. And, I suppose, the elimination of headaches for everyone involved, if you consider that a business benefit.
It’s the cost savings of managing multiple information sources through one central system – of revising something once versus 50 times and still missing instances. It’s the cost save of increasing your efficiency across the board.
The effort goes down and the quality goes up.
Yes. Mass metadata enrichment, enterprise-wide, managed from one central point.
Now, it’s important to point out, this is not the Big Bang. Other companies have created all-encompassing information systems as well, but those solutions force you to migrate all your assets—everything you have—into one system.
Service Portal is plug and play. The content doesn’t need to reside in our system.
The system pulls in data from these disparate sources, all these different databases generate the content in a dynamic way.
We connect the system to your databases, and we get them talking to one another in a more productive way.
"Other companies have created similar solutions, but those force you to migrate all your assets—everything you have—into one system. Service Portal is plug and play. The content need not reside in the system itself."
And this is where the APIs come in.
Yep, that’s what’s going on in terms of technology,
In terms of the technician experience, when they sit down and interact with the system, it’s able to assemble all this information and visualize it for them in an easy-to-understand way thanks to the APIs.
So, now, the technician can look and see what repairs have occurred on a specific vehicle or machine.
They can click through the repairs and see what was done in each session.
They can see what parts were ordered, and there might be an API speaking to an entirely separate spare parts system.
Of course, what the technician will find there depends on the information stored in the spare parts system. We’re not Harry Potter (laughs), unfortunately.
Right. They haven’t integrated magic into the system.
No crystal ball integration. Not just yet.
But if the information is there, Service Portal can bring it in and make it available for anyone with the permission to see it.
I remember when we first spoke about Service Portal—I think this was back in 2018, maybe—part of the story revolved around these customized APIs we were building.
Correct.
That would happen, and still happens, if an OEM has a department that’s, let’s say, very particular about their data structure, or perhaps attached to certain processes related to their information sharing. We can accommodate those variations with custom APIs.
Are there safeguards built into the system to ensure the quality of its output?
That’s very important, no? That’s aided by the XML. All the content is native XML with a style sheet on top.
This helps you correct for any issue with the images, or any issue with the translations and so forth.
It’s easy to traffic the content into the review management system and then it’s easy for everyone to validate.
This is where mass metadata enrichment comes into play. It becomes very easy to mass-update assets.
What’s an example of using metadata enrichment to mass-update assets?
Well, let’s say you have 300 topics coming in about a specific vehicle. Let’s say you’ve been calling the vehicle by its engineering name, and your authors have used the engineering name all throughout your content.
Fine. But now the vehicle gets a new marketing name and naturally that conflicts with everything you’ve written to date.
To make matters worse, you’ve given the same vehicle unique names in three different markets. Maybe it has a 123-X suffix in this region, it’s the XB in another region and in this other region it has no suffix.
This is a very annoying problem to have, right?
The engineering name is used everywhere, in all these different systems, and these systems are used by unique areas and departments.
With mass metadata enrichment, this becomes a very easy problem to solve.
You select everything that uses the engineering name, update it to the new marketing name, and add these three new market-specific names.
This is very, very powerful.
And once you render the metadata consistent across assets, it becomes easy to apply VIN ranges.
"This is where mass metadata enrichment comes into play. It becomes very easy to mass-update assets."
It’s an intelligent, enhanced find-and-replace function.
It is exactly that, one that operates across a large expanse of disparate assets.
Instead of finding and replacing within a document, or collection of documents, you can quickly impact a wide expanse of different databases and documents and other assets, as well.
You can find and replace, or you can find and add, or mass-select and then apply a certain metadata.
And you can do this on the topic level or on the publication level.
It can be contextually aware, too. So, in one case you might find a particular piece of information and change it to one thing, but in another context perhaps you need to change it to something else, or something slightly different. The system will work with that, too, modifying the same thing differently – context dependent.
And it works on the display level, as well, right?
If you have a vehicle with two different trim levels, you tie those levels to VIN numbers in such a way that when a technician looks up a particular customer vehicle, the system will instantly know which trim level to show them.
That’s good for the technician, because when they access the information, the product in front of them matches the imagery they see on their screen.
Does that work the other way round? I mean, could these contextually aware modifications extend to curating the level of detail depending on who’s accessing the system?
Yes! That’s another useful thing.
That comes from the user role and the role management system.
Just to pick on something boring, let’s say a vehicle needs a new oil filter.
I go in, as an owner, and I access the system.
The system knows I’m the vehicle owner. It knows it should display the most elaborate version of the information, and it should include all the steps, because as an owner I should have very detailed assistance.
And I’ll be pleased with this, right? Because I’m not changing oil filters every day.
Meanwhile, at a dealership, a seasoned technician logs on, and they also want to change an oil filter on a customer vehicle.
The system says, “OK, here’s this other user, but their user role is that of a technician who’s familiar with our vehicles. Let’s provide this technician a leaner version of the same information, because he just wants us to get to the point.”
It might also look at the use patterns and preferences of that particular user. Then it will display this content with the appropriate detail and in the appropriate way.
So, it will adjust its presentation based on your historical methodology, your user persona, or how your role is set up in the portal.
Well, Claude, I appreciate all this. Thank you for walking us through Service Portal.
It’s been my pleasure. Thank you.
Special thanks to the Marriot Towne Suites Chesterfield.
To learn more about Service Portal, visit tweddle.com.
