Keep the application useful after launch.
Organise support, maintenance and controlled improvements around the systems your teams depend on.
What this covers.
Keeping applications running after they are live: incidents, fixes, small changes, dependency and platform updates, and the monitoring that surfaces a problem before a user reports it. Also the knowledge capture that means support does not depend on one person.
How it runs.
An agreed response model with priorities that mean something operationally rather than on paper. Incidents and changes go through the same queue so small changes do not get lost behind them. What was fixed and why is written down, and the recurring causes are raised rather than absorbed.
Where it fits.
After delivery, whether or not we built the application. Taking on support for somebody else's system starts with a handover period, and we will say honestly if the code is in a state where support alone is not enough.
What you get, and what it depends on.
A response model with priorities that mean something operationally, monitoring that surfaces a problem before a user reports it, and recurring causes raised rather than absorbed. It depends on access and a handover period, especially where we did not build the application.
How we can work together
The model is chosen to suit the work, not to suit us. We will tell you when a fixed price is the wrong instrument.
Managed support
An agreed response model covering incidents, fixes and small changes.
Takeover
Support assumed for a system built by somebody else, after a handover.
Standby
Cover for a defined period, such as a go-live or a peak season.
What would a better working day look like?
Bring us the process you want to improve. We’ll explore the product, technology and delivery work it needs.