Dynamic document generation via API is our primary use case.
Dynamic document generation via API is our primary use case.
The product has improved our organization in allowing us to dynamically generate our customer documents - all of our contracts, application documents, and any other documents that are always dynamically dependent on the customer's details. We're able to now generate them dynamically, using a single template and a single API core, by just passing that data through. That has allowed us to streamline our document generation capability within the organization, removing work that was potentially required to do that previously.
The ability to design templates within the Microsoft Office Suite has absolutely freed up developers' time for other tasks. Report-building is not having to be done by developers. A lot of it can be done by the simple business user, if it's just a font change or replacing some static text. That can be done by the simplest of office and business users. If you can use Word, you can do that.
Some of the more complex functions, like dynamic merging in a nested loop might require a little more advanced knowledge, but anyone who uses Excel or who can write a small macro in Word or Excel would be able to do that. The learning curve is a lot simpler than any of the other report builders that are out there.
One of the features that we have found most important is that the report builder is in Word, so it was very easy to get into it. The learning curve wasn't too steep. We could also use some of our existing Word templates. We could just leverage them, whereas competing products use a proprietary report builder where you have to rebuild everything from scratch.
The other major feature is having a RESTful API that we can call to create these documents.
One thing that frustrated us a little bit is that we have to use the Office PDF generation, because the native PDF generation is always slightly different compared to the one in Office. The formatting is just a little bit off here and there. Sometimes a page-break will not appear. There are always some little differences between the native PDF and the Office PDF. This means that we need to have Office installed on the server to be able to generate these documents via API. That's been a bit of a frustrating limitation for us.
They do continue to improve that, but because we want to maintain documents exactly as we see them in Word, we have to use the Office PDF generation, instead of the native PDF generation. And that takes a little bit longer to generate as well, whereas if it was the native generation, it would take less than half-a-second. The Office PDF generation takes a bit longer, it can take up to two to three seconds to generate a single document. So there is a bit of a performance hit there.
This is the one negative aspect that we fought through. It didn't stop us from using the solution. But it is something that we hope, over time, will improve. If they could get the native PDF generation to be one-to-one with the Office generation, that would make it an exceptionally good product for us.
We've never had it crash. The stability of the solution is very good. We've had no issues with it ever crashing.
The scalability is pretty good. On our biggest days we now have to have three servers to handle the biggest loads - something like 10,000 documents per day. In general, it is not unusual to expect to have three servers supporting that sort of load.
Overall, it probably generates some 10,000 documents for us, at least, per month, if not more. That's just off the top of my head. As our customer base grows, and if we decide to use it in different parts of the business, we would consider scaling up and using the product further.
At this stage, it is part of a crucial project that we delivered, and it's a crucial component of that project. As long as our business grows, we will consider growing that component of it, as well.
So the scalability is good. I won't say it's excellent, but it's certainly quite good, at least a six or a seven out of ten.
Tech support rates at least a good eight out of 10. They are always very keen to help. One time we had a bit of a critical situation and I got a response from the CEO himself, very promptly. It has always been very good.
The only issue for us is that, because we were Australian-based and they're American-based, there is a little bit of a delay in their response. They don't have 24/7 support. It could be better in that regard if they offered 24/7 support. But, the support, when it is provided, is very good. It's just not 24/7.
The previous solution was home-grown, an internally-coded solution that could not be leveraged. It was for template-building, it was a hard-coded document-generating engine. We didn't even have templates for it and it was very difficult to make any changes to the documents that were generated. The documents were not very pretty. They were very not marketing- or design-friendly.
In another part of the business, we used SSRS, which is a Microsoft report builder, for some documents. But that was not really good either. As soon as you had multiple pages it didn't work very well either. We went from a home-grown, 20-year-old legacy solution to using this product.
The initial setup was pretty straightforward. The solution is not very complex for what we use, meaning the RESTful service. All it required was one server to be set up with IIS and Microsoft Office installed on it.
We had a few little conflict issues that we had to check on with support, but those were specific to us. Overall, just following the instructions on their website, we were able to set up in a few hours or half a day.
Our implementation strategy was to first try it out. We did a bit of a proof of concept. We downloaded the REST API product and the demo of the report builder. We tested one of our templates with that, called it via an API call. Once we knew that that worked and it was delivering the results we were expecting, we went ahead and chose the product.
We also thought the cost was very reasonable, so we just went ahead and pulled the trigger on it. After that, we went into financial negotiations and bought the licenses to use the product in production. We then implemented the product on a more scalable server, one that was designed for production loads. We continued to test it and build reports afterward.
It was all done internally. We did reach out a few times directly to Windward with a few queries. They were specific configuration queries for our particular use case. We deployed it in the Azure Cloud.
It's not a very complex product and the implementation was pretty straightforward.
It's difficult to measure whether it has saved costs or not because I have no baseline to compare it to. It is functionality we required that was previously accomplished by a 20-year-old capability that didn't fit our needs anymore. We needed to invest in this, to have this.
I wouldn't say it has saved us costs because we didn't replace manual labor with this capability, we replaced our legacy capability.
The pricing is very reasonable for what it provides. The report builder is about one grand per user and we're only going to ever have two or three of those. And the licenses are perpetual. If those were subscription prices, if they were annual prices, that would be quite expensive. We are paying for a support contract, which is 20 percent of the price, but because the licenses are perpetual, I think the pricing is very reasonable.
We were comparing Windward to SSRS, Microsoft Sequel Server Report Services, which is one other kind of report-building product. I downloaded a few demos and tried them.
We looked at OpenText and we were thinking of OpenText as a grander solution. But at that point in time, we didn't have the capacity to go through a full procurement process, which is what would have been required for an OpenText solution. So we ended up doing a quick prototype and proof of concept with Windward.
The biggest issue I had was that all of those other solutions had a proprietary report builder, whereas we already had these documents in Word. All we had to do was use the templates we already had and just add the text fields, the form fields, and the merge fields into those documents. It was very quick for us to do the initial round of comparisons. All the other products we looked had their own report builder and we would have had to rebuild all the Word templates in a proprietary report builder.
For us, that was a key feature that we wanted to leverage.
Do a proof of concept to make sure that it meets your needs. Check the PDF generation between the Office PDF and the native PDF. That caught us out a little bit. Make sure, if you're hoping to use the native PDF, that it is generating the documents as you want them.
If your company is a massive enterprise business, Windward is probably not entirely suited for that, although we are a pretty big enterprise and we are able to leverage it. But very big enterprises can probably spend a bit more money and do bigger programs and have programmers to do this in a more powerful manner. But any small-medium or medium-sized businesses, the 100-employee businesses, it's perfectly suited for them. Those particular segments should try Windward out, do a proof of concept.
It's pretty straightforward. You can do a proof of concept easily in a week, to see if it meets your needs.
We've been using it now in production for over six months. We started proving concept with it about a year ago.
The solution's layout and design capabilities are good. But I think there are better ones on the market. What Windward has is completely sufficient for what we wanted to do and what we required. They're basically the same as what Word offers. Anything you can do in Microsoft Word, you can do in Windward. So you can do quite a lot, but there are definitely products out there with which can do more. However, they're also a lot more expensive, and a little more difficult to use.
The quality of the layouts and designs is very good. It's better than average, an eight out of ten. Again, there are better products out there which are a lot more expensive and a lot more focused on the desktop publishing market, more so than what people use Word for. It's a slightly different requirement, but it fit our requirements.
The ability to design templates within the Microsoft Office Suite is very good. It's a seven to eight out of 10. It's exactly what we were looking for in terms of capabilities. There are other ones on the market, which have more power but, again, those are focused on a slightly different market, and a slightly different requirement.
The POD (Portable Object Doclets) feature is good but you can actually do a lot without it. It is something that makes things a little bit easier. It isn't the greatest feature in the world, but it is useful. We managed to do a lot of work without using that particular feature.
The only people using the it are the report builders. They change the templates and create new ones. We have three people who are trained up to do report building. Sometimes, we let other people try and build them. It is pretty self-explanatory, and you can do some of those changes without any training. It really is pretty straightforward, but we have three people, particularly trained up to be report-builders.
The rest of the product is used by API calls, meaning it's used by applications. We've got a Loan Originations application. A lot of different users use that application, and when it gets to the point in the process where they require documents to be generated, they just click a button, and via API we are able to produce those documents for those types of users. I wouldn't say those users are using the product per se. They're using an API that sits in front of the product.
We have one staff member who is looking after the product, not even full-time. There are three or four people trained up to look after the infrastructure component of it, but it's pretty straightforward. For them, it overlaps with a lot of the other roles that they do in terms of looking after infrastructure, servers, etc.
Overall, I rated as I did because, for its price point, it's very good at delivering what it's designed to deliver: keeping your templates in Word. Anyone who can use Word can build these templates very quickly and easily. It also allows people who have a lot of these documents already in Word, to take those documents and very easily turn them into dynamic documents that can be generated on the fly via an API. That is exactly what we needed. For what we required, the product met those needs.