Integrating Administrate into Training Operations for Growth

Hi, everyone. My name is John, and we're gonna be talking today about our journey with administrate. I'll give you a little bit of information about my company, and then we'll talk about how we worked on integrating administrate with all of our key systems in order to enable us to grow our training business. So who are we? We are a Fortune five hundred technology in the US. Last year, we trained about thirty five hundred students in two hundred and fifty events or so, and we're on pace to to surpass that this year. We offer training to individual learners. We have learning packages where people can buy multiple courses and types of events at once. And then we have, enterprise programs as well where we sit down with customers and we figure out what type of upskilling does their staff need, how do we get them from point a to point b, what are all the courses that are required to do that, and then how do we schedule that in a way that meets their scheduling demands and allows them to grow their business?

Currently, we're at about a hundred and seventy five courses in our catalog, and that continues to grow. You'll notice two hundred fifty events over a hundred and seventy five courses. That's not a huge ratio. A lot of those courses are not offered super often. Some of them are offered super often. We have a wide range of frequency from once or twice a year to almost every week and everything in between. What were we trying to accomplish here? Really, we needed to make sure that we could transact training in a scalable way that allowed us to integrate with all of our key business systems in a way that meets audit requirements and is robust and automated. So we embarked on an implementation and integration project with administrate to really enable that to happen.

At our company, we have a number of existing transactional models that training does not fit into. We we sell widgets, so we've got warehouses full of products. It's all SKU based. We drop ship those as well to our customers. Hardware sales is certainly a large part of our business. Configuration services, so configuring the hardware that we sell. Professional services, installing and configuring on-site the hardware that we sell, and then subscription services for things like managed services and cloud subscriptions, that sort of thing. So we have a number of different transactional models that were existing in the company. Lots of people had tried to shoehorn us into one of those transactional models or another, and it really turns out that training is nothing like any of those existing ways of transacting.

And so we looked at all the systems we had in place. Do we have anything that allows us to actually sell training and manage it? And the answer was no. Enter administrate. Administrate was that system that that sort of got us over that first hurdle of how do you manage a training business from a training management system perspective. When we think about transactions and transacting training, there's some key transactional differences that we have that that other parts of our business really don't contemplate. For training, you need stuff like dates. When is the training gonna happen? You need a course. Like, what content is someone consuming? You need a location. Is it virtual? Is it in Kansas City? Where is it? You need to know how available that training is because there's a finite number of people that can attend a course.

If you have twenty people in twenty seats in a class and fourteen of them are already taken, you can only sell six more. So that's an inventory related thing, but it's different from simply just inventory. And then we have to collect additional information about the students in order to successfully register them in the class. We need their name. We need their email address, and that's not necessarily information that comes along with any old order. We might have a a purchaser that's purchasing the training for five students, and those five students all have unique names and emails. So we need to gather that information, and none of our systems really allowed us to do that out of the box. We also need the concept of a token. In our business, we think about we sell training to to people for cash.

We also sell training to people in large programs where they might purchase hundreds of thousands of dollars of training at once, and then we chip away at that balance over time or possibly a year's worth of time as they put dozens of people through different training courses. So we need a way to track a balance like that where people prepay, and then we have a mechanism to to keep track of how much they've used and how much is left and report on that to the customer. So that token concept is really important, and that's pretty unique to administrate. It's definitely a key feature that we take heavy advantage of. So administrate really took care of of these aspects of the transactional model that we needed. It handles all of this stuff in the TMS, the dates, the course, the location, registration information, and it has the tokens.

What it doesn't have is a a built in, what I would call, enterprise ERP type of functionality that allows us to plug into other enterprise systems. Some things that we needed for that is we need the capability of pre billing a customer. And when you pre bill a customer, you have to represent that money that you've collected in some way. And so we have a retainer system in our ERP. So if we bill someone ten thousand dollars for training in the future, whether that's tokens that they purchase or it's a class that's coming up in December, we're billing ahead of time. We're collecting that money, and that money has to sit somewhere. So we need a retainer in our accounting system to manage that balance on the customer's account. We also have requirements, legal requirements, and other accounting rule requirements around revenue recognition.

Essentially, we can't recognize revenue because we're on an accrual accounting system. We can't recognize revenue until we've actually delivered the service that we're recognizing revenue for. So it's great that we can pre bill and we can get that money upfront, but it doesn't actually count as revenue until we deliver the training. So that's something that administrate doesn't have built in out of the box, and we needed to think of a way to manage the revenue recognition process and how to get that data into our systems that manage revenue recognition. And we needed to tie the financial transaction to the registration itself. The it's great that we're collecting money upfront, but we need some way of saying this registration with this person in this class is equivalent to this order, quote, unquote, order in our other system, which ties to a financial transaction.

So all of those things have to line up in order to meet our audit requirements and be a an enterprise that that follows all the accounting rules. It was really a challenge to to figure out how to make this happen, because administrate has a lot of these things covered out of the box, but it doesn't have these sort of big enterprise hooks figured out. So we had to integrate. Like I said, we're looking for compliance. Obviously, efficiency is really big. If if we're gonna grow this business the way we intend to, it's gotta be easy to to process transactions without a lot of manual effort. So that was our main focus for this project was enabling these sort of enterprise features in a way that's scalable and easy to manage. We broke our integration down into multiple phases, and I'll say this is this is easier to see in hindsight than it was at the beginning of the project.

But looking back, it slots nicely into a number of different phases here. So the first phase is just basic system mapping. We've got administrate over here. It's gonna be the transitional transactional system of record for training, but we need to map that to our ERP to to handle the financial aspect of things. So billing, some other financial features there. We have a revenue recognition system that's separate from that ERP that needs to get this data as well. We have a commission system that we need to get data into, so that our sellers can be compensated for the training that they sell. And we have a customer master that we need to pull data from in order to make sure that we have the right data and administrate to facilitate these transactions. So the first thing we did is just sit down and figure out, okay, what are all the places the data needs to come from and go to, and how do we need things to link up just at a really high level?

Then we sat down with the administrate team and scoped out, okay, what do we think this level of effort is for this? Here's basically what we're trying to accomplish. Let's talk about ways of designing this and integrating it and get on paper a statement of work showing what do we think this level of effort is. After that, we really started the project, which is where we began doing the detailed design. And so we're talking things like how what protocols are we gonna use to communicate between these different systems? Are there intermediary systems in between that need to shuttle data back and forth? How do we trigger the events in administrate to to push the data into our other systems? How do we identify what those triggers are? What data do we need for those downstream system? What are all the fields that they need? What are the acceptable data formats?

How is that data pushed? How often can we send data? So all all those kind of basic integration considerations. Then we did a lot of development and a lot of testing. The administrate team in particular did tons of development to help us get, the kind of the requirements from basically a webhook and administrate that contains a data package and completely transform that into the data package that our systems need to ingest the data from administrate and get it into the right place. So really not aligned. We had to completely reformat and refactor the data and in a lot of cases, do crazy lookups and all kinds of stuff in the middleware layer to to get that data from administrate into the format that we need on our end.

That that was a ton of development. And then, like I said, tons of testing just as we were going. We would do some codevelopment, do some testing, or we're getting the data we want. After we're done with that sort of development and and testing phase, then we did heavy user acceptance testing. So we got our finance stakeholders involved. We got our sellers involved. We got, specialized QA resources from our, internal development teams involved, lots and lots of people, to do user acceptance testing and extreme levels of documentation so that we can show our auditors that, yes, this was the input from administrate, and this is the output in our financial system that that shows things tie out. After that, really the easy part was the go live and the cutover. Once we had everything built in our UAT environment, we were able to migrate that into the production environment.

And we had some considerations that we'll talk about, with the go live and the cutover as far as timing and, kind of data management. But, really, that was the easiest part of the project, I would say. So looking at phase one, the basic system mapping, I'll give you just a a high level overview of of how things plug in. And you can see administrate sits at the center of this, and that is no accident. It's really the nexus of everything that we do with training. So we're taking customer data from our CRM and feeding it into administrate. We have literally millions of customers in our CRM, and so we don't want to just willy nilly load every customer into administrate. That would be foolish. So we took a different approach, more of a pull approach, where we said, okay.

We're gonna we're gonna enter a customer into administrate that we wanna transact with along with a customer number that matches to our CRM. And when we do that, it's gonna go out and pull the data we need from the CRM based on that customer ID. So that's a it's a one way sync. So we're controlling that inside administrate, but it's very quick. It's within about ten seconds. We get all the data in from the from our CRM into administrate. And then as we transact, we're sending data downstream to several other systems. So we have our revenue system that gets the revenue data when actually we deliver the training. We have our invoice data that goes to our ERP, and that includes invoices for prepayments as well as invoices for for drawing down our retainers. So the way that works is we send out an invoice to the customer upfront.

That goes to them. They pay the invoice. That sets up a retainer in our ERP. And then when we deliver training, we invoice that customer again. That that actually doesn't go to the customer. It's just an internal only invoice. But it basically says, okay. We need you to pay x amount, and it's gonna go and look at the retainers that are available and say, oh, I've got a retainer over here. I'm gonna use that to satisfy this new invoice and, boop, clear it out. We're all done. So that's how that works. It's a double invoice system, but the customer only sees the first one. We've got a link from our ERP into our financial reporting system. We don't have to send data explicitly there. It it just flows down downstream, which is great. And then, like I said, we have transaction data that goes into our commission system as well to make sure that we're compensating our sellers the way that they need to be.

So the next phase of our project was the scoping phase. We sat down and did a basic integration design. What do we want this to look like? How do we want it to work? Administrate went through and did some documentation of the solution and did some estimating and pricing. And then then we sat down and actually re allocated resources after we figured out what was needed. There were about seven teams on our side and about thirty five people on our side. I would say this is symptomatic of a large enterprise, not because it was that much work, but because we have that many specialized roles. You'll see the team on the administrate side is much smaller and and more nimble. Then we worked through the contracting and the scheduling process. And, again, we were the slow the slow poke in the scheduling process, the long pole and the tent, whatever you wanna say.

It's just hard to get that many people up and running at once. But we did, and we got everything assembled and kicked off. So that was that's the the first step of our project. As far as the integration team is concerned, couple of these folks are on the phone with us right now. But, Ian Brown is really the all star of the integration. He did almost all of the development work and the conceptual, architecture of how we integrated this. So he was absolutely critical to this work. Gary was his right hand man on that in the US when we needed more round the clock type of effort or when he was not available. Cole is our customer success manager, really our sponsor of this entire project in helping us get it across the finish line. Without Cole, I think it would have been a lot harder.

And John, in addition to being the CEO, John was a, I guess, I would say, the the brain trust as far as how have people done this in the past with administrate, what are some best practices, how do we translate this genesis of an idea into something that's actually actionable. So so John was really critical to the project besides being just the kind of the head sponsor on the administrate side, on the technical details too, very important. And then the support team. As we work through the project and into the go live, the support team was working behind the scenes to get spun up on how everything works and, be there to support us on day one when we went live. On our side, we had, as I said, a lot of people. We had our training director as our sponsor, also very much in the details. That was really helpful, and I I could say pretty confidently that if you have someone like this in your organization, they should be involved, and you should be thankful because it makes it a lot easier if the person who's sponsoring you also has, you know, deep, knowledge of the transactional models and the types of integrations that you need.

Then we have myself, the training systems manager, and we have a bunch of teams. So we have a revenue systems team that was involved, a finance team, which you'd think would be the same, but it's not. We have development teams that did work on various c d systems on our side. We have UAT testers and a QA testing team, which, again, is separate. And then we had a bunch of business users who are day to day users of administrate that helped us simulate all of the different transaction types that we are looking to put through. So phase three was our detailed design. And so the first part of this detailed design was mapping the data. And so we talked to our internal teams about how to how to get the data that they need and what format they needed.

From each team, we got, eventually, a a list of data fields and the data type that's required, field lengths, all of those things that we need to supply in order to successfully turn these transactions into a a transaction in our systems. And so in a lot of cases, that was a meeting or two meetings or multiple meetings with these various teams who represent the different systems to get this design together. Of course, they had some documentation to start with, but there was a lot of customization that we required. Things that the training does that are unique that, you know, we just hadn't contemplated as a business prior to this point. Oh, yeah. I guess we do need a way to track, you know, x y z data point that we've never needed to track before. So some of that stuff went into this as well, and we came out with basically a recipe for each of the four downstream systems and what data they required.

The next piece of that really was mapping those inputs on our side to the fields in administrate that the data needs to come from, which was not as straightforward as as I was expecting, to be honest. There are lots of ways to skin a cat when it comes to drilling in and finding the data in administrate. So I spent a lot of time querying the API and just getting to know the data model on the administrate side so that I could make sure that we're actually pulling the data that we want. And even we I got it wrong a fair amount. We had to go back and remap some things when we had new requirements come up or did some testing and discovered, oh, that doesn't work the way we thought it would. So that was a fairly large effort. In the middle, we have some additional systems that sit in between administrate and our core systems.

We have a a Workato instance that administrate manages that does the lion's share of that data massaging so that when the data comes out of administrate, it gets put into the right format and the right field names and all that stuff to be absorbed by our systems. The other thing we have in play is a service bus on our side. So I'll show a diagram of this in a little bit here, but that that sort of sits in front of our core systems and helps parcel out the data and get it where it needs to go. So both of those sit in between administrate and our core systems. And then really defining the triggers and the filters to get the data that we need. That was a much more complex thing than we anticipated because of all the different transaction types that we have and the different reporting requirements that come along with each one.

We have our initial billing. We have our revenue recognition. There's differences in the payment methods that people use, to transact. And then we had a lot of edge cases. What if somebody buys a lunch, that catered lunch that comes along with a classroom rental? Or what if we wanna sell, a test voucher along with a a seat in a class or whatever? Training credits, again, a big thing for us using the administrate tokens. So lots of different moments in the life cycle of a training event and administrate where we might want to stop and pull data and send it through. So that was a a fairly large thing. It's just deciding when is the right time, what what's the trigger for this data to be sent.

Just looking at the data flow here, basically, the way it works, we have our administrate again as the central hub. Based on those triggers that we defined, it's sending out webhooks. And so some of those triggers are things like invoice created or learner attended session, learner results recorded, those types of things. So whenever one of those events happens, we're looking to see, okay, does it match these criteria? If an invoice is created, is it a a prepay customer versus the post pay customer? Is it for training credits, or is it for an event that someone's attending? So there's a lot of filters that go into that to to make sure that we're getting the right data at the right time. But regardless, those come out as webhooks based on those events that I mentioned. Those go into Workato, which helps get the data into the right format.

Workato makes an API call to our service bus, and that service bus does some special things. If we're sending a customer ID through as part of the data package, it's gonna go query our customer master to pull some additional enrichment data about that customer. What who is the account manager and what ZIP code is their billing address in. And there's some lookups that happen behind the scenes inside the service bus to help enrich that data before we send it through into our core systems and actually insert it into our tables. So that's the general workflow. And, of course, we've got some good logging that goes from Mercado back into administrate. So we're writing we're writing logs that include the full data package for each of these webhooks. So all of the the results basically of what we've created, the data package from Mercado to our service bus gets written back to administrate.

So it's really easy for us to go in and say, hey. I see that Joe Smith attended this class on April fifteenth, and it says he paid two thousand dollars for it. And we can see all of the data right there in front of us confirming that the data package actually went from Mercado into our service bus. It's also writing back an invoice number into administrate. So we have that invoice or Workato generated invoice number that gets written back to administrate so that we can tie that off as we do our month end reporting as well. So that's the the general overall data flow. I'm gonna talk a little bit about triggers here for a second in a little more depth. We have about four different transaction pipes that we're sending data through for.

We have retainer invoicing. Hey. We're gonna bill the customer now to set up that initial retainer, the pre bill. We have the retainer drawdown. So someone's taking a class, and we're actually pulling it from that retainer. We have customers where we can't pre bill. By contractual requirement, we have to wait until after the class is delivered. So we have those post delivery invoices. And then we have credit notes where, you know, someone for whatever you know, we've made a mistake in a transaction or dollar amount is wrong or whatever. In some reason, we need to back it out. And so we have that capability as well. Some Some of the triggers that we use for those are the creation of the invoice and administrate, students' attendance being recorded. So the first day of any class, we get a lot of data packages flowing through to say, okay. Student has attended a class.

We can now recognize that revenue. When we redeem tokens, that that sends data through for a retainer drawdown, and then we have a way to manually flag events as well to say, hey. This event has now happened, and we're going to, recognize revenue for that private event. For post delivery invoicing, we rely on the results being recorded, so pass, fail. If either of those is recorded for a student, that data package gets sent. And then for private events, we finalize the invoice and administrate, which sends that data package through. And this is how we tackled this. There are lots of different ways to skin this cat and administrate lots of types of events that can happen. And I think if you're contemplating something like this for your business, I would say take a good look at your workflow and the types of things that happen in administrate as you work through a transaction end to end, and then find those areas where every time we every time we invoice a customer or every time we generate an invoice and administrate, we need that invoice to go to the customer.

Okay. That tells you your trigger. Or every time we x, we need to y. That's how we landed there. When it comes to variables, these are what drive our filters. Hey. We're creating an administrate invoice, but we don't necessarily always want to send the data. We only wanna send that data if it's creating a a new retainer, for instance. So that might pull into into the logic, the pre bill versus post bill question. It also pertains to the payment method. There are certain they they pay for a credit card. It's always a prepayment. But if they pay with a check, it might be a post payment. So there's a lot of if then if then if lots of nested logic there when it comes to these variables. And so we we took these different variables, so funding source, payment method, pre versus post, and then what did they buy.

And these factor into the filters for each of the triggers. So as you can imagine, the the number of combinations of things that we have is pretty large. It's four four different main types of data packages that we're looking for about, I don't know, seven different events that we're triggering on, four main variables that we're looking for. So when you combine those, it starts to get pretty big pretty quickly. And just to give you an idea of what this looks like, this is our final solution. And you can't even read it, but I'll just describe what it is. So these are our different events along the top. So we've got stuff like invoice created and student attended for a session, student has passed or failed. And then we're doing some logical checks. Like, was this a a prepay customer? Yes or no? Did they pay with a credit card?

And then we've got this flow that takes us down to the different data packages. And so we've got a data package that goes to our financial system for billing here. That's this row here. We've got a data package that goes to our revenue system once to initiate the sales order that kind of sets up the revenue, and then, again, to send a revenue event to say this revenue has now occurred. And then we have our commission system here at the bottom. So for each of these, in most cases, we're sending data to four systems sequentially. So we went through and figured out our triggers and our filters. And if we get to this box here, then that means that we're doing the rest of these boxes in sequence. And so we went through and we number we these are we have all these different filters at the top that we keep track of in a spreadsheet. We have different JSON files that are marked here for each box, and I think we're up to forty six or forty seven different JSON files.

So it's a lot of complexity to manage, but it does exactly what we want. That's that's where we landed with this. So it it was a labor of love. We got there, but, pretty complex. Five customer systems, seven triggers and administrate, thirteen unique flows or columns in that chart, forty five JSON packages with specific data attributes. I hope that your system is not as complex as this if you decide to do this. So getting into phase four of the development and the testing, this was all just conceptually figuring out what we wanted this to do. And, certainly, this diagram changed as we did our development and testing, but we started with something very similar to this. As we went through the development and testing, first, we started with a mock up of the JSON data.

So I took a sample transaction for each of those forty five JSON files and said, okay. This is what we want the result to look like when we send the data through to our downstream systems. And these are the fields for each row of the JSON file. This is customer ID. Where do we get customer ID from in administrate? Oh, it's from first, we have to go and look at the delegate, and then we from the delegate, we go to the registration. And then from the registration, we go to the account. And from the account, it's a custom field on the account. Mapping every every field of those files, and, typically, these files had between twenty five and a hundred different fields in them. So it was a fair amount of work to map for each of these forty five files where does this data come from because it's different for each. But, anyway, so we got that mocked up, and we were able to hand that to administrate and say, okay.

This is the way we want it to look when it comes out of Workato and where we want the data to come from. And then they had to go figure out how to make that happen. That was certainly a a big amount of effort on Ian's part. It was just looking at this crazy diagram and these files to try to figure out, k. How do we get this to actually happen? So he did a lot of development in administrate and Mercado to get that ready. In parallel, our team was working on our service bus to say, okay. We've got these data packages that are gonna be incoming. What types of data are we expecting? Where do we need to send this data once it arrives? In a lot of cases, we could use existing API functions to do that, but in some cases, we had to write new features or special add ons that would handle the data in a new unique way. So they were working on that in parallel with Ian.

Once both of those parties were done, we started our testing. And so we we just went JSON by JSON and said, okay. This is JSON number one. We're gonna run a test and try a transaction and administrate, do a new opportunity, push it through, see the invoice come out. Do we have all the right information in the administrate invoice? Does that get translated into Workato? Does the JSON file look right going into our systems on the other end? We did that times forty five, and each of those flows has to happen sequentially. We're doing one package, and then when that's successful, it moves to the next package and then down. So there's a there's an iteration element here too that's just because you get one doesn't mean you're gonna make it the whole way through the flow. Lots of testing, Fair amount of bug fixes just because there's so much detail.

So we we had some things to to fix. And along the way, we discovered some enhancements that we needed, special business cases that we hadn't considered along the way that we needed to allocate or account for. So that that factored in as well, and then we're back to remocking up the JSON data and doing the development. And so it really was this sort of cycle like you see on the screen. But it was pretty rewarding. It was nice to see things come to life. Once we got through the heavy lifting of mocking everything up, and then we'd turn Ian loose for a few days, and he'd come back and say, how about this? No. Yeah. Okay. I think we're there. That was pretty nice to see it all come to fruition. Then we moved into user acceptance testing. So when we, on the sort of, I would call the core team, were satisfied with how things looked, then we brought in all of our testers from the enterprise so that we could prove that the data that we're pushing through is valid and represents the actual transaction in the proper way.

And we could make sure that we are billing the customer for exactly what we need, that we're gonna get paid, the amount that we need to get paid, and and all of that stuff. So for this process, we started with just getting all the users on board. So that's this included, like I said before, a lot of testers from our development team, but also business users. So we have a delivery management team within our training organization that was heavily engaged. We had my team, the technology team that was heavily engaged. Our sales team, we had a presales group that was pulled in. So, really, a lot of different people, our management team, were looking at this and doing this testing. Great engagement from those people. We went through and we developed one of our QA resources as an expert at developing scenarios, and she helped us document and figure out the twenty four tests that we needed to run to satisfy ourselves that everything was working the way that we needed it to.

We developed these twenty four scenarios. What are the inputs that we're putting in? What are the expected outputs and why? And how do we validate that we actually got the outputs that we desire. We ran our tests. We did ninety two tests in all, which actually I feel like is not too bad for twenty four scenarios. Some of them we had to do more than once. Overall, I would say it was pretty successful and mostly what we expected. Obviously, we addressed the defects. We had a great defect tracking system that we used to get those over to Ian. He was great at playing whack a mole with the things that we sent him and and getting those fixed, and we would retest again often the the next morning. I will say that's a benefit of working with someone who's in a different area of the world is a lot of times we could do our testing later in the day in the US and get Ian notes at the end of our day.

And oftentimes, by the time we logged in and get him logged in again the next morning, he already had stuff fixed because he had been working for six hours. That that was helpful, actually. So after we got everything fixed and all the defects addressed, we completed all of our documentation, which is fairly extensive. You've seen a little bit of it, but we've got a lot more that just helps us keep everything straight because it is pretty complex. And then we had to get our sign off by the business process owner. So that's people like our our finance team, our revenue recognition team, our management team within the training organization. Really, anyone who's involved, the sales team, was asked to sign off on what we had put through. So we were by the time we got to the end of this testing, we were pretty confident that everything was working as expected.

So that that kind of got us ready for phase five, which was the go live and the cutover. And it was nerve wracking. We picked the date, and we were sure that we were ready to go on that date. You're never totally sure that everything's gonna be perfect. What we did, actually, is we enabled all the integrations in production, but we spooled up all the data in Workato. What that meant is as events happen in administrate, so as we had people attending class, as we were selling training, all of those events were happening, and we were sending our data packages through to Workato as of the go live date. We picked the first day of the month for that. So we're sending data through. We're looking at it in the logs, inspecting that data to make sure that it looks right. And it's just sitting in Workato at this point because we weren't ready to receive it yet in our systems.

And the reason for that is we had to actually transfer retainers from a legacy financial system that was involved prior to this new system over to the new financial system and get all those customer balances converted to the new system. So we couldn't pull down from a retainer that didn't exist, essentially. That was the main problem we were trying to avoid. We worked behind the scenes for about the first four days of the month to get all those balances converted over. Big program customers that have lots of, training credit balances, people that are just scheduled training in the future. All of those are represented by retainer. So going through and auditing everything, making sure it's all correct, and moving that money into the the appropriate buckets in the new financial system.

So that once that was done I guess that's what that bullet was about. Once that was done, that allowed us to move our receivables from the legacy accounting system over to the current accounting system. Anything that was owed us was moved over. And then we once all the money was in the right place, we sat down with Ian. We just made a a Monday morning of it and said, okay. Let's take the first transaction that's waiting in Mercado, and let's play it through into our systems. And we he clicked the button, and we all watched and waited. And people were looking at our financial tables and checking our revenue recognition and everything. We had probably eight people on the phone validating all this data.

Okay. That was right. It looks right. Let's do the next one. So we went through and we processed all the queued up transactions, which I think there were maybe thirty or forty. It was not a huge number. Got through all of that. And once we were satisfied with everything that went through, we enabled our automatic processing in Mercado. So from that point forward, everything that happened in administrate went real time, administrate, Mercado, service bus, financial system. So that was a switch that we flipped. And like I said, I think it took maybe four or five days, at the beginning of the month. There really was no there was no rush on our side because we knew that we were queuing up the data in Mercado, and that that helped us sleep at night knowing that we could take the time to get the data right so that we were ready to start processing.

From there, it was miscellaneous bug fixes. We certainly had some things, especially that first month, where, you know, oh, this is a new situation that hasn't come up. Let's see what happens when we run through. Oh, yeah. It failed. So we have to go back and think about how do we need to adjust our filter logic or what do we need to do in Verkado to make sure that the right data gets to the right place. Now we're about, I don't know, eight months in with our integrations. They're running really smoothly. It's been a long time since we've had a a tweak that's required for a bug fix like that. We've had some tweaks in terms of, I guess, I would say enhancements to help us expand our business into things that were not part of the original scope of the integration. And Ian has been a great partner in getting those things accounted for and and built as well.

That's the project as a whole. So when we think about what we wanna do in the future, these are the things that we have in place today. Next on our list is tying our CRM into administrate for quoting and order processing. One of the problems that we have is we have a very large Salesforce, and those people are not experts in training by any means, nor are they experts in administrate, nor do we wanna license all of them administrate. So we need a way for those people who are, I guess, I would say entry level sort of novice types of training people, sellers, to be able to be walked through in a way in our CRM that's unified with the other things that they're selling that helps step them through the process of thinking about how to transact training.

Okay. Now is the time when you give us the names of the people who are gonna come to class, and here are the number of seats that are available, you know, and not let them sell seats that don't exist. Those types of things. So we're thinking about what do we need to deliver from administrate into the CRM to present to those sellers so that they know, the information that they need to know in order to be successful selling. And then when they generate a quote or an order, what do we need to flow into administrate into the administrate opportunity system, which then becomes or of the the data for all of these things that happen downstream. The the side benefit is of that is we get to configure a lot more rules around the types of training and transactions that we can allow in the CRM in ways that administrate CRM or yeah.

Administrate CRM is really not built to do today. There are more features in our CRM that we can enable that would provide guardrails for people so that they're not accidentally processing things that can't be processed. So that's next on our list. We're also working on an ecommerce experience for customers using the administrate WebLink and later, hopefully, some API customized web design as well. But that will enable customers to self serve on our website, to enter their credit card, and self register in our courses so that we get the salespeople out of those small onesie, twosie transactions and help them focus on larger scale programs for large customers or people that wanna have private classes or on-site events. That's where their time is best spent, and customers are perfectly capable of self enrolling with a credit card on the website for a one seat purchase.

So those are the sort of the next couple things that we're looking at as a company to help leverage, administrate to grow our training business even more than it already is. So just to wrap up, lessons learned here, getting the business stakeholders involved upfront is really important. We did a pretty good job of that, I would say, but it it helps you capture all the requirements. If we have people that are coming in at the last last phase of the project, you're gonna get some unpleasant surprises with things that you might not have thought about during the design phase. So getting those people involved upfront takes a little longer to get the projects spun up, but I think it pays dividends on the backside as you have all those requirements met out of the gate. Having consistent engagement from a project sponsor is really important too.

We we're lucky that our director is very hands on and understands everything that we're doing with these transactions and with the integrations, so that was extremely helpful. And I would say on the administrate side as well, the consistent sponsorship of Cole and John and Ian to help drive this forward too. Having people that can stay in lockstep through the length of the project, really valuable. Obviously, expect significant surprises. This was we did expect significant surprises. We had a lot of surprises, probably more than we thought, but that's what discovery is for. And our discovery continued well into implementation. We got pretty far down the road before I think we could confidently say, okay. We've discovered all the things that we're gonna discover. Little things just kept popping up as we went through.

What about this odd scenario that happened today? As we're doing our transactions, just business as usual off to the side, people would say, oh, this just happened today. Oh, we don't have that accounted for. So that was a learning experience to just make sure that we're documenting all those requirements as we go. The cooks in the kitchen thing, that's real. As I said, we have thirty five or so people on our side that were involved. That's really a lot, and it slows us down. It was a a major contrast with the administrate side who had two to three cooks in the kitchen at any time, and it was a pretty big discrepancy in terms of velocity between the two sides. So small is good if you can. Resource consistency, if you can have the same people involved from start to finish, that is really great.

Handoffs slow you down. They introduce errors and cause all kinds of problems. So keep those same people if you can. The test scenarios, we were lucky to have someone that I would consider really a testing expert to help us write those scenarios and think about are we getting at all of the all of the details of this transaction type with this test. We had we ended up with twenty four tests for roughly four basic transaction type, but there's a lot of nuance there. So having that person who was an expert was really great. If you have a person like that in your organization, bring them in early, help them have them help you get those tests written. If you don't have someone like that, think through what are all the different variables that can change and take the time to to make a different test scenario for each combination of variables because you never know what you might find.

We certainly found cases where we thought, oh, we're awfully glad we have this test. Real time testing. This is a really big one. We had daily meetings for testing, and I would say we were on the phone three to four hours a day every day for a couple of weeks. Getting those people on the phone sounds really expensive. And in some cases, we had ten, twelve people on the phone with us all at once. One person driving in administrate, one person driving in Mercado, one person looking at the data as it comes through on our systems. But having all those people plugged in at the same time and being able to do that real time data flow and validation was it was the only way I would do that. Trying to get people to to do things asynchronously, I think, at at this scale, it's just not it's just not successful.

So that's probably my biggest takeaway is get people on the phone together. Take the time to simplify your architecture before you develop if you can. When we look back at our architecture, as you saw, it's fairly complex. I haven't taken a lot of time to think about what we could have done differently, but I know there are things that we could have done differently to help modularize and simplify. If If we had to do it again, I think we would maybe take a slightly different approach, spend some more time upfront helping develop modules that can basically work together to achieve the outcomes that we need at at the more more granular level. And then the biggest thing, thanks to Ian. Ian was a trooper. He worked so hard on this project, was there every day with us in the trenches figuring stuff out, being a great partner.

I would say anyone that you work with at administrate, I would anticipate would have the same level of commitment that we saw from Ian, but the whole team has been great. But they were key in getting these integrations built. So that is that's my lessons learned. And that's really my presentation.

How important were the financial sales integration pieces of administrate to the success of the project because, you know, those are things that people typically don't associate with a learning product or platform. Right? And and do you feel like that, you know, that is critical? Do you feel like it's a nice to have or, you know, maybe just I I think that that question, that piece of administrative is sometimes not appreciated very well with people making an evaluation in a sales, setting. And and so yeah. Just kind of maybe some thoughts from you on that. I think for us, it it ended up being critical. The the built in functionality and administrate is good, but it doesn't have there are some things that it can't handle today, like revenue recognition at the time of delivery and, you know, some of those types of, I guess, more nuanced accounting factors.

So for us, it was really important that we had the the basic, I guess, I would say architecture of the financial system inside administrate to bolt onto with our integrations. Without that, we would have had to develop this all totally from scratch. So, you know, that was that was the starting point that we needed, and I'm not sure anyone else would have been able to, supply something similar. As far as,

you know, transacting and administrate is is not necessarily the first thing the platform was designed for. You guys have a a pretty great opportunity system that allows us to take sort of a training idea that someone has and turn it into an actual registration or an event or whatever is kind of being being sold. So the the opportunity engine is great. It plugs right into the into the financial transaction engine inside administrate. And so it was kind of a no brainer for us to use that. I know a lot of other organizations use administrate in conjunction with some other transactional system. So they're transacting in Salesforce or they're transacting in, you know, some other ERP or or some other way, that aligns with maybe some other way that their business operates.

For us, the other ways that our business operate operates is, like, they're all completely foreign to training. So none of those systems was a good fit, and and the idea of customizing one of our existing systems to meet this purpose was such a heavier lift than customizing administrate to to get us kind of over the hump of the additional work that we had to do to get our accounting right. So a lot of I I know a lot of other companies, you know, transact elsewhere and then and then use administrate just to kind of purely manage the training. For us, it had to be it had to be the same system because we just don't have any other place that we can transact training. So what I wanted to bring up, John, so this project or this presentation you just did was about a big project that was complex with a lot of workflows and use cases and a lot of people involved.

One of the things that maybe you can speak about here for a for a minute or two is something you and I talk about a lot on our calls, and that's our developer portal. And, yes, you guys have done a lot of integrations, but you yourself have used the developer portal, leveraged it to go out and build automations, just to make you your job easier and your team's job easier. Is there, some stuff that you can share on that front with us? Yeah. Absolutely. I mean, I'm I've been in there multiple times today. We we we use it so heavily. Without the API, we would be I don't wanna say dead in the water, but we would be way less efficient, because we can write custom scripts that do everything that we need to. One of the one of the more, I guess, elaborate use cases we have for for the API and scripting is, you know, we resell courses that other partners of ours teach.

So not everything that we put in administrate is something that's taught by an employee of our company. And so we have partners that that have schedules that are published or that they send us that we need to represent and administrate so that we can sell into those classes that aren't our classes. But in order to do that, it's a constantly moving target. I mean, we've got half a dozen or more partners. They all have a schedule. Each schedule might have a hundred classes on it, and they're constantly adding new classes, removing classes. The classes are filling up. They've got classes that go from public to private. There's, like, all these different ways that the stuff can swirl around. And so we needed a way to track all of that reliably so that we could represent factual information in administrate that that actually represents what those classes are.

So I wrote a script that basically ingests a a schedule from a partner in a particular format. We get a CSV file, and it'll go through and say, okay. Well, what do we have on our schedule? What do they have on their schedule? Do we have first you know, do we have classes that that are on their schedule that aren't on ours? If so, let's add them. Are there times that don't match? Are there time zones that don't match? You know, have those have those things changed?

Is is the class listed under one partner, but it's really being delivered by another? You know, there's a lot of these kind of parity checks that we do to make sure that we have the right information. And then when we get through with that that direction, we go the other way. And we say, okay. Is there anything on our schedule that's not on the partner schedule anymore that they removed or whatever? And then so we make a list, and these are all the classes that that are on the schedule that the partner doesn't have anymore. Some of these classes might have people registered in them already that we need to contact and help them move to a different class. So the script basically goes through all of that logic and helps us compare line by line all the way down for a given partner, you know, put their schedule on. So we have some partners that send us a schedule weekly, some that send every two weeks, or, you know, sometimes it's, like, once a month. But we'll run that script whenever we get a new schedule and just put it through, and there's always changes.

It's it's finding, oh, this time zone is wrong here or the you know, this class moved from this week to this week or or whatever it is. So, that's that's probably the best example I have of of, like, extreme automation, that we've built for for ourselves to to just keep ourselves sane because there's there's so much when you've got hundreds of events that you're managing like that, you can't do it manually. So, yeah, I spent a lot of time writing scripts, developing, API tools that we can use to, to help ourselves keep things efficient. Is is the ambition to ten x, twenty x, one hundred x what you're doing today, and do you feel like you got a good foundation to do that? Or Yeah. Great question.

So so, yeah, we are looking to scale, I would say, you know, ten to fifty x in the next five years. And there's a number of things that that will help us do that. The biggest thing is the ability to transact at scale and administrate with these integrations. So what we've built is the foundation for that to happen. Without that, we would be just throwing people at this problem. So, that that lays the groundwork for us right away to say, okay. This this is the the tool that we need to to kind of take us to the next step. The other pieces of that are, like I mentioned before, you know, the ability for our large group of sellers to to use our CRM to pipe leads and and sales into administrate in a way that doesn't require them to know about training or about administrate or even they don't even need to have heard about administrate.

So it kind of democratizing the sale of of training out to the thousands of people that that can help us sell that, is a huge game changer that we're looking to roll out, you know, as soon as we can, basically, as soon as we can get that integration done, get those sellers out there on the street, selling training to everybody they talk to. And then the ecommerce as well, you know, being able to to point people to a website. It's great that we can have our schedule published on the website right now like we do, but we don't have a way for them to transact today because of some limitations, you know, that we have, with with integrations and our financial system. So so we're looking to to get over that hurdle sometime in the next three months or so to to to get ecommerce up and running. And so between the the much larger Salesforce and the ecommerce capability, those two things, you know, should be able to, take advantage of the integrations that we've built to help us scale dramatically.