Running productivity software as a dependable service with an operating charter

The difficult part of business productivity software operations begins after the launch project ends. Work is already arriving, colleagues have found shortcuts, permissions are changing and the original implementation team is moving on. A tool can remain technically available while the service built around it becomes unreliable.

This guide is for organisations in England using task, workflow or collaboration software for everyday work. It treats the configured process as an operating service, not merely a subscription.

The public-sector sources below offer useful disciplines, but their requirements do not automatically bind private organisations. Legal, employment, privacy, security and contractual questions need suitably qualified review before publication or implementation.

What to take away

Write an operating charter

Start with one page: what the service is for, who uses it, where its boundary lies. Name work that must enter the system, and work that must not.

Give the authoritative record and the route used when the service is unavailable. If the software is only a coordination layer, say where signed contracts, personnel records or financial evidence must be kept instead.

The charter should answer practical questions:

Do not copy a vendor's feature names into the charter without translating them into the organisation's own process. A column called "Done" is meaningless unless people know whether it means completed, checked, communicated, recorded and accepted.

Map the real route through the work

Follow several recent pieces of work from request to closure. Include an easy case, a rejected request, an urgent exception and an item that crossed a team boundary. This reveals informal messages, duplicate entry and approvals that a tidy process diagram can hide.

Then define the smallest workable route. A useful pattern is intake, triage, ready, active, awaiting input, review and closed. Each state needs an entry condition, an owner and an exit condition. Limit categories and mandatory fields to information that changes a decision. Asking for data that nobody uses slows intake and may create unnecessary personal-data handling.

The Information Commissioner's Office says organisations should embed data protection by design and by default throughout the life of processing. For an England-based operator, data questions become part of workflow design. Decide why a field is needed, who may see it, how long it remains useful and what happens at closure.

A privacy specialist should determine the lawful basis and any assessment required for the actual use.

Give decisions named owners

Software administration is not the same as service accountability. One person may manage licences and groups while another decides priorities, accepts risk or owns the outcome. Record decision rights rather than relying on seniority or memory.

The Government Digital and Data profession describes a service owner as accountable for quality, performance, benefits and outcomes across an end-to-end service. That is a government role description, not a compulsory private-sector job title. Its value is the separation it draws between accountability and daily administration.

At minimum, allocate these functions:

A small firm may combine functions, but combinations should be visible. A person should not silently approve their own high-risk configuration change simply because the team is small. Set a deputy for activities that cannot wait for one individual's return.

Operate access as a routine

Create joiner, mover and leaver steps for the specific service. State who authorises an account, what access a role normally receives, how elevated privileges are granted and when inactive or external identities are reviewed. Use the organisation's identity service where the supplier and risk assessment support it.

The National Cyber Security Centre's guidance on using SaaS securely places attention on authentication, permissions, administration, data, monitoring and incident preparation. It is not evidence that any named product is safe or unsafe. Apply it to the proposed configuration and the sensitivity of the work.

Keep two forms of evidence: the current access state and the decisions that produced it. A periodic review should compare active identities against current employment or contractual need, not simply ask an administrator whether the list looks familiar. Security specialists should set the frequency and any separation of duties.

Build quality into routine delivery

Quality is not a launch-day test. Define what an acceptable item looks like at the point of entry and at completion. Use validation rules where they prevent predictable errors, but retain human review where context or judgement matters.

Government guidance on regular quality assurance recommends that a multidisciplinary team test usability and technical behaviour under normal and unusual conditions. Its audience is public digital-service teams. An ordinary business using configured SaaS can still adopt the principle by checking the complete workflow rather than only whether a button works.

Maintain a compact test set:

Run affected checks after configuration, integration or supplier changes. Record the environment, result, defect owner and decision. Passing a scripted path does not prove accessibility, security, legal compliance or suitability for every user.

Control configuration changes

Treat workflow edits as service changes. The request should identify the problem, affected users, data implications, rollback route and evidence of approval. Test in a safe setting where the supplier permits it, then release to a limited group when the consequence of failure warrants that caution.

Version templates and field definitions. Without a version, two teams can report the same label while following different rules. Keep a short change log showing who authorised the edit, when it took effect and which measures may have broken continuity.

Acas explains that consultation means discussing change and listening to affected employees. The page concerns Great Britain and distinguishes good practice from situations with legal consultation duties. Obtain employment advice if configuration changes monitoring, workload allocation, performance management or contractual arrangements.

Set service standards people can use

Translate "reliable" into observable commitments. Useful candidates include acknowledgement time, time to assign an owner, maximum age of an untriaged item, access-removal time, support coverage, update frequency during disruption and recovery priorities. Do not borrow targets from another organisation without testing staffing, risk and user need.

GOV.UK's reliable-service standard asks public teams to plan for downtime, monitor a service and respond to problems. It also warns against leaving all quality assurance to automated tools. Private operators can use those questions as a diagnostic, while defining their own justified commitments.

For every standard, record its exact start and stop events, exclusions, source data, owner and review interval. "Respond quickly" cannot be audited. "Triage clock starts when a complete request enters the queue" can be measured, provided complete is defined.

Prepare for disruption before it happens

Separate three events: the vendor service is unavailable, the organisation's configuration fails and information may have been exposed or lost. Each needs a different first action. Keep an accessible contact tree, alternative intake route, priority-work list and restoration checklist outside the affected platform.

The NCSC's incident-management collection treats response as a maintained capability linked with business continuity and recovery. Rehearse a plausible event with the people who would make decisions, including communications and supplier escalation. Capture decisions and improvements rather than judging success by whether the exercise ended on time.

If personal data may be involved, preserve facts and escalate immediately through the organisation's breach process. The ICO explains that organisations must assess incidents and report certain personal-data breaches to it. Whether notification is required is a legal judgement; an operations article cannot decide it.

Measure the service, not activity theatre

Counts of tasks created, comments posted or logins made show activity. They do not by themselves show that work is faster, safer or more useful. Begin with the service purpose, then choose a balanced set covering demand, flow, quality and user experience.

Government guidance on setting performance metrics recommends defining the question first, identifying data sources and interpreting numbers alongside user research. Its mandatory measures apply to central-government services in scope, not to every business. The underlying approach helps prevent a dashboard from becoming a substitute for investigation.

Write a metric card for each measure: definition, numerator, denominator where relevant, exclusions, source, owner, frequency and known limitations. Pair speed with quality. A shorter completion time is ambiguous if reopenings or unresolved complaints rise. Break down results carefully enough to find a harmed group, while protecting personal data and avoiding unfair employee inference.

Review suppliers and contracts during operation

The operating team needs advance notice of changes to features, terms, integrations and support. Assign someone to review supplier communications, security information and sub-processor updates, then route material changes to the right specialist. Keep the agreed service description and contract with the decision record so that a new administrator can distinguish purchased commitments from marketing.

Schedule a renewal review before the notice deadline. Examine actual use, unresolved defects, support experience, access population, data exports, total operating effort and credible alternatives. Do not treat renewal as proof that the original business case was correct. Nor should sunk implementation effort alone decide the next term.

Commercial counsel should check variation, renewal, termination, liability and exit wording. Privacy and security reviewers should examine current processing and control evidence. If the workflow supports regulated activity, add the relevant specialist rather than expecting the software owner to interpret the rule.

Establish the first operating month

Before declaring the service routine, complete a short handover:

Hold a review after a real operating cycle, not immediately after training. Bring examples of delayed, rejected, reopened and exceptional work. Decide which problem belongs to the process, the configuration, the supplier or resourcing. Give every accepted change an owner and a date.

The useful outcome is modest: people know where work enters, who decides, what good looks like and how the organisation responds when the normal route breaks. That operating discipline matters more than a crowded board or a long list of enabled features.

Before you act

Common questions

What should an operating charter cover?

One page stating what the service is for, who uses it and where its boundary lies. It should name work that must enter the system, work that must not, the authoritative record and the route used when the service is unavailable. It should also answer who can request work and who is accountable.

Why separate service accountability from software administration?

One person may manage licences and groups while another decides priorities, accepts risk or owns the outcome. The Government Digital and Data profession describes a service owner as accountable for quality, performance, benefits and outcomes across an end-to-end service. Record decision rights rather than relying on seniority or memory.

How should configuration changes be controlled?

Treat workflow edits as service changes. The request should identify the problem, affected users, data implications, rollback route and evidence of approval. Test in a safe setting where the supplier permits, then release to a limited group when failure would be costly. Version templates and keep a short change log.