Process For Processes
Spreadsheets are great for some things, but collaboration is not one of them. Enter the Catalytic data table: our take on a fully programmable, dynamic version of a database that is simple enough to use within a process for the average business user.
As Catalytic has grown, our Sales, Enterprise Services, and Customer Success teams have attempted to maintain a repository of our customers’ processes. As it would in so many organizations, this list began its life as spreadsheet. It was intended to tell a narrative in a centralized place: status of usage, customer involvement in the process build, who are the internal and external stakeholders, level of automation, integrations used, a description and use case, the value recognized by the customer, key dates, and the like. And as tends to happen, the spreadsheet became unwieldy, dated, and had inconsistencies in the way the data were entered across the team.
One of my first tasks after joining Catalytic was to build a process to track our customers’ processes that would internally complement a suite to be used by our customers’ centers of excellence. The narrative is started when building begins by our Enterprise Services team, or when the status changes: one fills out a form with the customer name, process URL, and process name to start.
Our narrative process checks our database for an existing account of the customer process, and pre-populates a form with anything that has so far been documented on it (or a blank form if we don’t have anything recorded). If the deployment dates have changed, or the process was in testing but has now gone live, the status can be updated, which also triggers an announcement to the appropriate customer channel in our Slack team. Both the date of those changes and the actual process launch dates are recorded automatically in the database depending on employee inputs in the form.
Depending on the process’ criticality to the customer we’ve even built a mechanism where our leadership can approve requests for regression automation. Once approved, these requests are monitored and handled by our Development team as the narrative comes through.
We have dovetailed the narrative to optionally start an additional process (built by one of my colleagues) that automatically generates a branded, customer-facing support manual that is personalized for their process. Fields that were previously captured in the build narrative automatically flow down, and text generates dynamically based on a short form completed by the process builder.
Once all of this began to be recorded in a Catalytic data table, we were able to build an automated report that is sent weekly to the leadership team highlighting any changes recorded for processes within the last week. Reports can also be generated ad hoc by customer and process status. Problems with visibility, versioning, data consistency, and documentation are a thing of the past.
As the repository grows, there is a use case for our “fuzzy matching” capability. For tricky process builds, this would allow our builders to search the database for keywords, and potentially repackage past designs, freeing up internal resources to solve truly new problems. As we release new actions, we can also more easily identify past process builds that could be significantly optimized by that new functionality.
Better than a spreadsheet? You bet.