In the past, businesses created policy and procedure manuals to define how the company operated. P&P manuals outlined the rules and guidelines for employees to follow; however, times have changed. With the advent of no-code and low-code platforms, business applications can replace paper and electronic P&P manuals with business applications.  Well-designed Business Applications with embedded business process flows can guide staff with consistent and compliant service and operations delivery. 

I started my career in airline reservations and customer service. During university I worked in an airline call centre selling flights and making travel arrangements for customers. There is a lot to know in most customer service jobs and airlines are no exception. When can a child travel unaccompanied and what’s the process for ensuring a guardian picks them up? How do you make arrangements for someone requiring oxygen or a travelling with a guide dog? If a traveller’s flight is cancelled, can you book them on another airline? You get the idea. All this knowledge was encapsulated in a large policy and procedure manual. I’m dating myself by sharing that the P&P manual was a binder with 300 plus printed pages. Every desk in the call centre had a copy. 

A company’s policies and procedures change often, and as a result, revisions to the P&P manual are ongoing. Once a month several boxes would arrive at our reservations office. In each box were packets of pages along with instruction sheets on how to revise the policy and procedure manual. “Turn to page 37. Remove pages 37-39 and replace with the new pages 37-39”. In our call centre there were, perhaps, 250 copies of the manual. I worked in one of about eight call centres spread across North America, Europe and Asia for our relatively small airline. Each month when the boxes of revisions arrived, a supervisor in the call centre would reassign a few agents to spend the morning visiting each workstation to update the P&P with the revisions. Let’s do some informal math: that’s a couple thousand manuals that need 5 minutes of attention or so every month or close to 200 hours of work to replace all those pages – not including the time for headquarters to print, box, and ship the revision packets. Other departments such as Airports, Maintenance, and In-flight Service all had their own P&P manuals and similar processes.

My first job in Information Technology was on a project to make the reservations P&P manual electronic. In the late 1980’s each call centre workstation was equipped with a green-screen mainframe terminal attached to the airline reservation system. The reservation system had a feature called DRS, the Direct Reference System. DRS was similar to an early version of a web site but limited to upper case text and no graphics. My job involved designing a logical structure and entering  the text from those Policy and Procedure Manuals into the DRS. The goal was to reduce the labor required to update the manuals by getting most of the content into the computer system and reduce the size of the printed P&P by including only images and material that didn’t translate well into upper case characters displayed on a mainframe terminal. The project was considered a success and reduced the size of the printed manual to about 20 percent of its original size. The hundreds of hours needed to distribute revisions also dropped to a fraction of the time. More importantly, the process for distributing changes became much more agile. The time needed to get new information into the hands of staff also dropped dramatically. This new approach allowed for the distribution of daily updates to staff via the online system, greatly reducing the need for staff memos and meetings.

Working on that first project allowed me to see the entire series of behind the scenes processes for managing policy and procedure changes and deciding when to release and implement the changes. A team worked with all the related areas of the airline to coordinate policy and procedure changes. Bringing a new type of aircraft into the fleet or the addition of a new destination were examples of business events that would result in considerable changes to procedures. Requests came from all over the company for the call centres to support new or changed business processes. It was someone’s job to manage this “backlog” of requests, prioritize and decide which ones needed immediate attention, and determine which ones could wait until later. Once policies were decided and procedures developed, new DRS pages (and paper manual pages where needed) were created. Updating those DRS pages was now immediate. When an edit was made to a page it was instantly accessible to all staff. This new methodology was effective for daily updates but required coordination for time sensitive material. If a new destination was not coming online for several months, the related pages would need to be updated but not released to staff until they were ready and needed. It became obvious that a release management plan was required to coordinate the distribution of changes.

New and changed P&P pages needed to be created in an environment where they could be developed and refined before they were distributed to the “live” DRS system for all staff to access.

That early experience with paper, and then electronic, P&P manuals was my first introduction to the world of business process design and implementation. There was no code or application configuration, but changes to business processes needed to be developed and distributed by a repeatable series of activities. Those activities increasingly became digital, but the underlying process was fundamentally the same. Intake requests for change, prioritize the requests, design the policies and procedures to ensure consistent, safe, and efficient service delivery, and finally distribute those changes into the hands of the staff that required them.

Does any of this sound familiar? Feature requests, backlogs, prioritization, distribution, and change management? Successful businesses have always been agile. The computer systems just had to catch up to a human way of working. 

Increasingly, policies and procedures are implemented not just as electronic manuals published on company intranets but as no-code and low-code business applications. Business Apps can not only communicate what steps should be taken but can ensure policies are adhered to by embedding business rules and workflows. Staff benefit by having context aware workflows available to them and managers benefit with vastly improved process transparency. Great businesses are constantly improving their knowledge and evolving their way of working. Great business applications capture institutional knowledge and enable your desired way of working.