Morning Operations Meeting
You get paid to deliver a service. You want to deliver that service to the level of your customers’ expectations, or at least to some internally defined level. So how often do you meet to discuss your service delivery quality?
In our experience, most companies meet only when there is a problem. Day in and day out many Software as a Service companies will operate their services throughout the day and simply not take the time to step back and look at the last day’s worth of issues, all open issues that are not yet resolved and diagnose service delivery problems. How could this be you ask? Well, we honestly don’t know!
As we’ve written before, if you are a SaaS company your business is predicated first and foremost on SERVICE DELIVERY! Developing software is important – but what makes you money is the delivery of a service. Get this straight folks, because it is a major mind shift.
In our view, it is absolutely critical to start the business day with a review of the past day’s service delivery. We call this the “Morning Operations Meeting” or “Morning Operations Review”. Every day we ask our clients to review major issues from the previous day, overall service quality (response times, availability, major interruptions or bugs live on the site, etc), and all major open issues identified in past days. Ideally the notion of an incident (a thing that happens in production and causes customer complaint) and the notion of a problem (a thing that causes an incident) are separated in this meeting. Both should be discussed – but they are really two separate things.
Ideally this meeting will have representatives from your customer support organization, technical operations and infrastructure teams and software development teams. Inputs to the meeting are a representation of customer complaints, complaints regarding service within the company, manual identification of issues, automated identification of issues (such as through a monitoring system to include Service Level metrics), predictive identification of future problems (such as might be the case from a capacity management team) and all appropriate service level information.
Open incidents and problems from the issue tracking system are discussed, updated, etc. Owners are assigned to new incidents and problems (if they haven’t been already) and new issues are updated if any were missed from the previous day’s operations.
Outputs from the meeting are updated service level reports, scheduling of post mortems for large incidents, updated problem reports and data for monthly or quarterly look backs or reviews (more on this later).
If done well, the morning meeting helps inform architectural changes that are necessary in the scalability summits or in other product development and architecture meetings. Recurring problems should be easily identified within the issue management as a result of heightened oversight and analysis of the system.