“Service Portal” can be taken as a general term or product category. At Tweddle Group, Service Portal is the working designation for a specific platform developed to address specific business needs and customized for individual clients. As often happens with innovation, Tweddle Group’s Service Portal first came into being in response to a unique problem statement—in this case, EU legislation—and grew to address a much larger industry need.
Tweddle Group Chief Business Development Officer Claude Vanbeveren may be one of a few people who know the Service Portal solution better than anyone. Working then as the head of Tweddle Group Belgium, Claude collaborated with Robert Coccoluto and the Tweddle Group Italy team to create this radical new approach to product information. It offered remarkable new efficiencies and new levels of information accuracy.
In part one of our interview, Claude recounts Service Portal’s early days of development. And he discusses the EU regulations that made the platform a necessity.
For anyone unfamiliar, could you give us an overview of Tweddle Group’s Service Portal solution, what it is and what it does?
Absolutely. Basically, you give it a product—either by clicking through it or by entering a VIN or some other product code—and that opens up a curated access door to information about the product, typically based on your role which is automatically tracked by the back-end.
The Philosophy Behind Service Portal
So, it presents service information…
Ah-ha, not so fast. That’s one important distinction to make right away, in terms of the philosophy behind our approach.
As we see it, there’s no such thing as owner’s information, or repair information, or warranty information. In our view, at the raw level, it’s all information—technical information about a product.
That information can tell you when a product was produced, when the warranty started, all the warranty repair data about that particular product. These areas may sometimes overlap because, you know, a piece of repair information could also serve as owner’s information if it’s being called upon by the owner, and if it helps the owner resolve an issue.
So, it’s all just information and it can have different uses or different applications depending on the context.
“There’s no such thing as owner’s information, or repair information, or warranty information. At the raw level, it’s all technical information about a product.“
How does the system decide what data is relevant to which user?
To resolve that question, you first have to build and store the information as discrete modules. And then you use tags to differentiate those pieces of information.
The tags provide a means for slicing and dicing information. These tags might also determine where you’re going to serve that information, how it will be presented, and who gets to see it.
Well, it’s something of a misnomer to think of it as a hub of service information. It’s more than that.
The service portal is there to serve information. The “service” of the designation refers to its ability to service people in a wide variety of roles.
Here’s the critical thing: you have content associated with a product. And you will serve that content through the Service Portal.
Auto-Curating Information Access
Got it. So, it registers a log-in by a particular user, it looks at who’s coming in and what they should have access to, and then it responds accordingly?
That is correct. It accounts for your specific user role, where you’re coming in from.
And it not only curates the data accordingly, it also gives you a persona which maintains and acts upon a record of your preferences. Those preferences might dictate how information should be portioned out, or how that information is being served.
One user might get different information access and a completely different interface than another user.
This part is exciting because we all have our own unique preferences. We all like to access information differently.
Some people like pictures. Some people prefer brief snippets of information. Some people want lengthy, detailed text—they expect the whole story up front. Some people like moving images, video. Some people prefer an almost gaming-style interface.
Some people like to dig in and tell the system, “This is what I need to know,” and then they expect to receive exactly that. Other people lean more toward, “Hm, I know there’s a lot here, so let’s explore this content,” almost an Instagram-style approach. They want to see this one particular video and they’d also like to see all the other videos that are topic-related.
Okay. It sounds extremely interactive and profile-based.
Very much so. And within that, we can let them see the information which people they know, or people who share their particular role also found useful. “Let’s have a look at this bit of information because one of my colleagues recommended it.”
That’s pretty remarkable.
I agree! We’re moving in a direction where Service Portal can almost behave the way social media behaves. The only difference is, it’s focused on your particular product. You use it to repair your vehicle, maintain your vehicle or get to know your vehicle better.
If you were to purchase a product secondhand, you might wonder, “Where has the vehicle been? What’s been done to it, what work has it undergone?” Service Portal will show you, okay, 11 months ago it underwent this type of maintenance, and so on. Or it may alert you—this vehicle is due for an oil change. Maybe the brakes are due for replacement, these types of things.
I could use that. All I have is the little sticker on the windshield and, you know, the recommended next oil change was 25,000 miles ago. I should probably do something.
(Laughs) Yes, then this might be good for you.
Creating Service Portal
So, how did Service Portal come together?
It really emerged from the implementation of an EU legislation called the Motor Vehicle Block Exemption Rule, or MVP. This took place around 2006, 2007.
You can think of MVP as the European version of the Right to Repair Act, and since passing it has been continually extended.
Toyota was using their existing service information setup, which was very flexible, but it was kind of old technology.
The European Commission said, “OK, because of this new legislation, now you need to share your technical documentation with the independent repair outlets.” They issued standards for pricing, they issued specification standards, and they even built standards around a required range of search parameters and criteria.
Toyota’s existing solution didn’t quite meet all the existing requirements, and that’s where Tweddle Group Belgium and Tweddle Group Italy got involved.
We knew printed manuals, right? That was our primary business up to that point—authoring and printing manuals. And in order to produce such content we’d become experts in XML. We knew XML would be critical to meeting the demands of the new EU legislation.
We started to build this thing at a fairly low scope, just to meet the minimum legal requirements.
And, I should say, those minimum legal requirements were no small matter, because if a company didn’t observe those requirements closely the fines were huge.
I think, in fact, a company could be fined up to 3% of their annual revenue for non-compliance.
You can imagine for a midsize OEM 3% of your annual revenue is a substantial amount of money.
Did XML provide the bridge, then, as Tweddle Group went from static information to a digital information portal?
Yes, XML provided the core concept, one which we knew would work. In a situation like this, where something is so new, you build as you go, but if you have a strong guiding principle… you know [laughs], you can move with some confidence.
“The service portal is there to serve information. ‘Service’ refers to its ability to serve people in a variety of roles.”
And it worked?
Yes, it worked. We pursued a more practical approach and one of the appealing things about our solution is the allowance it provides for reusing and repurposing information.
Repurposing Information
What’s the benefit of reusing and repurposing information?
Well, you have to understand how a lot of companies approach this sort of thing. The information is often siloed in different departments, and so let’s say this area needs to create this information, but this other area is producing some overlapping information, and now you have two areas producing different versions of the same information.
That’s troubling right away, because each iteration will live its own life, so to speak. They’ll both be written differently. They’ll both require their own maintenance. You’ve got all that work being done twice, at least, by two different areas. It’s a waste of resource time.
But as you can see, it’s also a threat to information integrity. Because there’s a component which is covered by these two duplicated pieces of copy, and it’s living its own life as well [laughs]. And if that component changes, you might see one iteration updated accordingly, but not the other. Now one of these versions is accurate but one is out of date.
Multiply that across all the possible components in a product and you can see how that creates problems. Because now you have many pieces of information with different verbiage all speaking to the same components, contradicting each other, some up to date, some out of date, and you have all these people managing all this contradictory information.
It’s a mess.
Right. It’s a mess.
It’s much more practical to rely on discrete, authoritative modules of information stored in a central repository.
If the information is correct, you author it once and reuse it anywhere else it’s needed.
When it comes time to update that information, when the engineering or the design of that component changes, you update it once and the system automatically updates that module wherever it appears in your digital ecosystem.
This has a few benefits.
One, you greatly increase the integrity of each module of information. It’s not living off in solitude, you know, with its own caretakers, oblivious to everything else going on.
Two, you greatly reduce the amount of resource hours required to author and maintain that piece of information, because you don’t have all these separate teams caretaking different versions of the same information.
And three, which is best of all, it becomes much easier to locate a module of information in an accurate and up-to-date state. This is huge, and this has a dramatic, positive effect throughout an organization, because there’s less confusion, less frustration and less wasted time involved in finding what you need to know. 
Finding bad or out-of-date information is not good for a consumer or a technician. Finding multiple, contradictory versions of the same information is even worse.
For internal teams, it’s exponentially more frustrating because they interact with this content on a daily basis. It just becomes this constant battle to find the right information.
So, this was on everybody’s mind as you developed the platform…
Very much so. We began working with the Toyota Technical Documentation and Homologation team. Together, we designed what would become known as NGTD, or the New Generation TecDoc.
We were dealing with two separate platforms, right? One was serving the independents, the other was the authorized corporate platform.
We said, let’s move everything into one central repository, and then depending on the user the system will pull the right information—for them—from the same repository. This is the XML component at work, right? XML is how we made that happen.
And depending on the type of user you are, whether you’re working at an independent or for the OEM, you’ll encounter a different interface. There’s the authorized interface over here, and the independent interface over there, each with its own unique information curation, each with its own appropriate access privileges, but it’s all drawing from the same authoritative storehouse of data.
Flash-forward, we’ve been serving both the independents and the authorized platforms since 2017.
END OF PART 1
In Part Two of our discussion, Claude looks at everything Service Portal can contain, the various users it can serve, and why it’s so good at paying for itself.
