Daniel: Thank you very much for joining us today. I’m joined here with Oliver from Zegal. Oliver Boote is our Head of Technology and Operations at Zegal, and Ollie is going to have a chat today with David Lee, who is Technology Director at Nexus International School.

David and Ollie have been working very closely. David’s team have been implementing Zegal at Nexus International. Quite a rush deadline, actually, because the team started implemented and started issuing student contracts all in a relatively tight, timeframe. So, both Ollie and David are recovering from a lot of weeks of work, which culminated last Friday and it’s Monday morning now.

So we thought we’d gather in and have a quick chat about how things went and get a little understanding of the situation before Zegal, what was happening at the school, how the implementation went and what the challenges were, and then also what we’re looking forward to hopefully achieving, now Zegal is in the school.

Thanks David. Thanks for joining us. So David, before implementing Zegal what were some of the main pain points you’d experienced with the student admissions process at Nexus?

David Lee: Oh, thank you, Dan. Thank you for inviting me to have a little chat with Oliver about this, and it sort of, does make me reflect on what we’ve done over the last nine or ten years.

So I’ve been at Nexus for ten years now, and this process has obviously been going on since then in various formats, and hopefully we’re approaching something which is as streamlined as it could possibly be. I suppose the biggest pain point is the fact that we actually have to do this at all. All schools in Singapore, which are private education institutions, have to register with Edutrust.

And as part of that certification, we have to contract our students on a yearly basis. Now we’re part of a bigger group of schools, based in Malaysia with Taylor’s group. Those schools don’t have to do this. They contract with students when they arrive. We have to recontract them every year. So not only do we have to contract students when they arrive, but we also have to recontract them on a yearly basis.

Currently we’ve got 1500 students. So that’s a sizeable task. Now, back in the day, when I first joined, we used to do this as a paper based project. You know, contracts were printed out, mailed, sent to parents. They then came back, and that whole process took six weeks, maybe, from beginning to end. So when I joined, we recognized that as a school was growing, it wasn’t sustainable, so we had to come up with something that would improve that process, and we’d just hired a developer at the time called Raj, and we worked on this with the finance teams, the admissions, learner services teams to try and put in place something that was a little bit more sophisticated. So Raj built a system that allowed us to carry out this process. It was a system that was built from the ground up at Nexus.

It took the data from our MIS then, which was Engage, and it carried out the enrollment of new students and the re enrollment of students who had to be re enrolled for the following academic year.

Now the problem with that, it worked fine, but there were always changes that Taylors pushed in our direction. Changes to discounts, changes to scholarships. The date at which the fees were agreed each year was always different. There were differing deadlines that were being brought to us either by an SLT or the board as to when these contracts need to be issued. So there was a sort of a process that wasn’t very well formulated in terms of how this whole thing should work.

In the IT team, we have a very complicated rollover process when we move from one academic year to the next. And because the re enrollment of the students is basically trying to predict where those students are going to be next year, our re enrollment process actually starts back in January. Now the problem with all of this is that the changes that were having to be put in place were hard coded into the code by Raj.

If Raj left or if Raj decided to go somewhere else or was not available, then we were going to be stuck in terms of being able to make those changes. So we were looking for something that was more sustainable into the future, something that had better support in terms of those ongoing changes.  

It just took a lot of time and actually the, one of the larger issues was the time between us getting the fees approved, being able to make the changes to the contract based upon the changes to scholarships and discounts. Do all of the testing of that, making sure that work with the invoicing to make sure that the calculations from the contract side match the calculations for the invoice side, because they will turn on two different systems.

All of that will take a nber of weeks as well. So we used to say to them, if you’re going to make the decision of what the fees are going to be very late, it just means that then that process of getting a contract out is going to be even later, just because we have to do so much testing to make sure that this system was going to be not a problem.

That system integrated with DocuSign. So back then, DocuSign was the only real product on the market for electronic signatures, which is what we were moving towards for the automation of this process and speeding it up. And the DocuSign integration worked well. It wasn’t perfect. There was some manual works involved, but it did mean that we could actually cut that process of sending contracts down. We did need to do a lot of testing and a lot of redevelopment if there were changes.

And obviously we were always pushing for this information as early as possible. But for various reasons to do with when other schools in Singapore published their fees, getting that information from SLT and getting that from the board was always quite difficult. So for us, it was really about making the solution more sustainable going forward in the future, having a proper company run this, someone who we can go back to for redevelopment, who we can go back to for support, and therefore we’re not reliant on one single person within the school to put in place that process.

So when we were first introduced to the idea of Zegal, which was actually back in April last year, we were in the middle of migrating from our previous MIS, which was Engage to isams. And obviously that gave an opportunity to be able to do something different when we had a platform, which we’d already been told that you’d already integrated with.

So obviously that was a big plus that we knew that this would work with isams. At that stage, Funnel wasn’t in the picture so much. Admissions have been pushing for a long while to be able to issue the first time contract for new learners from Funnel. And when we moved to isams, that was something that we were looking to do.

When it was proposed to us, we were just like, this is, there’s too much change going on for us to sort of do this at the same time as doing the isams project. So we’d already committed ourselves to migrating to isams in July of last year, and that involves something for us, like 15 reintegrations with systems that do various things across the school.

Because again, we’re very keen on this idea of the central source of truth being isams and then all of our subsidiary systems through various kinds of syncs will pull their data from that. And we just thought trying to do Zegal at the same time as doing this will be more complicated. And actually what we did, Raj rebuilt the integration that he’d done with Engage to work with isams.

So that as soon as we went live, as soon as we switched over, admissions could carry on doing their contracting. Obviously the re enrollment contracting hadn’t come at that point. We’ve done all of that in the previous April. So we didn’t have to worry about that. What we were worried about is being able to issue contracts as they went. And the way that we did that, even though we had two separate systems, Funnel is our CRM that feeds the data into isams for students who are joining the school. We would run the contracting process from isams. So they would be moved from Funnel into isams first. as an applicant and then in the applicant stage, they would then be sent their contract to then be moved into current. So the decision to move to isams, you guys appearing on the scene at a very opportune time, and then this desire for admissions to be able to do the contracting from Funnel, you know, it was an opportunity to try and rethink what we did and also to make it more sustainable by moving to something that was a proper product rather than something that was inbuilt.

So there were lots of things all coming together. And then partly because of the isams project, we ended up with this fairly compressed timeline, to get things rolled out for this particular sort of re enrollment.

Daniel: Ollie, one of the ways in which the team ultimately decided to share that data between isams, Funnel, and Zegal was by using Google Sheets. 

Spreadsheets are not a place that we really want to store data normally, are they? So why do we come about with that?

David Lee: Can I just, jump in there as well, just before Oliver starts, because the IT department to some extent has a reputation for being anti spreadsheet in terms of whenever someone comes to us with a solution, they use a spreadsheet and sort of roll our eyes.

Because, for us, a spreadsheet is not a place where you store the data. We’re more than happy to use it for manipulating the data, carrying out processes, but the data in there is temporal. The actual source sits back in the original database, and provided you’ve got a means to pull it in each time you need that change and you can do the functioning or whatever it is that you need to do on that data, then we’re all for it.

So when they first mentioned the spreadsheet, obviously our reaction was a little bit. Really? But then when Oliver went on to explain how this acts as a middleware for collecting the data for processing then it did make a lot of sense.

Oliver Boote: No, no, and I mean that’s that’s exactly it , I think one of the things that’s quite interesting They’re they’re used quite commonly when you’re trying to move data from one place.

 To another here’s It was a little bit different but What we had is, you know, we, we have a large bulk process that’s going to need to be undertaken at some point. And we also have various bits of information from, , from various systems. And so there’s, there’s a lot of student information that’s going to be in the student management system, but there’s probably also going to be other bits of information that might be related to the courses to the fees to some of the logic about how different pieces of information need to relate to the contract. And what we tend to find is that if you try to hard code all of that logic somewhere into an integration or connection, it becomes very difficult to maintain on an ongoing basis.

It’s also very opaque to the end users who are actually going to be making use of it and when things are changing from one place to another, but they don’t really understand how, then that can be difficult for them to use it and understand what’s going on. And so this is one of the areas where we found that pulling the information into a spreadsheet, but using it only as a preview tool and so the information gets pulled in automatically, and it can get merged with information from other sources, and displayed as a preview of a list of what is going to get generated, depending on how they need it, that can be filtered in any way that they might be used to doing with spreadsheets. It could be pivoted, it can be graphed. These are all tools that people are usually relatively familiar with, and so we can pull it in all automatically , into that spreadsheet. And then the spreadsheet itself is also how the contracts get sent back out for generating. So it allows us to do any of the computation that might be needed, any of the merging of information that might be needed and be able to preview this everywhere.

In a way that’s very familiar to people. And so none of the data lives in that spreadsheet, as a repository of data, it’s really just pulling in from one place. You can have a quick look at it and then it pushes it somewhere else.

David Lee: Yeah, there’s two other points to add there as well. I think one is that it made much more sense when we realized we were going to be pulling data from two different systems.

So when we’re actually contracting from Funnel and the re contracting from isams having this central spreadsheet which would be pulling in effectively very similar data to produce a contract which again was very similar for each of those instances just made it much more straightforward. And actually the spreadsheet acting as your middle repository of data, even though it’s in a temporary nature was perfect for that solution because you could see it from both ends.

Oliver Boote: Yeah. I mean, we have two different teams who are both on a day to day basis, living in two different systems. You’ve got your new students that are coming in through your CRM and your re enrollments that are coming out of your student management system. The information from each that was relevant to the contract that’s being made information related to the student or prospective student, both of those, regardless of which source that we’re coming from could come in as the details relevant to the contract.

And then all of the rest of it was, we could be assured that it was going to be the same rules being applied to both. And so that’s also been very helpful in making sure that there is a cohesive system to generate contracts, regardless of what source. is being used.

David Lee: So the logic is the same in each case.

The parameters are more or less the same in each case, so in that respect, it made sense for the information to be pulled into a central place. And the other thing that was interesting is that what Raj actually ended up doing was using the coding that he developed to produce the values to go into the contract to create an output of data, which was exported as a spreadsheet, which was given to the then head of operations, who would then use that to go through and check all of the data.

So we were sort of moving in that direction, but it was something that we weren’t happy with because we were thinking, okay, we should better do this in the application. It should automatically flag when there’s an issue, but it was not transparent at all and if we got issues wrong with the calculation and we spotted that there was some kind of mistake, Raj would have to dig back through his code to change a decimal point or a percentage or something. So it, it did make sense that this spreadsheet was the key to the success of the project.

Daniel: It’s clear hearing you guys talk, that there’s been quite a lot of collaboration. Talk me through a bit, David, about how you worked with the Zegal team and, what was fun, what wasn’t fun? What things that we perhaps thought we were going to do at the outset that maybe changed along the way and required a bit of problem solving? What other aspects of the build were interesting?

David Lee: Well, in terms of working with the Zegal team, it became apparent from the beginning that we were working with the people who were dealing with the code. You know, who knew what was going on under the hood. And in so many sort of collaborations that we have, we don’t talk to those people.

In my experience, in the 10 years I’ve been here at Nexus, the best results we’ve had has been where we can speak directly to the people who have an influence on how this is actually working. So we’ve done a couple of projects over the years. So as soon as we start talking to people, you realize actually, okay, these are the people who are going to be affecting the changes.

They’re not passing this information on secondhand to somebody else. They understand exactly what it is that we’re trying to achieve and also what tools they’re going to be using to achieve it. So a lot of the discussion around API and sharing API keys, which Oliver and I established an undocumented method of sharing the various secret codes and keys that we needed now, we just sort of slipped into that because both of us understood the importance of keeping that data separate.

So that’s one of the things that we look for when we look for a product, we look for somebody where if there’s any development or integration required Can we speak to the people that are doing it? So that was very obvious. The other thing is there was a huge amount of preliminary work that we did back in October through to December before we’d even signed a contract.

So again that was a good sign that you were serious about putting this in place and you were serious about knowing exactly what the scope was. And I think maybe there has been some scope creep over the last couple of weeks, but we both went into it with our eyes open. I knew that you were committed to it because of the amount of background work that was being done.

To make sure it was feasible while we didn’t have a specific sort of proof of concept or you know There were bits that we could do along the way bits that I could manage in terms of setting up the api access A little bit more difficult on the Funnel side because we don’t have access to that so readily, but again in in respect of the development process for me this is very much an agile process, you know in terms of it wasn’t a hard List of requirements.

I think we had a list of list of 10 or 11 things that we introduced you at some point, but it was very much. Okay, this is the broad framework of where we’re going, and then we will iterate on those things as we go. So in terms of whether that’s one of the things that you aim to do in your development cycle.

Now, we don’t do huge amounts of development in school, But we do produce a lot of stuff for academic teams. And again, we take that approach where we try and get them a solution as quickly as possible, which is more or less what we want. And then we just iterate from there because trying to put something down when people don’t really know exactly what they want it to do and what the capability of the system is.

Then working in this manner has been very productive, I think, and obviously maybe a little bit nerve shredding towards the end, but in terms of actually that approach to developing a product, that’s very much our ethos here when we develop something.

Oliver Boote: To add on to some of that, once we had early testing environment that we could get some feedback on, it’s also really interesting to interact with the team of people who are going to be the eventual users of the system.

And because beyond the high level requirements that are first identified, there tends to be little variations that come in and they often need to be categorized between what are the things that we think we wanted to do because this is the way that we used to do things and, our initial reaction is to first think, oh, well, we used to do it like this, can we do it this way? And sometimes these are some of the areas where discussing possible changes is more fruitful, but then also other areas where, you know, if we’re having a discussion early enough, and if we see that a particular request or idea is something that would quite genuinely benefit the platform, there’s a very good chance that even if the system doesn’t do that today, we can have that squeezed into our development and have that released as a potential feature.

Daniel: I think that brings us neatly onto my next topic, which is really talking about how it all went. I know it was quite a tight deadline, and then towards the end of the work together, you’d already started to actually see contracts going out to parents, which is great. What are the things that have gone well, David? What are the improvements that you’ve seen? And also, what challenges perhaps that will take and will need to work more on to iterate and improve on?

David Lee: They planned for two days, but they sent them all out on Thursday, I think. There was quite a lot of background work that needed to be done. Lots of people weren’t aware of in terms of collecting data from various other sources.

So to know who to recontract, who to send these sort of these English as additional language contracts to, and these SEN contracts that I was aware of that process. So nobody was chasing me up for that, but I knew that this is what we would normally do at this time of year. So we do have a re enrollment process where the heads of school and the year leaders have to decide that the students are going to the next year or not, whether we’re going to keep them on hold for various reasons.

We need to get the information in about for the recontracting of the students who are on these special support courses. So all of that was being done in the background. And I was trying to get that data in while everybody else is working on this. And it all culminated in this point where we, there were a couple of issues with, again, some things that we’ve forgotten.

So we have this distinction between intensive and additional English support, but intensive doesn’t exist in the lower school. So in years nursery through to year two, they’re still intensive learners, but they don’t have an intensive course available to them. So we made a mistake where we’d actually put them on a course that didn’t exist in the primary year.

So we had to go back and redo that on. These are things that just we need to build into that process and make sure we docent so that when people are doing this in future that they can not make those mistakes to be able to send all of those contracts out in one day. I don’t think we’ve ever done it in one day before.

And yeah, so that, you know, the proof of the pudding is in the signing of the contracts and that information coming back in and us being able to report on it.

So we can run this daily re enrollment report that we run between now and the end of the academic year to give us a daily update of who’s signed, who needs to be chased up.

So that’s a work in progress. I know there’s still some things to be completed, but in terms of the success of the project, given the sort of the very sort of slow lead up to it, you know, I was looking back at my notes yesterday and at the timeline that we had for this. And we did the very first sort of time it was introduced to us was back in April last year.

I think we met with you in August after we’d just gone live with isams and then we were quite keen to move ahead with this project because we could see it being a solution to lots of different things. And then it wasn’t until October, I think, that we managed to get Oliver access to isams and then Funnel came a bit later.

The Funnel thing was more of a problem with access just because we didn’t have necessarily the right contacts at the Funnel side to be able to give us that. But that did change as the project progressed. And then the meetings just became more regular. We then, we put in place, I think, a fortnightly meeting.

So we’d have a meeting internally and then we’d have a meeting with you guys once a fortnight and then it became once a week. And I think in the last 10 days, you guys were meeting on a daily basis to do this. I think in terms of that kind of project. And the agile nature of it, of the work on it, I don’t think you can do it any other way, because you are testing it as you’re going along, and Raj and I are really hot on the testing side of it, I’m not sure the admissions and the learner services team are quite as concerned about the information testing side of it as we were.

Daniel: And that’s a challenge across lots of schools that we see, absolutely. Ollie, from your perspective, what are the bits that you’re, dare I say, proud of that play around data integration and the use of that data, which David’s touched upon?

Oliver Boote: Oh, well, , I mean, I’m, I’m very proud that it all came together, I think first and foremost, this is something that we were planning on and working on for quite a long time by the end of it, but with the constantly evolving ways that we were going to be pulling these different pieces together, get a system that works for people that gives them visibility into what’s happening, and can also serve beyond just that initial contracting aspect, but, you know, it’s also being used to gather information to update the student system. It can push back into the various CRMs, and so I think that’s going to be really fruitful piece of this integration going forwards.

David Lee: Yeah, we learned an awful lot about isams, because again, we’ve only been isams users in Nexus since August, really.

And although we think we know it quite well, one of the biggest challenges that we had, which was really sort of problem solving on the fly, was the inability to access some of the custom fields that we were creating through the API. So we’re getting feedback from Oliver and his Zegal team. They couldn’t access these fields.

Yeah, these fields are only available if they’re in the first four tabs. So we actually did do a reorganization very rapidly over the week, over one weekend to create all of these additional fields that we need, move fields that were currently in place into the right tabs. And then I think there’s about five or six sections of Zegal fields for discounts, scholarships, which made it a little bit easier for us to manage that process of knowing where to look for the information. But at the same time, we were still carrying on the existing contracting process with DocuSign because they were still contracting students to start at the beginning of term four in a couple of weeks time. So we couldn’t remove those fields. We had to create two sets in parallel.

So that kind of stuff of doing that on the fly was a little bit nerve wracking because there were points where our question of trying to do some trial and error testing on my part to see if we could actually make those fields available. But Oliver was very responsive to that and would test that requirement at the point when I was moving those fields around. So I don’t, I think it would have been very difficult to collaborate on this. Had we been going through another sort of a third party or going through another support stage to say, okay, now I’ve done this. Can you ask Olliever to test this?

Whereas actually Oliver was there. And I think the Google chat that we had and the sharing of the Google documents. You guys are Google organization as well. It just made that so much more easy in terms of having that. Olliever was there, we could drop a line in, he could ask a question and people were very responsive and it did get a little bit hot last week.

I think there are a lot of messages going backwards and forwards, but it did mean that we could develop this thing on the fly in terms of. fixing the problems as they arose, rather than having to raise a ticket. This is an issue which we were having to do with Funnel, for example, which slowed that side of it down.

Daniel: Brilliant. We’ve obviously talked a lot about the challenges that you faced at school. And I know that from Olly’s perspective, Zegal is, is also working with other teams in schools, primarily outside of admissions, HR but what advice would you give? [00:23:00] To other PEIs, other K 12s that are thinking about implementing automation in either admissions or in HR.

And what advice would you give to those schools and those IT teams?

David Lee: For me, if you’re having to do this in Singapore and you have to do this on a regular basis, then you need to have a process that’s going to be slick and automated. So for me, Zegal is the best thing that we’ve seen that can meet that challenge.

Good stuff. Any final thoughts

Oliver Boote: It’s been great working with the team. We’ve continued to build, on the platform. We’ve added in a number of features that are going to continue to benefit both Nexus and other clients and use cases, which is great for the platform.

And it’s also been a good learning experience.

Daniel: Wonderful. Thank you very much. Both of you. It’s really, really interesting to hear.

Oliver Boote: Thanks, David.

Looking to find out more about protecting a trade mark in Hong Kong?
Valerie Suen, Partner at ELLALAN, introduces the key points to know in this short video.

Transcript:
Trade mark is essential to all kinds of companies and businesses. It is used to indicate the origin of goods or services, and it represents a business’ own identity.

It is important to protect the use of your own brand and mark and to prevent others from using the brand. The best way to protect yourself is to get a trade mark registration for your mark and to make sure the registration covers your products.

The mark can be your brand name, logo or a combination of both. Think about what tells people this product is from you. Sound and smell can also be registered as a trade mark provided it is distinctive enough.

Also think about what products are important to you and what are relevant but not core to your business. We need to list out goods and services in a trade mark application and generally the more categories you cover, the more money and investment you have to make.

Once you have all the info, file the application for your trade mark. If the Registry accepts it and no one else objects to your mark, it will proceed to registration. In Hong Kong, typically it takes at least 6 months from filing to registration if no one objects.

We also recommend you keep records of the products you sell, advertising materials and publicity on your brand and products. These materials can be very helpful in the future – to support your application if it runs into conflict with others’ marks or to take action against others who are using it.

Each trade mark registration is also expected to be put into use for the goods or services that are covered within 3 years after registration. Evidence of use you keep is therefore also helpful if you need to defend your mark in case someone cancels or invalidates your registration based on 3-years of non-use.

If you have any questions about this topic, please do not hesitate to contact us. For more information about us, pls visit our firm’s website www.ellalan.com or follow us on Linkedln.

Thank you for watching and see you again in our next video.”

Paperclip HK kindly invited Zegal to speak about LegalTech at their event Adventures into a new era – Exploring your Potential.

Paperclip HK kindly invited us to speak about LegalTech at their event Adventures into a new era – Exploring your Potential.

Paperclip HK kindly invited us to speak about LegalTech at their event Adventures into a new era – Exploring your Potential.

Karen Ng, Co-founder of legaltech startup Zegal, chats about how the Hong Kong-based company hopes to democratize access to legal services by building a SaaS platform through which users can discover and communicate with local legal professionals.

Antoine Blondeau is the co-founder and managing partner at Alpha Intelligence Capital, talking about what Artificial Intelligence is and what it means to the legal profession and to the legal world.

Terry Wong, CTO of Zegal during #zegalcon talks what inspires him on legal tech.

English solicitor from Manchester, inspired by his real life as a lawyer moving into the legal tech world Zegal which is a platform for creating legal documents online.

Decoding blockchain: Challenges and Opportunities from a Legal Perspective

Look back at ZegalCon 2018 edition, Asia Pacific’s Top LegalTech Conference.

Every Contract. Every Edit. Everywhere.

Zegal’s Own In-App Editor

An easy way to work with peers and colleagues.

Make notes and feedback to your collaborators.

Keep track of any changes made

A quick way of getting signatures from all parties.

Learn about Upload&Sign feature to upload any external document and e-sign it yourself and with others.