What is our primary use case?
We are a B2B cloud service provider offering SaaS solutions to the UK energy industry. Our billing products require various forms of end customer communication. If our customer does not have their own solution in place for rendering documents, we recommend Docmosis.
Our software operates in a serverless (AWS Lambda) environment so a web service for this was clearly important and inline with our technology strategy.
We use the product for two main functions:
- PDF rendering of bills and other documentation aimed at our customer's customers. Bills in particular can be complex documents that also need to be presented clearly, smartly, and on brand.
- HTML rendering for emails.
How has it helped my organization?
Having a robust, simple, cost-effective rendering solution integrated into our own products increases our attractiveness to customers. It is also vital to our architecture that the software follows our cloud strategy.
Our customers benefit by being able to be extremely agile in changing the flat text in any of their communications. Their operations are made easier by having up-to-date messaging.
During the COVID-19 crisis they were able to author and implement vital messaging to their customers in a single day.
For startups, having a cost model that grows as they do is essential.
What is most valuable?
We mainly use the PDF rendering facility. The combination of the MS Word template and the passing of a JSON data object into a single simple REST API call that returns a PDF document is exactly what we required.
The ability to embed, and dynamically repeat, templates within each other is a very simple yet extremely powerful tool.
The HTML rendering, in combination with our own AWS SES service, allows a very simple method of producing bespoke emails.
The storage of templates within the product in a folder structure makes the rendering call simple and also allows for multiple environments to be catered for.
What needs improvement?
Haven't investigated fully, but the HTML rendering could be a little more sympathetic to multidevices. Perhaps some options are available there.
Although not a requirement at the moment, the ability to produce charts might be so for some customers. A solution, however simple, for this would be great. As it is not a requirement at present, we haven't fully investigated whether this may well be achievable one way or another.
Version control and restricted access to some users for template editing could also be a useful addition.
For how long have I used the solution?
What do I think about the stability of the solution?
Good. Not a single issue so far with thousands of documents.
What do I think about the scalability of the solution?
We don't have a concern for our many use cases, but they are primarily small documents.
The integration works. Seems flexible about hitting band upper limits but always wise to model this as best you can.
How are customer service and technical support?
On the single occasion that we used tech support, which was for an issue with our environment, they were very helpful.
They are flexible when discussing environments, pricing bands, etc.
Which solution did I use previously and why did I switch?
Not for this exact scenario.
How was the initial setup?
Memory of setup was that it was straightforward with some good coding examples to supplement the documentation.
What about the implementation team?
What's my experience with pricing, setup cost, and licensing?
Cloud and REST API models keep the setup costs low.
Price bands are based on pages so ensure you have a good understanding of this if documents are of variable length.
Which other solutions did I evaluate?
Did not formally evaluate multiple solutions. Selected preferred option on apparent ease of integration and cost, then trialed it successfully.
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)