For a long time, I hardly kept any records within HubSpot. I mean, I was the one who was building the workflows, setting up the properties, and updating the reports. I knew the reason for everything existing.
Or at least I used to think so.
One day I opened a workflow that I had not touched for months and looked at it for a few minutes, then asked myself why I had built it like that.
I honestly couldn’t remember.
It was at that moment that I realized the documentation, which I had thought was unnecessary, would have been just as useful to me as it would have been to anyone else.
Since that time I’ve altered the way in which I work; when building something important, I make sure to leave sufficient context for the next person, whether or not that person is a teammate or someone who joins a year later, or in many cases just myself six months from now.
Documentation needn’t be complicated; it could simply consist of a brief note stating what a workflow does, a sentence explaining why a custom property was created, and a straightforward account of how a report is used. Details of this kind can avoid hours of confusion in the future.
It also makes it much simpler to judge whether something can be altered or deleted. If that context is not available, each update seems a bit risky.
I have seen companies delay improving their HubSpot portal just because no one wanted to risk breaking something that they didn’t completely understand. Good documentation solves this problem. It builds people’s confidence. It makes cooperation simpler. And it allows the CRM to continue growing without becoming more difficult to manage.
I now consider documentation to be an integral part of the process of building the product, rather than something I’ll deal with ‘later’ because later almost never does arrive.
In my view, a well-managed HubSpot portal is not merely an automated one; it’s one which could be understood by someone else without having to try to work out why a particular thing was built the way it was.