Innovating Document Delivery for Property Managers

Our process

Everything started with standard analysis. We needed to understand how the distribution works, who it affects, and what problems we might encounter. The deeper we got into the issue, the more complex the solution became. The first challenge was whether we would even be able to get the data we needed.

Synchronizing the data

Our property managers, like many others in the Czech Republic, use the SSB 2000 software from Starlit s.r.o. This program manages all the data about the houses and owners and uses it for billing and other tasks related to property management. This has been a source of data for us. Starlit began creating and selling this program in the 1990s, and the technology in which it is written matched that. Microsoft Visual FoxPro is a technology older than the vast majority of our developers. It is a program created for Windows and runs only locally. The company solved a problem with collaboration and data sharing within by storing all data on a local network drive. Outside of the local network, it was impossible to access the data.

We decided to solve it by using an intermediary. The company had a corporate Microsoft 365, which included Sharepoint cloud storage with decent synchronization of locally stored files. Its main advantage, at least for us, was its API!

So all 5GB of data in the form of 40k pdfs and the SSB 2000 database is constantly synced to Sharepoint. From there, via the API, we select new and changed files every night via "delta query" and download them to our portal.

Decode the database

The first challenge is over. We have the data. Now we have to figure out, how to get the information we need from it. Each pdf file generated has a long numeric name, that carries, among other things, the unit ID in the SSB 2000 database. Then all we have to do is find the appropriate owner and pair the contact information to it. Easy.

Except that the program used a DBF database, which means, among other things, that the column name cannot be more than 8 characters long. For comparison - we're used to naming like "first_name" here it was "A_rpc2". Not very descriptive, especially if you're looking for the ID of an entity. Reverse engineering took the most time out of the whole process of creating this functionality, but in the end, we achieved a successful solution.

Email, the gold standard of Internet communication

It was time to decide on a way how to deliver the documents to the owners. Our attention first turned to the 1:1 chat built into the portal. Its use brought many challenges, such as:

• The legal acceptability of delivery,
• its generally low usage in the portal,
• most of the houses and thus the owners were not yet registered on the portal.

The last point, of course, carried with it a certain promise. It would force the COAs to speed up the registration to the portal. However, this could not be done in such a short time. In the end, technical, legal and UX considerations outweighed the business ones. Therefore, the good old standard of internet communication - email - won out.

The good is that people change their address more often than email. The disadvantage is that a large number of people today have several email accounts - work, personal and so-called "spam emails" used for online registrations. Their primary goal is to minimize the amount of junk mail on their main accounts. Generally, we see an increasing trend in the use of this kind of practice in recent years. This phenomenon could significantly reduce deliverability if we were to use the addresses that users have registered for the portal.

Fortunately, the Property managers had a "confirmed" e-mail address for electronic communication with the vast majority of owners. In this case, the route to the word "confirmed" was via physical forms signed and handed in person at the secretariat. Probably a minor inconvenience for the owners, but a big help for us now.

How it works

Now it was time to figure out how to bring it all together into one well-functioning unit. It was clear that we would use the so-called "Administration Zone" for distribution. This was part of the application used by property management companies that needed to manage all their houses on a portal.

information gathered from the initial analysis was very important here. The process was not allowed to be significantly changed. Nor was there any reason to do so. A "document distribution" section was created in the administration zone, with an overview of each house and a list of documents enriched with this information in the details of each house:

• unit,
• the recipient (owner of the unit),
• the status,
• date of upload.

We knew that distribution is done on a house-by-house basis and often by different people. This allowed us to avoid reviewing all 40,000 downloaded documents, a potential performance issue. It also greatly simplified the demands on the UI.

So let's take a look at the complete flow:

1. A property manager, let's call him Carl, processed the billing documents for "his house" in SSB2000.
2. These documents were uploaded to the "Administrative Zone" on Sousedé.com by the next day.
3. Carl sorted documents by upload date, checked, selected and sent. Before sending, he just set the start and end dates of the time window to deliver the documents - usually two weeks.
4. When the documents were merged by a recipient and sent as one email.
5. After the set period expired, the undelivered documents fell into a section aptly named "Undelivered Documents".
6. From there, Carl downloaded them and a sent "traditional" letter way. Deliverability was to determine how much work Carl would end up with. That's pretty much the whole point here.

Deliverability is all that matters here.

The internal goal was to achieve at least 50% deliverability in the first round of mailings. This would save the majority of costs and also mean a proof of concept. Further optimization could get us even better results. But even that was ambitious.

1. The sender must be the property manager, not Sousedé.cz. The billing email will be sent from their email, not the traditional info@sousede.cz used for transactional emailing.
2. The word "billing" must appear in the e-mail subject. This is because owners expect it at this time of year.
3. The design must be minimal and clear. We don't want a bunch of text with a link at the end.
4. One email is not enough. Undelivered documents are resent every 3 days. Until the deadline, which is setup in the distribution setup.
5. Before distribution, we posted on the notice board that the billing will come electronically this year.
6. Everything has to work on the phone. 70% of our open transactional emails are opened on a mobile device.

The last thing left to figure out was to define what "delivered document" actually means and how to measure it. It was not possible to send documents as attachments, there is no way to measure that.

Measuring clicks in an email is tricky. Some email clients contain antivirus software that tests links by clicking through them. Therefore, we came up with a solution of having the user click through a unique link from the email to a website where a similar-looking report with a download button would be waiting for them.

The first click on this button saves all documents at once, to avoid a situation when the less attractive ones are left undelivered. In terms of cost, it doesn't make much difference whether you send one or more documents in a letter. The text of the button also needs to be clear. It not only downloads the documents but marks them as delivered and signs them by saving information like device type, IP address, browser, etc.

How it all worked out

In the first wave, the goal was to deliver at least half of the documents sent, and then make incremental changes to achieve better results. However, there was no significant optimization and the reason was, to our surprise, simple - we managed to deliver over 90% of all documents in the first wave. In addition, by simply exporting the already completed document sets, we also streamlined the distribution of the remaining undelivered 10%. Thus, we saved the Liberec housing cooperative around half a million crowns for the first mass mailing. The entire functionality is now also used for other types of documents throughout the year.

A small drawback remained the actual connection to Starlit SSB 2000. Although it works very well in this case, it is not easily and quickly reusable to other administration companies. The entire implementation requires some customization to how the program is used in a given company, which makes the entire process slower and more expensive. Even so, document distribution has become a mainstay of the interface for administrative firms and has helped us bring other houses into Neighbors.com. In this case, not by units, but by the dozens.