Regulatory organizations play a crucial role in a clinical trial sponsor’s success — but small and scaling teams are often challenged by budget and resource constraints. As a result, too many regulatory leaders at emerging clinical trial sponsor companies are left to manage their team, documents and submissions with a patchwork of do-it-yourself systems and processes. In the following webinar recording, we dive into how to do it better!
In this educational session, Marissa Berry, PhD, RAC, owner of Embee Consulting, and Kivo CEO Toban Zolman share how they build and scale regulatory operations with clinical trial sponsors using modern project and collaboration management - dramatically improving efficiency and effectiveness.
The presentation includes best practices and lessons learned in areas such as:
- Regulatory team management — how to structure and manage collaboration across internal and external teams
- Leveraging partners — making the most effective use of regulatory consultants, writers and publishing services at each step in the submissions process, and as your pipeline scales
- Process automation — using tools and platforms to improve efficiency and bandwidth, without introducing compliance risk.
- Scaling cost-effectively — how to manage the workload as a pipeline expands from two active programs to 20… without 10x the budget.
To learn more about how Kivo can help streamline regulatory submissions for your organization, request a demo today.
Full Session Transcript
RAPS Webcasts: Hello, everyone. I'd like to welcome everyone to today's webcast entitled Streamlined Submission Management for Emerging Sponsor Teams sponsored by Kivo. I'd like to introduce you to today's presenters. Toban Zolman, CEO of Kivo; Kevin Tate, Chief Revenue Officer of Kivo; and Marissa Berry, Owner and Regulatory Affairs Consultant of Embee Consulting. Take it away, guys.
Kevin Tate: Thank you. Thank you. We're super excited to be here. I'm Kevin Tate, and let me just share my screen real quick. This is exciting. We've met many of you at RAPS events before, but this is our 1st webinar with RAPS. So thank you so much for joining us. If you're not familiar with Kivo - we're a regulatory solution built specifically for emerging sponsor teams, which is why today we're excited to explore some best practices for how teams, especially small and scaling teams, are working together most effectively today.
So one of the things that makes this a really interesting and timely topic is that the market is accelerating. So all of us who are in the business of dealing drug discovery - bringing those to market, helping them get through regulatory approval, and all the things that come with that - are about to find our lives speed up a lot. And there's a few things that are really driving that acceleration, and that we're expecting to see play out over the next couple of years.
One is the sheer amount of money coming into the space. And you can pick any number of staggering figures here about the investment into AI driven drug discovery. But 60 billion is about how much has gone into AI fueled drug discovery in the last couple of years. Most estimates say that it's about a 2.5 x increase in the number of compounds that are promising, and then have a candidacy for trials and approval. So that's just a lot more to work with.
The second thing that's happening is that the discovery phase itself is getting a lot shorter. So it used to be that it took 3 to 5 years to take a promising molecule or substance, and figure out how to get it to a clinical stage. That's shortening to around 12 to 18 months, and that matches with the type of money that's coming into this market as well. Right? A lot of the funding for the companies that are emerging and that we work with today, it's coming from VC and PE backers who want to see things in their portfolio move quickly. They want to see opportunities to partner or monetize that pipeline on a shorter timeline.
And perhaps the biggest impact for all of us who have to figure out how to work on these programs as they go to market is we're gearing up for about a 10x increase in clinical trials. There's been a huge increase just since 2019, but no matter whose estimates you pick, there's about another 70K trials that are in the hopper and a target of about 200,000 trials by 2030. That's huge. If we look back at 2019, when there were 16,000, and there's going to be 200,000 soon. That's the kind of 10 X, even 15X growth. That means you need a whole new approach. And so that's some of what's in the back of our mind as we think about how teams are organizing around a new market.
The other thing that we're seeing is that that landscape is changing the way that companies and their regulatory teams work, and you know, to sort of generalize a bit if we look at the old way. There was a time when most of this work was big teams working in big pharma and everybody's marching together toward a commercial launch. And that's rarely the case anymore. 70% of active trials are actually happening inside of smaller companies with smaller teams. Those teams are distributed. They are bringing experts who have a lot of experience in the space they're building a pipeline of products, each with its own opportunities and timelines and expectations. And those expectations might not be, "We're going to take this all the way to commercialization ourselves." It might be an acquisition or a sponsor partnership. That's just a really different way of working, and it's a really different landscape for regulatory teams to play their part.So that's a pretty interesting backdrop to think about how teams and technologies can be working today to be more effective.
So with that, I'm going to hand it over to Marissa, who's going to talk about a bit of what that feels like from a regulatory operations perspective.
Marissa Berry: Thank you for the intro, Kevin. Hi, everyone. My name is Marissa Berry, and I am the owner of Embee Consulting LLC. I've worked in regulatory affairs on both the sponsor side and on the consulting side. So today I'd like to talk to you a bit about what I think are some regulatory project management best practices.
I would like to start by saying that regulatory affairs does encompass a lot of different things, especially if you're at a small company, and there are many different aspects of regulatory strategy operations project management that honestly, I could spend hours talking to you about. But today I really wanted to focus on the best practices for planning, drafting, publishing, and submitting documents to health authorities, particularly for the FDA.
I will also state for the record that there are many ways to go about tackling a regulatory activity. What I'm presenting here is generally my preferred approach, based on my experiences. But this is a process that might differ or be adapted from company to company, and it certainly evolves with time.
So the 1st step, as you tackle a regulatory activity is understanding your task. So 1st and foremost, what is the activity? Is it an FDA meeting? Is it an original submission, a maintenance, submission? Who will be involved? Do you have SMEs? Are you using a medical writer? Is this an activity that requires a publisher? And then will it just be your internal team, or will it be contractors or consultants? Next is, when must it be completed? So is this a company goal or formal FDA deadline? And what source information is needed? Are there non-clinical reports, clinical reports, that sort of thing, that you need to be able to draft your regulatory document? And lastly, what tools are available to you? Do you have a document management system? Does your company have regulatory templates? Is there project management software? Do you have a submission builder and that sort of thing. What tools can you leverage to make this whole process in your job easier?
Once you've understood the requirements of your regulatory task the next step is to really set expectations for both your team and for what the process will look like. So for your team, 1st and foremost, if there is one thing that you take away from this talk today, it's that you should identify a person who's going to be responsible for driving the document drafting and submission process. This really needs to be someone who will take charge and coordinate everything from start to finish.
The next thing you want to do is make sure everyone's roles are clear. So who's going to be the primary author, who is just a reviewer, who's responsible for cleaning up and accepting things like track changes edits and responding to comments, and who ultimately has final say and final approval for a given document. In my case my personal preference is usually (and this is based on past experience), the reg strategist is usually the driver and the primary author. We'll have SMEs, who are reviewers. But the reg strategist will use best judgment to really incorporate edits and respond to comments and clean everything up, and then usually the Head of the Regulatory Affairs group will give final approval of a document, or if it's a CMC document, maybe head of CMC. Things like that. Lastly, if you don't have publishing in-house, you will need to identify a publisher if you're submitting to the FDA through the gateway.
Next, you'll wanna make sure that you set expectations for your process. And this is really more about expectations for your team in terms of how the process will work the process overall. It can range from document drafting to building out your submission to handing off to your publisher and review of any publishing output prior to submission. I will say most small companies, and even some bigger companies, probably don't have any sort of SOPs in place for what this process is supposed to look like. You're very likely in a situation where you're just kind of following what's been done before, what you've done before, and adapting it as needed for your team and how things will move forward. Or you're making a process from scratch if you're a completely brand new company.This, I will say - developing your process is a really good area to leverage the tools that you have available to you. I'm thinking particularly in mind of your regulatory templates and any sort of document management platform that you have any project management tools that you have. Those are tools that are really gonna make your job easier, as you're coordinating this process. So if you don't have regulatory templates and you're gearing up for a big submission, definitely recommend getting some! And also for the sake of your sanity, do you have a writing style guide? I definitely recommend one of those, because I can't tell you how many times someone has completely messed up the formatting of a document because they just didn't know how to work with a given template, and then you have to go and fix it. Nobody wants to spend that time. So any tools that you have to make your process work for you, I definitely recommend.
Next, you want to set your timeline. So this will be based on when you're gonna get your source documents, because those are the basis for all of your submissions, and then what sort of document, drafting review and finalization process you have for your team anytime that your publisher needs to actually work up the documents and send them through the gateway. You do also want to account for any sort of national holidays, upcoming team member vacations, things like that.This is also a great place to leverage any sort of project management tools you have in terms of timelines builders and things like that. What I've shown here as an example on the slide is just a piece of an IND timeline that I have for one of my current projects. And you can see we usually go through just a single round of review before the document gets finalized.
That's something that's works for this particular team I'm working with. Same with the days and the times here. That's something that works for this particular team. What works for you and your team might be different. It might be a different amount of days. Things like that. But I will say, try and be reasonable, but you can't cater to everyone. And remember that timelines are meant to be a guide to help manage expectations for both yourself, your team, and any folks at upper management. But timelines can change. So make sure that you're constantly adapting and updating as you move forward as the process goes on.
So once you have your timeline settled, the last thing that you really want to do before you actually kick off the process is to get organized. This for me personally, this comes in the form of a bunch of different trackers. So this will be things like Excel trackers, for you know what are the source docs that need to go into the submission, particularly if it's a CMC-heavy one, because there's a lot of different source documents that go there. Any history of correspondence and submissions that you have with a given health authority. Those are helpful to know and have at your fingertips. I usually keep those right now in excel files that are just very readily accessible for myself and my team, so that everybody can see what they need to. This next bullet here task list for team members. It is a pain, I will admit it, but it's very helpful to actually do this! It would be so amazing if anyone you ever interacted with only needed to be asked once to do a thing and they did it and give you the deliverable on time. But sadly, that's not real life. We're all human. We make errors, and I think one of the easiest ways to keep everybody on track is to have very dedicated task lists for each of your team members, and then to remind them repeatedly when when certain things are due.
Lastly, I think one of the other critical things for staying organized and keeping your process moving smoothly is to have settled on your document storage platform.You need to know what works for your company. But you know, I personally like to have everything organized so that all of my team members can access the files they need in a very intuitive manner, but also that so that things are very easily accessible for me at my fingertips when I'm compiling a document. So in the examples I've shown here - on the left is just what my per project desktop folders look like on my computer so that I can personally locate a few key things that I go into regularly, and then over here on the right is our document management platform that I like to use. And this is our per project organization, or at least just an example. And this is something that the entire team has access to, so that anytime someone is looking for something. I can just quickly send them a link, point them in the right direction, and we can go from there.
Now that I've kind of summarized everything at a high level in terms of what the process looks like, or at least what my personal preferences are for the process. I do want to leave you with a few tips and recommendations, just to kind of help you as you move forward.
Number one, leverage the tools and resources that are available to you. Understand their limitations and adapt your process as needed. There's a lot of different tools that can make your life easier from regulatory templates to document management system to project management tools. So it's important to use them if you can, or at least encourage your company to get some, if it's within budget and things like that. But also be very aware of what the limitations are. So if you're the kind of company where you're emailing documents back and forth, and that's what your review process is, okay. You can work with that. But you need to build in time to your timeline for someone to harmonize all those edits into a single document at the end.
Another thing to keep in mind is, take charge of your activity and process. You really want to lead your team and prevent chaos before it starts. And this is what I touched on earlier. Where, if there's 1 thing I want you to take from this, it's someone needs to be in charge of the process. And I will say, very rarely have I ever been on a team or at a company where that was decided at the get go that, "So-and-so is in charge. Follow their lead." That usually doesn't happen. It usually ends up a free for all. And so one person just needs to really step up, take charge, and act like you're the boss of this project even if you're not, and your team will thank you for it, because they know, "Okay, so-and-so is in charge. They're gonna tell me what to do and when and you can go from there." So it really helps keep things moving along, keeping things smooth, and like I said, preventing chaos before it starts.
Another helpful thing is, make sure your team has easy access to all the files they need, and they know where to find them. This can come in handy with a document management system.And, like, I said before, send reminders about task due dates and who is responsible. I I wish everyone were as organized as as me sometimes, but that's not life. Some folks could really benefit from having a personal assistant all the time, so sending helpful reminders actually goes quite a long way for keeping things on track.
And lastly, I do want to say, drug development is a team sport.You're working with the team. So planning collaboration and communication is key. And importantly, information silos really don't help anyone. It's, I think, one of the more frustrating things I've seen working on regulatory submissions is when one team doesn't want to share information with another. And it's everybody needs to know everything, to really make the process work to put together a good submission, and to have a very open dialogue with the health authorities that you're working with.
So with that, I think that's everything that I wanted to touch on, so I will hand it back to you, Kevin.
Kevin Tate: Thank you. Thank you. That was that was awesome. Thank you, Marissa. So many good nuggets in there. And a lot of questions that came in. So let me throw a couple of these your way. A couple are about the timeline itself, and you mentioned how important it is to to set a realistic timeline, as we all know that timeline can become, you know, a management and board level thing as things progress. So maybe 2 parts. One, how do you set a realistic timeline upfront? And then how do you maintain confidence even as those timelines change? So you don't get to the, as you said, chaos point.
Marissa Berry: Yeah, so I will start by saying, you will never make everyone happy with your timeline, so don't try to cater to everyone. It is too exhausting and it is too stressful. The best you can do is really put forth what seems reasonable for you and your team based on the levels of expertise of everyone on the team, and whether you've tackled a particular task before. In my case, you know, I've I have enough experience that I know how quickly it'll take me to put together. You know an FDA meeting package or module 2.7 of an IND, so you know I have a set amount of time that I think is reasonable for me to put together.
And then, in terms of team reviews, my rule of thumb is usually 5 business days because the review process is so much faster than the initial drafting. So I think the the hardest is setting the time for the initial drafting, and then review's 5 business days longer if it's a big chunk of documents. Little shorter, if it's less than that, and hopefully, your team should be able to find one of those days within that window to to make it work.
Kevin Tate: A couple questions came in about this theme of accountability. As the question says, like, how do you make sure the mindset doesn't become "Oh, the red team's responsible for this, but rather we're all responsible for supporting this activity."
Marissa Berry: That's a good question. I balance it. I like to make it clear that I'm in charge. These are the timelines, please follow them, but I am never shy from saying I am not the subject matter expert in, say CMC or non clinical. I know enough to be a little bit dangerous, but not enough to be tackling it all. So I need to make it clear that there's a need for that team member. You're not able to do this without them. You need them to at least confirm that what she wrote is right, or, you know, answer a question, whatever it is, make it clear that there is a need for them. They have a role to play. Then when I send those task emails out, I call out who's doing what, and at what point in time. So I'll usually send, here's the high level timeline. This phase are these people, this phase are these people, and then I'll send a specific name-by-name task list as well, so that everyone's very clear on I need you. This is when I need you, and this is what I need you to do.
Kevin Tate: So, useful peer pressure. A couple of people asked about project management tools - any advice there for which one to choose and how to use it?
Marissa Berry: So it's it's up to you and what works best for you. I've seen some folks use smart sheets. One of my main clients that I'm working with uses Microsoft Project, so that's what I've been using lately. I think there are other tools out there in the works (like Kivo). So it's really what's familiar to you, and what's easy enough for you to use. I found MS Project seems to work fine for my needs but I do always appreciate any sort of tool that allows me to create a really nice Gantt chart that I can put into a Powerpoint slide or things like that. Powerpoint has a a timeline plugin that you can import from whatever project management software you use. And it'll create a really nice, pretty great Gantt chart for you.
Kevin Tate: That's excellent, and spoiler alert, Kivo is going to be showing off our new project management capability. So that'll be fun. A couple of questions about whether or not a commercial RIM system is really worth it for a company in in this spot, and whether you see value in having a RIM system at this stage?
Marissa Berry: The short answer is an absolute yes. I fully recognize that, you know, companies do need to balance their budgets, especially if they're a startup, but I think the sooner you can get into an information management system the better, because once your project takes off and you've had some interactions with the FDA, or you're starting to build out your manufacturing or what have you, it's a lot harder to migrate a bunch of documents than it is to just start in one system and be there. And I think, as you build out your teams, you know, everybody's worked on something different. So if they can come in and you just say, this is what we use. I think that makes things go a little bit smoother, but having been on teams where our literal process was email documents back and forth, and me having to be the one that harmonizes all of the comments and edits at the end...That is exhausting. It's not a worthwhile use of my time, so I much prefer having something in an information management system where everything's easily accessible. I can easily tell my colleagues where things are. And especially if it has collaborative authoring where everybody can be in a document at once. I don't have to deal with technical issues, things crashing on me, people losing access, anything like that. So yeah, short answer is, yes, I I highly recommend an information management system, even if you're small.
Kevin Tate: That's excellent. Thank you. I want to move on to Tobin's perspective around, how do you build systems and process to support these teams, and what have we learned from that? So, Toban?
Toban Zolman: Yeah, thanks. So I wanted to approach this from the perspective that that we deal with a lot at Kivo, which is a small emerging company that doesn't have a product in market yet maybe hires their 1st regulatory person. That person often comes from a larger company because they bring experience and understanding of process, and then they arrive and can't quite make sense of what they're experiencing. And so I wanted to perhaps provide some color to what some of those dynamics are in these smaller companies that drive a very different process and priorities.
We talk to, probably I don't know 10 of these sorts of folks a week that are like, "Help! I can't make sense of of what's going on. How do I navigate this?" And so I'm gonna kind of take what Marissa talked about and specifically apply that to the constraints when you're you're the 1st or one of the 1st regulatory folks into an organization. And you need to create a process, manage that process and ultimately scale it. So how do you go through that?
So we'll start by really looking at how you create that process. These are themes that I think we encounter literally on a daily basis as we work with companies with kind of these attributes, and the 1st one here is very much a variation on on a theme that Marissa hit on, which is you need really a decentralized process with really clear ownership over all of the steps in that process, and the content that is moving through it.
I want to kind of drill down on this just a little bit and explain why why this decentralized piece is so important. So if you were to kind of round up all of Kivo's customers and look at the user accounts in those, it's typically one to 3. So for every employee in a company that works with Kivo, there's typically 2 to 3 additional users that are not employees. They're CROs, contract medical writers, contract Reg Ops or Reg Affairs froups, publishers, you name it. And that creates a really unique challenge to build a process that works for everyone within Acme Pharma, but also all of the CROs and contract medical writers as well. Some of those folks you'll be in control of their time because they're contractors working for your organization. Others are partners like a CRO, which is literally a black box. You won't know what their internal
authoring and review processes are, sometimes even who's doing the work. So it's really important to focus on the handoffs or the gates that content moves through as it goes through each draft, because that's going to vary from employees to contractors to partners. All of that's going to flow differently.
The second thing I would say, is to train on both the process and the tools at the same time. When we have a new customer at Kivo, and we do a kickoff meeting...Typically the impetus for that is, they've brought in Kivo, they're starting their core authoring for their IND, and I can usually tell within about 2 min of that 1st meeting how that kickoff is going to go. If if I'm in that meeting with their Head of Regulatory, who has a process slide up and is explaining how content is gonna move through the process, when they're calling out each of those things like Marissa showed, you know, draft one, draft 2, etc... If that's all well defined, the review steps and the criteria for review are well defined, then I know exactly how to train those users on doing those tasks in Kivo. If I am just simply showing them how to abstractly use software but it's not anchored in how they are going to run the process, inevitably it's a mess. And so I would say, it's really critical to couple those 2 things together. That can be as formal as work instructions or as simple as a Powerpoint slide that outlines it. But it's important to to cover those things together. And frankly, it's a forcing function to ensure that they align. If you're saying this is what the review it should include for content or formatting, but the tools that you're using give you no way to actually look at those items, then that's going to be problematic. And then the workflow is going to to break down.
I would also say iterate and improve the process as you go. I work with so many folks who wrap themselves around the axle trying to define every edge case, and perfect a process before they roll it out. Don't do that! Literally set your timeframe like 3, 4 weeks out. Just try and survive the first month of the project, and then continue to improve and iterate. Tell everyone that what you're doing it radically de-risks the process, and frankly disarms everyone so that they're not all trying to project, "Well, when we do our NDA or BLA, this isn't gonna work." Check. That's not what we're doing here today. We're just trying to get the the current submission or whatever the project is off the ground.
As I said, focus on handoffs. Let your partners worry about their own internal process and really build the process for the project that you're currently working on. So many of the of the emerging companies that we work with, they may not make it to an NDA. They may not bring their product to market if the initial clinical trials aren't promising. So there's really no reason to completely project that far into the future and create a bulletproof proof process that's going to solve any theoretical eventualities.
The final thing I would say here in terms of like an actual lesson learned. And this is super basic, but we see it on virtually every project. Everyone needs access to the same tools. So Marissa outlined a host of what those items are - content templates, document management, if you're using project management tools - folks need access to that. And inevitably half of kickoff meetings are contractors and partners, raising their hand and saying, "I don't actually have access to your templates. I can't use Please Review. We don't have a license for Office", whatever it is. Make sure before you start a process that everyone participating can participate in the same way. That's super critical.
Once you have that created, then it comes time to manage it, and the 1st thing that I would say is, get your management process as close to the content as possible. That's kind of awkward wording...Let me explain what I mean there.
A few weeks ago I was working with a regulatory project manager at a service provider. She manages IND projects. They were kicking off a new project with with one of their sponsors, and she spent literally 2 to 3 weeks building up this massive Microsoft Project plan. Every document had accurate dates and gates, and what the sponsor approved, what they approved. It was immaculate, and by the time it was done it was 3 weeks out of date, and they started the process all over again. There was no way for a single human as a project manager to keep that document up to date as fast as they were needing to move. So I would say it's really critical, whatever tool you're using, to ensure that it's not totally separated from the content and the tasks that are being done. You can close that gap in several ways. Let people update the project plan themselves. Use tools that pull that project management or status capability directly into the document management system or documents. There's all sorts of ways to do that. Tools like Kivo bake it in. You can use metadata. You can use due date status. But get the the context of the process directly into the documents if you can.
Second thing, I would say, is reduce the scope of iteration cycles outside of life sciences. This has become a best practice across the board. In software development, typically you're working on one to 2 week sprints, because humans can actually relatively accurately predict timing in that short of a timeframe. If you ask me to outline what the next 6 months is going to look like. I'll be wildly inaccurate, so create smaller handoffs between yourself and partners, do more iterative handoffs to publishing. Try and shrink the scope of everything as small as possible, and then leverage those shorter time horizons into shared reports and views.
So I I saw a question come in - are weekly meetings too redundant for a 180-day task? Nope, you may not necessarily want to do a meeting on that. If you can leverage reports and views that share that status so that that can happen asynchronously. Literally a 1 to 2 week time horizon is about all humans are good at projecting, and so embrace that, and try and manage stuff to that short of a timeframe.
One lesson learned on this side is that sunlight really is the best disinfectant for process issues. I'll give you a great example of this. We had a customer that was deep into their IND process. They kept missing timeframes. The Head of Regulatory was just chasing and chasing and chasing trying to get documents updated and understand status. Unfortunately, CMC was typically the bottleneck on that. So we were able to create just some simple reports that showed how stale documents were in different steps of the workflow, so you didn't need to chase anymore. Everyone in management had access to those reports, and we're able to see, "It's Biff yet again. That document's been stuck in his lap for 7 days," or whatever it was. So it's much easier to just create transparency and let that drive management versus trying to chase folks down.
The final thing I wanted to talk about is scaling process. This is an area that is always super challenging for our customers. And I think the behavior of small companies is very different from a large company. So what I mean by that....Kevin talked about the locomotive versus a freeway of futuristic cars on his slide. And that's truly how small companies behave. They're not building a company. They're building product pipelines that they can monetize and create partnerships around. And so really, what you're doing is building SWAT teams around each of these items and scaling those individually to support that particular product. So lean into this. And this is a hard thing, a hard paradigm shift, I think, for a lot of regulatory professionals that come from big companies and go to small ones. Create execution teams per product in the pipeline, create a common nomenclature and language across all of those teams. A draft one is a draft one for every single group, even if the process that you're using between in that draft is unique from from product to product. At least use a a single kind of language, and then ensure that teams can really work independently of each other.
The final thing, I would say on this is a lot of decisions - strategic decisions at companies - those are board level decisions. But if you're in a small company, the the degrees of separation between you and the board is maybe 2 levels.It's not like if you're, you know, coming from Lilly or Pfizer, or something where it's 26 levels between you and the board. And so, because of that proximity to where strategic decisions are being made, it's really important to understand those dynamics and frankly align how you're running and scaling your process to those overall strategic business decisions.
So that, I think, is a place when we talk to to customers or talk to regulatory professionals, that is often an "Aha" moment of, "Right. I'm literally one degree removed of these strategic decisions. I need to reframe how I think about it, and how I run my projects in a way and in language that makes sense." Because I'll be honest - we see the reports and the dashboards that we create in Kivo literally used in these board meetings to make decisions on scaling the company, and so just be aware that all of that gets compressed in a smaller company and lean into it.
Kevin Tate: Thank you, Toban. That was great. You touched on a couple of the questions that had come up in the in the Q&A as well. So thank you. And, Marissa, I saw you jumping in and answering some of those questions as well. So thank you. Thank you.
As Toban mentioned. This is what we do all day. So I wanted to share a little bit about how we address it from a systems perspective. And you know how we've designed what we do at Kivo with this type of way of working in mind. So I'm going to give you a real quick tour of how we do it at Kivo, and how our clients work in it and try to tie back to some of the things we talked about today.
This is what Kivo looks like when you log in, as you can see, it's a dashboard that puts everything you're working on front and center and tells you whoever's logged in what you should be working on. So to some of the things that both panelists talked about - I can see files I'm working on, or tasks or files that have been assigned to me. I can easily see anything I'm in the progress of editing or collaborating on, and of course, anything waiting on review or approval, and we find that just makes a big difference again, bringing it front and center. So everyone knows what they're working on.
Another thing that we find really helpful is to have intuitive document organization. So if I go into the regulatory area here and I go into the documents repository, what most teams do is they'll set up one program folder like this where they've got a substance. Let's go through. What is typically the EDM reference model for keeping track of all the documents related to that program. So I'll click into one here and you can see when you arrive at a document homepage here in Kivo. Everybody can see exactly what's up with that document again. All that can be based on roles and permissions, and you know who can access what and where. I can see I'm on version 14. It's currently approved. I can see all the previous versions. If I need to get to something directly in a previous version, I can do that quickly. I can see and manage all the metadata for that document I can see and manage who has access, if I'm an Admin. And of course the full audit trail on that document. So just having access to everything within a click really helps keep everyone, you know, literally on the same page about every doc that's going into the system and that you're working on for the submissions.
Another thing that came up on the call today was the the need for easy collaboration and everyone being able to work together. This is a really key part of Kivo. So in this example, I've invited some folks on the team to collaborate on a document. I can choose anyone, internally or external, that I need to work on this document with me. And then, when I go to work on it, when any of us go to work on it, we can actually open it in our own Microsoft Office. So when I click this edit button, it opens this document in my own Microsoft Word. So I can have access to any toolbars or macros or things I like to use for authoring. And also anyone else who's working on it can collaborate in real time. So real time edits track changes, commenting all the things that you come to expect if you're working with Microsoft Office online, but all right here in the Kivo system. So all this is syncing right back to Kivo. Oh, there's Toban now. So we can actually see each other working on the document. We're not like checking in, checking out or having to worry about versions and things on our desktop. So we find that makes a big difference. Whether with Kivo or another system, make sure you've got real time collaboration for your team.
Another thing I would highlight is when it comes time to organize these documents into submissions. We heard from Marissa about the importance of using some kind of submission builder. So what we do in Kivo is, we have a submission builder with templates for each different type of submission. This one is for a full IND, and then an easy way to populate the leaves of that IND in this case, with documents from anywhere in the DMS. So I can navigate to find exactly what I need, or I can always search and pull in exactly the right 1571 to populate that submission. That really helps with organization.
So in a lot of cases, the teams we're working with are using submission builder to prep all this, and then they just do an export and hand it off to their publishing partner, and that could be everything, or it could just be what's changed. So you can easily go in and make a couple of edits, export only changed files, and share that for publishing.
Of course, another important part is being able to view and manage the ECTDs that you get back. And so we have an ECTD viewer with a number of different views. We can view the original application. You can view each amendment. We also have a current and a cumulative view. So not only can you see the most current, but you can look back at the cumulative changes and see what happened in each cycle.
Back to the organization piece. One of the things that we find really handy for customers is, because you build it in submission builder, you can close the loop on where those ECTD components came from. So not only can I see the information about this leaf, but I know right where it came from in the DMS and which version. And when I go look at that in the DMS, that document knows it was a part of those submissions. So if I go over here on this document homepage, it'll say, "Oh, yeah, I was included in these 2 sequences, and this is the version that was included, and I was also referenced in this ECTD, in which version..." So, finding a way to close the loop on documents and the submissions they're involved in and keeping versions clean is, we hear, a real help in terms of keeping things moving.
Other things that we find teams like to have organization around are regulatory activities like commitments and correspondence. If you are keeping track of correspondence with agencies, have a system like Kivo that allows you to capture key information, add it to the right cabinet, and then even drag over emails directly from Outlook. So you can take an email from Outlook, drag it over to Kivo. We'll create a rendering of that email, and even put any attachments up here. So just keeping stuff in a centralized, part-11 compliant system versus, you know, on people's hard drives or in their email inboxes is really key.
And then the last thing I'll show is what I mentioned earlier. We have a built in project management tool now. So, as Marissa said, a lot of teams will use SmartSheets or Microsoft Project, both of which are great. We also have ways to import those projects into Kivo and use our built-in project management tool, where for each milestone and task you can assign owners and checklists send those reminders, assign tasks, and (what I think is most powerful is) you can link documents to each task. So here, this is a big, big project. It's like a full IND content plan. But because each document is linked to each task, if I'm managing this, I can watch things move across my Kanban board automatically, because documents are getting uploaded and worked on and approved, and I can see their state change. And if I want to zoom in and just look at, "All right. What's relevant to content and the content team?" I can see what's up with every single thing the content team is working on.
So that's a really powerful project management tool that also feeds into our reports capability. So a lot of times regulatory teams will come in and create a dashboard like this, so they can see every document they're working on for a given program, or even across programs, and then see the status of that, and maybe to the point earlier, about sunlight. We'll create some sunlight by scheduling delivery of this every morning or every week to everybody on this list, so everybody can see exactly what's up and maybe what's holding up our timeline. So those are the some of the things that go into the Kivo RIM system. And I think, as we heard today, systems like this can really help small teams get a lot more done and get a lot more done on time.
So thank you. I saw some questions come in. Toban, thank you for handling some of those I know, one of them was, how long does it take to set up a system or set up Kivo? The honest answer is, 2 weeks. Usually it doesn't take that long. Everything you see, comes out of the box with Kivo, including our authoring templates. We have about 450 ICH authoring templates you can choose to use or bring your own, So it usually takes a couple of weeks, and then oftentimes we're importing documents from SharePoint or Veeva RIM, or whatever people were using previously, and we can pull those in and get them all slotted into the cabinets.
So let me check my Q&A list here...What is the cost of Kivo? All right. Well, thank you for asking, and the honest answer is, we try to make it really affordable for small teams. So Kivo starts at less than $1000 a month for the smallest teams which we find is affordable enough that teams can jump right into Kivo earlier on, and they don't have to wait until they are behind because they didn't have a system.
So that's my Kivo tour! And hopefully what you saw is that we are bringing these key aspects of a regulatory solution to teams that are small and scaling. We do work with over a hundred sponsors and service providers all over the world, and if this is something that you or your team is looking into, please come, check us out at Kivo.io. You can also come and join our webinar on November 12th. We're very excited, as this is our largest feature update ever. We're going to be showing off a whole bunch of new document management and project management features. So I invite you if you're interested, go to Kivo.io, check us out and sign up to join us on November 12th!
I see a few more questions here, butI think we're getting short on time. I want to thank you so much for your time today and for joining us. We're huge fans of RAPS and appreciate your support. That's it for me.
RAPS Webcasts: Thank you, Kevin. So as we conclude today's webcast, RAPS would like to extend our gratitude to the Kivo team for sharing their valuable insights with our audience.We hope to see you at a future RAPS event. Go out there and make it a great day. Talk to you all soon! Bye, bye.
Toban Zolman: Thanks, everyone.
