My name is Joe Johnston and I am obsessed with internal tools. Over the last 10 years, I've created over 80 of them - one particular tool had over 80,000 users and saved the organization over $3,000,000 per annum. If this is your first time learning about building internal software, you've come to the right place. This is NOT your average "Internal tools in 2022" post. This is a continually evolving environment to learn about the finer details of building internal tools, and how they can help you accelerate digital transformation and supercharge your organizational efficiency.
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Internal tools are internally-facing software developed and utilised within an organization. They range from database GUIs to employee wikis, and are highly-tailored to an organizations processes.
Internal tools have been around since the early days of software development. They're the unsung heroes that power the majority of businesses that exist today. And they're growing in popularity.
Software is eating the world, and digital transformation is at the top of every CIO/CTOs agenda. $120 billion was spent last year on internal software development. This figure will continue to increase as we gather more data, become more distributed, and industries become more competitive.
Below are examples of internal tools used within companies and a general list of popular internal tools we've seen users build within Budibase.
Google are infamous for their internal tools. I have spoken with a few product managers at Google and I'm under good authority they have over 500 internal tools in the wild. Some of those tools have hit the headlines, including the two below:
Google's internal browser - Google developed an internal browser tool that monitors meeting requests made by employees. This has upset a number of employees, who have spoken out about the new internal tool. A Google representative denied the tool was for 'spying', saying the company developed the extension in response to an uptick in spam involving calendar entries. Basically, the tool alerts employees when they attempt to auto-add a meeting to the calendars of large numbers of people. The extension does not prevent users from creating such meetings and doesn't collect personal information.
Google's Borgmon (now Monarch) - As you can imagine, Google has a collossal task on its hands monitoring its computer systems. The teams behind tools such as YouTube, Gmail, etc, need to monitor a continually growing and changing collection of heterogeneous entities including visual machines, devices, containers. The total of entities stretches into the billions and, to make matters more difficult, are distributed around the globe. So, Google built Borgmon. Any Google engineer, between 2004 and 2014, will have fond memories of Borgmon - it was a beast and involved a steep learning curve - but it worked, to a degree. Google have since replaced Borgmon with Monarch, which can manage trillions of time series and is essential to the smooth running of the Google engineering empire.
You cannot hit IPO without experimentation. Airbnb understood this from the very beginning. They state:
"At Airbnb we are always trying to learn more about our users and improve their experience on the site. Much of that learning and improvement comes through the deployment of controlled experiments."
To run and manage their many experiences, Airbnb created an internal tool. The tool did all the heavy analytical lifting automatically, whilst limiting bias when setting up an experiment. When designing the tool in 2014, simplicity was the primary goal, and it shows:
On a call with David Singleton, CTO at Stripe, we asked him if they preferred to "build vs buy". His answer was
"Build, depending on the scale of the task at hand. For example, we use Github, because the engineering effort to build a tool like Github is not worth our time and engineering effort."
This is a quintessential answer. Below is a design of one of Stripe's many internal tools, called Home. Home is Stripe's employee resources portal. It provides directories for employees and teams, as well as company-wide resources like calendars, events, and announcements.
Credit to Stripe, their design always seems to strike the perfect balance between beauty, and communicating 'we're an incredible technical company'. It's great to see a company apply the same effort to design and build their internal tools, as they do their external tools.
A CRM (customer relationship manager) helps sales/marketing teams manage their prospects/clients. There are many off-the-shelf CRMs including Salesforce, Pipedrive, etc, but many organizations build their own CRMs due to the unique nature of their sales process. I worked in the defence industry and we used Microsoft Dynamics. It was a great platform, but due to the uniqueness of our sales process, the sales team hated it. It was not fit for purpose. We spent north of $40,000 customizing the tool to fit our needs, but still, it did not suffice. So we built our own and the team loved it.
Data is eating the world. As more organizations and processes move online, the more data we obtain. Collecting data is generally the easy part, it's the interpretation of this data which is hard. In many cases, data is distributed across multiple data sources, making it a little tricky to compile and analyse. Many companies build internal tools / dashboards to help display this data in a way which is easily interpreted. This is one of the primary reasons why Budibase supports many different data sources including Mongo DB, Couch DB, PostgreSQL, Elasticsearch, CSV, Dyanmo DB, and more.
Many SaaS / eCommerce platforms require an admin panel to manage backend operations. They allow you to approve user access, manipulate data, and track transactions. Admin panels often have a dashboard element built-in to save time exporting data to another platform. Like all items on this list, the decision to build an admin panel is usually down to a custom requirement which is not available of-the-shelf.
Generally speaking, the larger the organization the more layers of management it has. A popular process within organizations, especially enterprise, is the approval process. This category can involve many, highly specific approval processes, from booking holidays to signing-off on a sale. When building this type of internal tool, understanding the different types of users and their hierarchy, is crucial.
Inventory can take many forms; from rockets to Tamagotchis. Managing this inventory involves a robust database, an interactive UI, and automations to accelerate the processes involved with managing shipments, orders, and deliveries. Often, a control dashboard where a manager can gain a snapshot of operations, is also required. On top of this, internal development teams need to stay on top of how inventory apps feed into to related tools, processes, and stakeholders.
There are many departments within a business which require software to do their job more effectively - Sales have the CRM, HR have the HR platform, and IT Support have the ticketing system (among others). The core function of an IT ticketing system is to manage incoming support requests from general employees. As you can imagine, the life of an IT support technician can get stressful. Hardware/software have changed our lives, but they are complicated beasts and come with many problems. Combine that, with stressful/over-worked employees, and you get tickets of fury coming at you from all angles, 24 hours a day. This is exactly why a good ticketing system is essential. It helps IT Support plan, triage, disseminate, and inform - allowing them to do their job with an impressive level of calmness and efficiency.
In many companies, internal software development is left to a single person or a loose group of people. These days, a growing number of organizations have an internal products team. 100% of this team's time is dedicated to building and supporting internal tools.
Internal tools are generally built by developers, but if we're honest, they're not the projects developers like to work on. So if internal tools are becoming more popular, isn’t this a developer’s worst nightmare? Not exactly. That is, with new technology, the way developers build internal tools is changing too. These advancements have reduced the learning curve, abstracted a lot of the more difficult technical parts, and made it super quick to build internal tools. This has led to a new wave of internal tool developers. Below we will explore the types of users building internal tools with Budibase.
The illustrious internal tools developer is often the unsung hero in many cases. They are building mission critical software, but often don't get the recognition they deserve. Over 40% of Budibase's users are developers of some type. Their general reasons for using a low code platform, include speed, ease of design, and simplicity.
Product managers are an emerging role which use to be reserved for larger organisations. We are beginning to see more product managers working within SMEs which is testament to the importance of this role. The beauty of a product manager is they are 100% committed to a product; providing direction, ownership, and insights at all times. In a lot of cases, they're both technical and business focused - which is an incredibly powerful mix. Through conversations with PMs, one overarching theme has stood out for us - Product Managers fully understand the business value of these tools. Just under 20% of Budibase's signups are product managers, and growing!
Over 15% of Budibase users are IT managers. They generally belong to manufacturing / construction / logistics industries and work within a small team. Due to the nature of their business, we've found they are often building multiple internal tools, from inventory to CRMs, as their role primarily revolves around supporting the organizations internal technology and business operations. Around 15% of Budibase signups are IT managers or 'IT professionals'.
Of course, as technology changes, so too do the job roles organizations must fill to manage new business processes. Here are too specific emerging specialisms that we've noticed growing in popularity among Budibase sign-ups over the last few years.
Due to the increasing importance and collection of data, we've noticed Data PMs signing up to Budibase. On inspection, their responsibilities lie within creating interfaces to make sense of the large amounts of data collected within their platforms. They then analyse this data to inform business direction. It's very much a data analyst / product manager hybrid - which seems like a role which could benefit almost every organization on earth.
Basically, a product manager whose sole focus is on internal operations. We’ve noticed this role within larger organizations, and the low-code platform/internal tool builder seems to be their weapon of choice. We are watching this role very carefully, as it seems like it could grow in popularity as internal operations increase (due to digital transformation and the increasingly distributed workforce). Specifically, product ops teams love low-code, since it allows them to push out effective solutions to process-specific problems, as quickly as possible.
Building internal tools is different from building customer-facing tools. When building internal tools, you have greater access to the end-user. Quite often, when using an internal tool builder, the build process is a collaboration between builder and user. This is a beautiful, powerful experience and often results in an outstanding internal tool.
There are primarily two ways to build an internal tool; completely with code, or with an internal tool builder.
Both options have their pros and cons; code is more flexible; internal tool builders are faster, easier, and more cost effective.
Going forward, we will illustrate how to build an internal tool with an internal tool builder.
If you are leading the quest for a new internal tool, quite often you will need a business case or approval from the powers-of-be. For this post, we will assume you have approval.
The internal development methodology is the method of building internal tools to automate processes, equip your workforce, and grow your organization. It’s about building tools to empower your employees to do more, and do it faster.
Why? Because when your employees succeed, you succeed.
The Internal Development Methodology can be applied in four ways:
To build an internal tool users love, you need the builder and the AU (admin user) to collaborate. Depending on the size of the organization, the team involved with building the internal tool may involve a product manager (if you can involve a product manager, do!). Collaboration provides motivation and encourages creativity; whilst reducing errors and upsets. During this phase, planning is completed, the project is scoped, and the architecture decided. In cases where the admin user is also the builder, it is still important to plan, scope, and architect.
Within Budibase, there are three phases to the build process; data, design, and automation. During the data phase, you structure your data, and add it to the builder. During the design phase, you build your application with pre-made components and screens. You can then pull in data to your components, and query them with incredible ease. And during the automation phase, you will automate certain processes such as email, notifications, and more. We feel the data, design, and automation pathway is the easiest to learn and the most natural for devs. Other internal tool builders may differ.
Testing should be completed across the relevant browsers and devices. It is a good idea, to test with a user who has not been exposed to the tool during development. It is up to the admin user to sign the internal tool off.
Once the tool is signed off, you are ready to deploy it to production. The admin user will record any bugs experienced and collaborate with the builder to fix them - in some cases, due to their familiarity, they should be able to fix some issues.
We've experimented with this methodology for several years now and every time it has resulted in superior internal tools, happier users, and advocates! And it's these advocates who promote this methodology, which results in more internal tools, happier employees, and faster, more productive businesses. This is how your organization builds momentum, and this is why the internal development methodology serves as a strong foundation for your flywheel.
As we previously mentioned, the internal development methodology can have a positive effect on your employees, equipping them to do more, faster. What's great about the methodology, is it also converts your employees into advocates, which spreads motivation.
Below outlines how IDM transforms a user into an advocate.
Collaborate (user) - The AU (employee) is fully involved from the very beginning. They lead the planning, participate in scoping, and assist with architecture. In a sense, they are the product manager. They are the ones who fully understand the problem afterall.
Build (co-creator) - The AU co-creates the internal tool, providing UI/UX feedback along the way. Co-creation is incredibly powerful, and made possible with internal tool builders such as Budibase.
Test (owner) - The AU is also the tester. They understand the tool, they understand how it should perform, and what the common user will expect from it. They have the final say on whether or not the product is the ready for deployment - at this stage, they are the owner.
Deploy (advocate) - The AU, due to their heavy involvement, is the internal tool's advocate and first line of support for their team. They are the owner, they are the creator, they will promote the product to their team and gather feedback which then kickstarts the flywheel again. In some cases, they can make changes without the need of the internal tool developer.
Once the user becomes an advocate they sell the internal tool to their colleagues. Their colleagues, the new users, experience the platform and immediately begin considering how they can create internal tools to improve their jobs and provide the company with more value. The wheel keeps spinning, and a faster, happier workforce grows.
Better collaboration results in better internal apps. It also results in happier users, advocates, less bugs, less support, and less maintenance. Trust me, it's worth it!
When deploying your apps, it's important to understand where in the world your users will reside as this will impact perf. If you are in a highly secured environment, it's generally better to self-host your apps in the comfort of your own infrastructure.
Do you remember in the summer of 2020, when President Barack Obama, Joe Biden, and Elon Musk's Twitter accounts were hacked? Well, the hackers managed to compromise one of their internal tools and get access to their accounts. Please take security serious. Below is a picture of the internal tool:
It's important to scope the internal tool to understand any areas that might require additional development outside of the internal tool builder. If there is development, please make sure your tool of choice is extensible and allows you to build on top of it - being able to see the codebase is a huge advantage here. This will also reduce technical debt.
At Budibase, we like to include an NPS feedback popover in our apps. It asks the user to rate, from 1 to 10, how likely they are to rate this internal tool to a colleague. Underneath the scale, we include a comment box. This helps us understand the general feeling towards our app. Understanding feedback helps us build better tools.
When building an internal tool, it is advised to think of your users like you would an external application. Uber have many internal tools, and Kamal Boparai, Engineering Manager, IT Eng Compliance and Legal (Engineering) Team puts it nicely in the statement below:
"The IT Eng team is very focused on our end users (Uber employees) and their experiences. We always put our end users first; from there, we can help external end users (Uber’s partners and customers) virtually. Even more importantly, we keep the Uber network functioning properly and create the infrastructure that supports Uber employees. Basically, IT Eng is responsible for everything that happens in the background to keep Uber running smoothly."Kamal Boparai,Engineering Manager | Source
More and more businesses have dedicated people, whose full-time job is building internal tools. Still, as we’ve seen, a whole bunch of different professionals can find themselves working on internal software, at least from time to time.
So does your choice of platform impact their success? Or, to put it another way, what can you do to empower your team to create the right tools, the right way?
Besides determining the cost of internal tools, different builder platforms will offer very different experiences for each class of user.
Here’s what each one needs to thrive.
The faster your internal developers can build and deploy new tools, the better. As long as they’re not compromising on quality, that is. This is doubly true if you have developers working on internal projects, even though this isn’t their main responsibility.
The crux of this is that your developers are skilled professionals, with some of the highest labor costs in your entire organization. Clearly then, you want to choose the tool that’s going to offer the best developer experiences, the most flexibility, and the lowest lead times.
But they still aren’t developers.
The thing is, your product team knows your processes inside and out. They’re probably more aware than anyone of the need to drive efficiency too. The missing step is giving them the tools they need to put this into practice.
If you want to empower your non-technical people to build internal tools, you need a platform that offers high levels of functionality, with intuitive, user-friendly experiences. That way, anyone can be a developer, not just your developers.
IT managers have to juggle more concerns than just about anyone else in your organization. On the one hand, their job is to make sure everybody else has the tools they need. On the other, they need to make sure that these tools are secure, compliant, and cost-effective.
You can see how this would go out the window if different teams built their own tools with no oversight.
The key, therefore, is furnishing your team with the tools they need to build effective internal software, without undermining your broader IT strategy.
We’ll return to how Budibase can help you balance all of these concerns a little later.
Microsoft's CEO, Satya Nadella once said, "Every company is now a software company". Software is without doubt changing every aspect of the workplace. What's more accurate and less heralded, is how we've only scratched the service when it comes to the productivity gains expected from software.
2020 was a disastrous year for people around the world, and for many businesses too. The events in 2020 and 2021 will inevitably lead to organizations looking inwards to find answers. Building internal tools with internal tool builders can play a huge role in helping an organization cut costs whilst improving output.
Internal tools have increased productivity across the board for the majority of industries, but the scale in which they're rolled out can make a huge difference. A study from 2003 showed that while Wal-Mart and Kmart both invested in IT, Wal-Mart did a better job of changing the rest of their business to work with the technology, and consequently saw “higher levels of productivity and market value”.
Of-the-shelf software, especially enterprise software, costs a crippling amount. When building internal tools with an internal tool builder, you can save 10x the cost of off-the-shelf software - sometimes a lot more! You can save even more if you self-host your tools on your own infrastructure.
If you are self-hosting on your own infrastructure, and implementing your own Auth system, in a lot of cases the security will be better.
When building your own tools, you have the power to build them exactly how you want them. As previously mentioned, you are building a solution around your specific problem. One of the common reasons users come to Budibase to build custom software is because a part of their business is so unique that no off-the-shelf software can solve their problem how they'd like them to.
Providing your employees with the right tools to do their jobs is incredible fulfilling for employees. As I am sure you are aware, a common scenario in organizations is a disgruntled employee battling with an unfit tool, or using a particular tool to solve a problem the tool was not designed for. (We'll chat about Microsoft Office soon).
Previously it would take an internal software developer/development team, on average, 4 weeks to 6 months to build an internal tool. With modern internal tool builders, such as Budibase, internal software developers can build and ship these same tools in days.
Microsoft Office is the workplace swiss army knife. We're grew up using it, loving it, and inevitably hating it. But, please don't see this as slander. It's an incredible platform, with incredible tools which solve common problems. In fact, a highly product Excel user is basically an engineer with a different title; building internal software (albeit in a highly restrictive environment). The problem is how we overuse these tools to solve problems which they are not suitable for. Here's an example of how nearly 16,000 people who tested positive for the coronavirus disappeared from records due to an Excel error.
Code is awesome. Boilerplate code and repetition not so much. We created Budibase to augment the development experience not replace it. You can still write code, query data, self-host; but you can also develop faster, design better, and output a real single page application.
The emergence of internal tool builders has reduced the barriers and resolved many of the concerns around building internal tools. If organizations were more willing to build their own internal tools, specific to their needs, they would experience huge productivity gains, an increase in employee satisfaction, and potential market growth. With digital transformation now a priority for most businesses, there has never been a better time to build internal tools and accelerate your organization forward. I hope you enjoyed this post, and thank you for reading.
Supporting the internal development methodology is an all-in-one platform for building, automating, and shipping internal tools. By combing the internal development methodology with Budibase, you'll accelerate digital transformation, speed up development, and equip employees with the tools to grow.
As we said earlier, most of our users are professional developers. That is, they know how to code, but they choose our platform because it makes their lives easier, faster, and more cost-effective.
In fact, we make the development process so smooth and intuitive, that Budibase is loved by developers and non-technical professionals alike.
Let’s take a real-world example to show off just how simple internal development can be.
As with any project, the first thing we need to do is define our requirements. As we’ve seen already, internal-facing apps can vary quite a lot in terms of complexity. So, sometimes these might be aimed at a single, discrete task.
Other times, they might be used to manage a whole raft of tasks within a wider department or team.
For simplicity’s sake, let’s focus on the former. You can then scale up the same approach for more complex tools.
Obviously, our first task is deciding what we want our tool to do. The best jumping-off point here is figuring out which processes, tasks, and user actions we want to replace or manage. In other words, how our users will interact with the tool and what will happen in response.
Let’s say we’re building an internal vacation approval platform. We’d probably come up with a list of requirements along the lines of:
This might seem simple enough, but don’t be afraid to read over it a couple of times so you’re fully familiar with it. We’ll be using the same example for the rest of this article, to see how much time and effort you’ll save using Budibase vs hard coding a similar tool.
Once we understand our requirements, we need to think about the data we’ll leverage to put them into practice. Basically, what kinds of objects our tool will deal with and what we need to know about each one.
This is what’s known as a data model.
To hard code this, we’d need to create a database from scratch, or at least connect to an existing one if we’re lucky enough to have something like this available.
With Budibase we have a couple of different options. We could still connect to existing data. Alternatively, we have the option of using BudibaseDB, to quickly create an effective data model, on the fly.
Let’s think about what data we’ll need, and then you can make your own decision. Essentially, our tool will store information on three separate but related entities:
Each employee is related to one line manager, but each line manager is related to many employees. Each request is related to one employee and one line manager, but both can be related to many requests.
The specific attributes you need to store on each will depend on your existing processes, the size of your organization, and the complexity of its structure.
For employees and line managers, we’ll definitely need to know their personal information, holiday allowance, job role, and any other relevant details for vacation decisions. For requests, we might only need to know the relevant dates and maybe optional comments.
We can achieve this in just a few seconds with Budibase DB, and then edit it on the fly afterward. Or, we could even import a CSV to get started even faster. Alternatively, we still have the option of connecting to an external database, if we prefer.
With our data model in place, we can think about the interfaces we’ll need to let users interact with stored information. Since we’re dealing with a relatively tight set of requirements, we won’t need many screens to make our app a reality.
Essentially, we’ll need:
If we were feeling fancy, we could also add a third form for employees to edit or delete their previous requests, but that goes a little bit beyond the requirements we set out earlier, so we won’t worry about it today.
You might not believe how easy Budibase makes this step.
You literally don’t have to design a single thing, if you don’t want to. We offer auto-generated CRUD screens, so you can achieve functional interfaces to manage connected data sources at the press of a button.
Of course, you’ll probably still want to tinker around the edges and perfect your internal tool UIs.
Even then, we offer an incredible degree of customization and flexibility, while still keeping custom code optional. Use our intuitive builder to add, move, delete, and configure any of our library of built-in app components.
Next, we can think about the processes that will link our interfaces to our data. Again, Budibase makes this a breeze. For simple business processes, you don’t need to do much at all.
For example, our autogenerate forms are already fully functional, so there’s no need to write out queries manually.
For more specific tasks, you have a couple of options for creating custom business processes in Budibase.
If you opt to connect to external data, you have full control to build your own queries, transformation rules, bindable values, and more.
We also offer a dedicated automation builder, drawing on a full library of built-in functions and rules, or third-party integrations. Use user actions, system events, data conditions, external signals, and more to trigger your custom automations.
We also need to think about how different users will interact with our internal tools. In fact, it’s very rare to find internal software where all users perform the exact same actions. Rather, it’s normal for there to be a hierarchy of roles and responsibilities.
Our vacation request example makes this incredibly plain.
Remember, we have three entities, two of which are employees and line managers.
Each of these corresponds to a different type of user, who needs a different level of access.
In Budibase, we can grant or limit access to different resources for each defined role in a couple of different ways. First, we can configure a minimum access level required for each individual screen.
Alternatively, we can use conditionality rules to define access rules for individual components within a screen.
Finally, we can limit read and write access to individual tables within BudibaseDB, to control permissions across the board.
Finally, we can deploy our internal tool for managing vacation requests. As ever, Budibase offers a couple of different options here:
We don’t believe in a one-size-fits-all approach to internal development.
Instead, we offer our developers and users the flexibility they need to create the perfect solutions for their specific needs. So, if you need the convenience of one-click cloud deployment, we’ve got you covered.
Or, if you need extra customization, security, configuration, and control, self-hosted Budibase tools are the perfect solution. Deploy to your own infrastructure with Kubernetes, Docker, Docker Compose, Digital Ocean, and more.
Why should you take our word for it that Budibase is the best way to build modern internal tools?
After all, we obviously have a vested interest, don’t we?
Well, yes and no. On the one hand, we clearly want you to see things our way. On the other, we’re pretty confident that once you’ve tried Budibase, you won’t want to go back to slow-coding your internal software.
To help you get started, we’ve created over 50 fully deployable, free app templates, using our own platform.
Let’s take a look at some of our favorite internal tools, which you can use or customize today.
Check out our IT incident report form, for a simple, customizable tool to register and record all kinds of hardware, software, and security issues.
This is a deceptively simple internal tool, but it could save you untold amounts of time, hassle, and money. The faster your team reports incidents, the better positioned you are to limit damage, learn lessons, and prevent reoccurrence.
Unfortunately, many employees won’t bother to do this, unless you make it as easy as possible. So, having an intuitive, fast, and easy-to-access incident report tool can literally be a lifesaver.
Or, in the case of security breaches, a reputation saver.
Our tool offers two separate access roles and experiences, for on-the-ground employees and IT team members respectively. It’s the perfect one-stop-shop for reporting and responding to all manner of incidents internally.
Expense management is one of the most ubiquitous business processes around. Basically, every department in every business does this, at least to some extent. Our invoice approval software template is your best friend here.
This is the perfect example of a simple internal tool that could save you heaps of money in redundant admin tasks.
Say goodbye to lengthy calls, email chains, and follow-up questions with the finance department. Our template is designed to eliminate manual interactions entirely. Employees can submit invoices at their convenience.
These can then be approved or declined by the responsible team.
You can even add extra power to our template by creating your own automated approval rules. For instance, by instantly approving any invoices that fall below a certain threshold, or come from particular teams.
In many businesses, time logs are at the center of a whole host of internal operations processes. So, gathering accurate, detailed records of how your team is spending their day is central to profitability.
We’ve built our employee timesheet template to achieve exactly that.
Our template offers a seamless experience for employees to submit multiple timesheets, in one sitting, making it the perfect way to record accurate, reliable data to inform a huge range of processes.
Use our template to simplify job costing, HR processes, finances, project management, payroll, invoicing, and more.
We’ve all worked in offices where things break and never get fixed. At best, this can be annoying. At worst, it compromises your employees’ morale, job satisfaction, productivity, and even their safety.
You can set hourly rates for all different kinds of project functions in the back-end data layer. Then, users can provide time estimates for each stage of the project to create a robust, itemized budget.
We’ve built our maintenance request form template to guide users through providing exactly the right information your team needs to put issues right.
It’s also got a separate dedicated interface for maintenance operatives to respond to requests and provide follow-ups, helping to ensure maximum internal trust and transparency.
Thank you for reading our definitive guide on internal tools. If you liked this post, please share with your colleagues. If you've not tried Budibase before, give it a whirl and let us know what you think on the Budibase forum.