Owen Sound: A Four-Year City Business Plan

Home › The Public Scorecard › Chapter 46

The Public Scorecard

Chapter 46Services: The Public Service Scorecard

9,963 words · Mike Seiler · Owen Sound, Ontario

Open in the reader →

Vote on the proposals, hear the audio, read the reviews, search the whole plan.

In this chapter

A City can answer every email and still provide poor service.

It can send:

We have received your request.

within five minutes and leave the actual problem unresolved for five months.

It can build an attractive app while residents continue to:

The Services Scorecard should therefore measure more than speed.

It should measure whether municipal service is:

The principle is:

Measure the resident's problem, not merely the City's activity.

The central service question is not:

How quickly did we acknowledge the request?

It is:

Did the resident get the right answer or the problem actually get solved?

46.1Purpose

The Services Scorecard should answer:

Can residents find the right service?

Can they access it without unnecessary barriers?

Does the City respond within a published standard?

Does the response actually mean something?

Does the issue reach the correct person?

Is it resolved within a reasonable period?

Does the resident know what happens next?

Does the City close the loop?

Do recurring problems trigger deeper action?

That is municipal service performance.

46.2Service Is Broader Than Customer Service

Residents are not merely customers.

Municipal government also:

Good service does not mean:

everyone gets the answer they wanted.

It means:

the process is clear, lawful, fair and professionally administered.

46.3A Denial Can Be Good Service

A permit may lawfully be denied.

A complaint may be unfounded.

A request may belong to another government.

Good service can still mean:

Measure the quality of the process.

Not whether the resident received a yes.

46.4Service Scorecard Headline Measures

The public Services Scorecard should include a manageable set of headline indicators such as:

  1. Service requests received.
  2. Meaningful first-response performance.
  3. Resolution-time performance.
  4. Open backlog.
  5. Overdue backlog.
  6. Repeat-contact rate.
  7. First-contact resolution.
  8. No Wrong Door handoff success.
  9. First to Action completion.
  10. Reopened requests.
  11. Resident clarity.
  12. Resident respect.
  13. Accessibility barriers.
  14. Complaints and escalations.
  15. Service-standard exceptions.
  16. Persistent root-cause issues.
  17. Offline and non-digital access.
  18. Service interruptions.
  19. Service corrections.
  20. Overall resident service experience.

Not every department needs every measure.

46.5Service Catalogue Is the Foundation

The scorecard depends on the Service Catalogue established earlier.

Every common resident-facing service should have:

Service name

Responsible department

How to start

Information required

Expected first response

Expected next step

Typical completion standard where appropriate

Escalation route

Without a defined service:

Performance cannot be measured consistently.

46.6Measure the Service Residents Understand

Internal organizational structure should not dominate the public scorecard.

Residents care about:

Not:

46.7Internal Department Still Matters

Behind each public service:

There must be an administrative owner.

No metric should belong to:

the City generally.

Someone owns the process.

46.8Data Owner

Each service measure should identify:

For cross-department service:

Name one accountable lead.

46.9Update Frequency

Recommended public frequency:

High-volume routine services

Quarterly.

Low-volume services

Semi-annually or annually where more meaningful.

Major service interruption

As it occurs.

Resident satisfaction

Quarterly sample or annual stable survey.

Do not create reporting overhead greater than the value of the measure.

46.10Service Standards Need Definitions

A service standard should identify:

Clock Start

When measurement begins.

Clock Stop

When the required response or completion occurs.

Pauses

If any.

Exclusions

If any.

Business Days or Calendar Days

Which one.

Responsible Party

Who controls each stage.

No invisible clock manipulation.

46.11First Response

The first response should mean:

a meaningful response from the City.

Not merely an automated receipt.

46.12Automated Acknowledgement

An automatic message can still be useful.

It should say:

But it does not count as the meaningful-response metric unless the service genuinely requires nothing more.

46.13Meaningful First Response

A meaningful first response may include:

46.14Meaningful Response Rate

A possible core formula:

Meaningful Response Rate = Requests Receiving a Meaningful First Response Within the Published Standard ÷ Eligible Requests × 100

Eligibility rules should be published.

46.15Median First Response Time

Use:

median

where appropriate rather than only average.

Median can better describe the typical experience when a few extreme files distort the average.

46.16Average Still Has Value

The dashboard may show both:

If they differ sharply:

That can reveal outliers.

46.17Do Not Hide the Tail

A median of two days can look excellent while:

Also report the percentage outside standard.

46.18Service Standard Compliance

A simple measure:

Service Standard Compliance = Eligible Requests Completed Within Published Standard ÷ Eligible Requests Completed × 100

Define whether the measure refers to:

46.19Resolution Time

Resolution time means:

time from valid request to the point the municipal issue is completed or a final municipal decision is delivered.

Not all services should have a single resolution target.

46.20Resolution Standard Categories

Possible categories:

Immediate

Emergency systems.

Same Day

Some simple information.

Short Routine

Selected routine administrative matters.

Scheduled Operational

Maintenance or inspection.

Complex

Planning, engineering or legal matters.

Do not force every service into one standard.

46.21Complexity Matters

A:

and

should not be judged against the same clock.

Fair measurement recognizes complexity.

46.22Resident-Controlled Delay

If the City is waiting for:

the public metric should distinguish that time where technically appropriate.

46.23Outside-Government Delay

Likewise:

If the City is waiting for:

show that separately where material.

46.24City-Controlled Time

One of the most useful measures is:

time the file was actively under City control.

This helps identify whether the municipality itself is the bottleneck.

46.25Do Not Stop the Clock Invisibly

Every paused file should have a reason category.

No:

paused

with no explanation.

46.26Clock Abuse

Do not improve performance by repeatedly:

requests to restart the clock.

The anti-gaming rules should prohibit it.

46.27Incomplete Requests

If a service request lacks information:

Respond quickly with:

An incomplete request should not disappear.

46.28Complete Application Versus Inquiry

For regulatory services:

Distinguish:

Do not use casual inquiries to inflate or depress formal processing statistics.

46.29First-Contact Resolution

For appropriate services:

Measure whether the resident received the needed answer without transfer.

A possible formula:

First-Contact Resolution Rate = Eligible Requests Resolved During the First Meaningful Contact ÷ Eligible Requests × 100

46.30Not Every Service Should Resolve First Contact

A building inspection cannot necessarily be completed over the phone.

Use this metric only where appropriate.

46.31Transfer Count

For services involving handoffs:

Track the number of transfers before the request reaches the responsible party.

46.32Handoff Burden

A useful public goal:

Reduce unnecessary handoffs.

A resident should not need to speak with:

to discover who handles the issue.

46.33Repeat-Contact Rate

A strong service measure is:

Repeat-Contact Rate = Requests Requiring Resident Follow-Up Because No Adequate Resolution or Status Was Received ÷ Eligible Requests × 100

The exact methodology should be operationally feasible.

46.34Resident Follow-Up Is Not Always Failure

A complex file may legitimately involve several conversations.

Differentiate:

from

46.35Chasing the City

Where feasible, resident surveys can ask:

Did you have to contact the City again because you did not know what was happening?

This is valuable.

46.36No Wrong Door

No Wrong Door should have its own service measure.

The rule is:

If the resident starts with the wrong public body, help them reach the right one.

46.37Wrong-Door Identification

Track common requests that actually belong to:

This identifies public-information gaps.

46.38Successful Handoff

A successful handoff should mean more than:

here is another phone number.

Where practical, it may include:

46.39No Wrong Door Success Rate

Possible measure:

Successful Handoff Rate = Verified or Resident-Confirmed Correct Referrals ÷ Eligible Wrong-Door Requests × 100

Where verification is too burdensome:

Use resident sampling.

46.40Do Not Create Cross-Government Surveillance to Measure Handoffs

Do not track residents across agencies merely to prove the referral succeeded.

Use:

where possible.

46.41Referral Accuracy

An incorrect referral is worse than saying:

I need to confirm.

Track common misroutes.

46.42Referral Directory Accuracy

Audit the internal No Wrong Door guide regularly.

Government contact information changes.

46.43First to Action

The original source proposed a Standing Work List and a more responsive Town at Work model for visible municipal issues.

The Services Scorecard should measure whether that approach actually improves resolution.

46.44First to Action Request Volume

Show selected routine categories:

46.45First to Action Is Not a Popularity Metric

More reports can mean:

Do not automatically call more reports success or failure.

46.46Completion Rate

Possible formula:

Completion Rate = Eligible Requests Completed ÷ Eligible Requests Due for Completion During the Period × 100

The department should choose a technically sound denominator.

46.47Closure Rate

Do not report only:

tickets closed.

A closed ticket must represent:

46.48Closure Codes

Possible categories:

Completed

Duplicate

Referred

No Action Required

Outside Jurisdiction

Scheduled Capital Work

Unable to Complete

Other Documented Outcome

Publish aggregate categories.

46.49No "Completed" When Deferred

If a pothole request becomes:

road scheduled for reconstruction in 2029

the resident request may be administratively closed.

But the issue should not be reported publicly as:

repair completed.

Use the proper category.

46.50Backlog

The scorecard should show open eligible requests awaiting action.

46.51Backlog by Age

Useful age bands might be:

Do not publish arbitrary bands without operational meaning.

46.52Overdue Backlog

A key measure:

Overdue Backlog = Number of Eligible Open Requests Beyond the Published Service Standard

Show both:

46.53Backlog Is Not Automatically Bad

Seasonal work may intentionally accumulate before:

Explain planned backlog.

46.54Hidden Backlog Is Bad

Work should not vanish into:

where management cannot see it.

46.55Standing Work List

Routine recurring work should appear in the appropriate operational system.

The original plan specifically contemplated a Standing Work List for recurring items such as potholes and lighting.

Measure whether work is:

46.56Scheduled Work

Some requests should legitimately become scheduled maintenance.

Report the scheduled date or window where possible.

46.57Resident Closure

When practical, notify the resident that:

Close the communication loop.

46.58Closure Communication Rate

Possible measure:

Closure Communication Rate = Eligible Requests With Final Status Communicated ÷ Eligible Requests Closed × 100

46.59Anonymous Reports

If the resident reported anonymously:

Closure communication may not be possible.

Exclude appropriately.

46.60Public Status

Some routine public-works issues may have a public aggregate status.

Do not expose:

46.61Reopened Requests

Track issues reopened because:

46.62Reopen Rate

Possible measure:

Reopen Rate = Requests Reopened Within Defined Period ÷ Requests Closed × 100

Use only where useful.

46.63Low Reopen Rate Can Be Good

It may indicate durable resolution.

46.64Extremely Low Reopen Rate Can Also Be Misleading

If residents cannot:

the metric can look artificially good.

Ensure reasonable correction routes exist.

46.65Repeat Location

Track repeated municipal issues at the same location where appropriate.

Examples:

46.66Root-Cause Trigger

Define thresholds that trigger deeper review.

For example:

same issue repeatedly reported at the same asset

may require asset or engineering review.

Avoid rigid universal thresholds.

46.67Root-Cause Cases

Publish aggregate:

46.68Root-Cause Resolution

A repair that prevents repeated calls can be more valuable than faster repeated patching.

46.69Do Not Incentivize Fast Temporary Fixes

If the scorecard rewards only closure speed:

Staff may be pressured toward:

solutions.

Balance speed with repeat-failure measures.

46.70Quality Measure

Where feasible, combine:

No single service metric is enough.

46.71Service Failure

Define a material service failure.

Possible examples:

Use professional definitions.

46.72Service Failure Log

For material recurring failures:

Track:

What failed

cause

correction

completion date

The public does not need employee blame.

It needs system improvement.

46.73Correction Culture

A service organization should be able to say:

Our process failed here.

Then fix it.

46.74No Blame Dashboard

Do not publicly rank individual employees on:

Performance management belongs within proper management processes.

46.75Department-Level Accountability

Publish service performance at:

level where useful.

Not employee league tables.

46.76Resident Respect

A good service scorecard should measure whether residents felt:

46.77Respect Survey Question

Possible stable question:

Were you treated respectfully by City staff during this interaction?

Responses:

Keep it simple.

46.78Respect Is Not Agreement

A resident can be:

and still report respectful service.

That is exactly why the measure matters.

46.79Resident Clarity

Another useful question:

Did you understand the City's answer and what happens next?

46.80Clarity Rate

Possible:

Clarity Rate = Respondents Reporting the Answer and Next Step Were Clear ÷ Survey Respondents × 100

Report response count.

46.81Do Not Overgeneralize Small Surveys

If 37 people responded:

Say:

Among 37 respondents...

Do not claim:

92% of Owen Sound residents.

46.82Satisfaction

Overall satisfaction can be useful.

But it should not replace:

46.83Satisfaction Is Influenced by Outcome

Someone denied a permit may be dissatisfied even if service was excellent.

Therefore:

Use satisfaction as one measure.

Not the measure.

46.84Transactional Survey

Keep post-service surveys short.

Possible questions:

  1. Did you know where to start?
  2. Did you receive a clear answer?
  3. Were you treated respectfully?
  4. Did you understand the next step?
  5. Was the issue resolved?

Five may be enough.

46.85Do Not Survey Every Contact Excessively

Survey fatigue creates bad data.

Use:

46.86No Incentive That Distorts the Survey

Do not offer large rewards that may bias participation.

46.87Accessible Survey

Allow:

options for significant annual resident-service surveys.

46.88Language Accessibility

Where community need supports it:

Provide reasonable language assistance or translated service information.

Do not promise every municipal document in every language.

46.89Plain Language

Service instructions should use ordinary language.

Avoid:

pursuant to subsection...

on the first screen unless legally necessary.

Legal detail can remain available.

46.90Reading-Level Review

For common services:

Test whether instructions are understandable.

Do not turn this into an arbitrary reading-score bureaucracy.

Use real resident feedback.

46.91Accessibility

Every major service should be reviewed for:

accessibility.

46.92Accessibility Barrier Report

Track barriers identified through:

Possible categories:

Fixed

Scheduled

Major Capital Required

Outside City Control

46.93Accessibility Is More Than Website Compliance

A service can have an accessible webpage and still be inaccessible if:

Measure the full service journey.

46.94Non-Digital Service

Track whether common services can still be accessed without:

46.95Digital-Only Exception

Some specialized services may reasonably be primarily digital.

Where digital is mandatory:

There should be a strong operational and legal reason plus accessibility support.

46.96Phone Service

Measure:

where operationally meaningful.

Do not optimize call duration so aggressively that residents are rushed.

46.97Call Abandonment Rate

Possible measure:

Call Abandonment Rate = Calls Abandoned Before Answer After Defined Threshold ÷ Eligible Incoming Calls × 100

Exclude instant hang-ups as appropriate.

46.98Hold Time

Median hold time may be useful for major public phone lines.

46.99Voicemail Response

If residents leave voicemail:

Publish a reasonable response standard.

46.100In-Person Wait

For high-volume counters:

Measure wait time periodically where useful.

Do not install intrusive tracking merely to measure it.

46.101Appointment Availability

For services requiring appointments:

Track time to next available appointment.

46.102Appointment No-Show

If no-shows materially affect service:

Track aggregate rate.

Use reminders where appropriate.

Do not publicly shame residents.

46.103Emergency Service Is Separate

Do not mix emergency:

response metrics into ordinary customer-service measures.

Those require professional public-safety measures.

46.104Emergency Redirect

Every public service tool should clearly instruct residents where an issue may be:

Do not encourage emergency reporting through ordinary municipal request systems.

46.105After-Hours Service

For relevant services:

Explain what is available after normal office hours.

46.106After-Hours Expectations

A resident reporting a routine pothole at:

should not expect immediate repair.

The service standard should make this clear.

46.107Seasonal Services

Snow, grass, leaves and recreation have seasonal patterns.

Set service measures accordingly.

46.108Snow Service

Snow performance may need measures such as:

Detailed infrastructure/winter measures can also appear in Section 47.

46.109Weather Exception

Severe weather may legitimately alter service timing.

Define exceptions.

Do not use:

weather

as a catch-all excuse.

46.110Scheduled Seasonal Work

Publish reasonable seasonal windows for:

Residents should know whether the work is late.

46.111Recreation Service

Measures may include:

Participation itself belongs more fully in Section 52.

46.112Facility Closure

For major recreation or public facilities:

Track unscheduled closure hours where useful.

46.113Service Uptime

Some municipal systems may use an uptime measure.

Examples:

Do not overuse IT-style uptime for services where it is meaningless.

46.114Planned Maintenance

Planned outages should be reported separately from unexpected failure.

46.115Service Interruption Log

Major interruptions should record:

service

start

end

residents affected where estimable

cause

correction

46.116Service Recovery

A mature scorecard asks:

How quickly did normal service return?

46.117Communication During Interruption

Measure whether residents were:

A service failure becomes worse when nobody knows what is happening.

46.118Website Information Accuracy

Audit common service pages regularly.

Track:

46.119Information Correction Time

When an error is found:

How quickly is it corrected?

46.120One Source of Service Truth

Departments should avoid multiple contradictory public instructions.

The Service Catalogue should point to authoritative information.

46.121Printed Information

Where brochures or printed forms exist:

Use:

Old paper guidance can remain in circulation long after online pages change.

46.122Form Burden

Measure selected high-volume forms.

Ask:

46.123Data Minimization

Remove fields the City does not actually need.

Better service and better privacy can align.

46.124"We Already Have That"

Where lawful and operationally appropriate:

Do not repeatedly ask residents for information the City already has and can legitimately reuse for the same purpose.

46.125Purpose Limitation

Do not reuse personal information merely because:

the City already has it.

Privacy rules still apply.

46.126Duplicate Documentation

Track common situations where residents must provide the same document to multiple City departments.

Reduce where lawful.

46.127Interdepartmental Handoff

The resident should not become the City's internal courier.

Where systems permit lawful sharing:

Route internally.

46.128One File Principle

For multi-department applications:

Use one master public-facing file or coordinated reference where practical.

46.129One File Does Not Mean One Database

Departments may still need separate systems for:

reasons.

The resident experience can be coordinated without merging everything.

46.130Service Ownership

Every multi-department file needs a lead.

The lead does not perform every task.

They help coordinate the journey.

46.131Contradictory Advice

Track complaints where two City representatives provided materially inconsistent instructions.

46.132Contradiction Resolution

When found:

Identify the authoritative rule.

Correct:

46.133Do Not Punish Staff for Raising Contradictions

Employees should be encouraged to identify:

That is improvement data.

46.134Escalation

Every service should have an appropriate escalation path.

Possible:

staff lead

supervisor

department head

statutory appeal or external process where applicable

Not every issue belongs to the Mayor.

46.135Councillor Escalation

A councillor may help a resident understand or navigate service.

That should not create preferential queue-jumping.

46.136Political Escalation Is Not Service Priority

A request forwarded by the Mayor should be subject to the same operational priority rules unless there is a legitimate urgency.

46.137Escalation Rate

A high escalation rate may indicate:

Investigate.

46.138Formal Complaints

Track formal service complaints separately from ordinary service requests.

46.139Complaint Categories

Possible:

Protect privacy.

46.140Complaint Resolution Time

Publish aggregate performance.

Do not publish employee disciplinary information.

46.141Complaint Upheld Rate

If the City formally determines whether a complaint is:

aggregate reporting may be useful.

Explain methodology.

46.142High Complaint Rate Is Not Automatically Bad

A strong complaint process may encourage people to report problems rather than give up.

Look at:

46.143Low Complaint Rate Is Not Automatically Good

Residents may not know how to complain.

Accessibility matters.

46.144Ombudsman or Statutory Processes

Where outside complaint or appeal mechanisms apply:

Route residents correctly.

Do not create a City process that falsely replaces a statutory right.

46.145Service Appeals

For regulatory decisions:

Distinguish:

These are different.

46.146Staff Conduct

Allegations about individual employees should be handled:

through proper management.

Not through public scorecard naming.

46.147Harassment of Staff

Respectful service works both ways.

The City should not require staff to accept:

46.148Difficult Resident Is Still Resident

A frustrated or critical resident is not automatically abusive.

Do not label ordinary disagreement:

46.149Behaviour Standard

Use objective conduct standards.

Not political agreement.

46.150Restricted Contact

In rare cases of repeated abusive conduct:

The City may need structured communication rules within law and policy.

These should be proportionate.

46.151Accessibility Before Restriction

Ensure any communication restriction preserves a reasonable route for legitimate municipal business.

46.152Resident Dignity

The scorecard should include:

Were you treated with dignity and respect?

This matters especially when the City is enforcing rules.

46.153Enforcement Service

By-law enforcement should have clear service standards for:

where legally appropriate.

46.154Enforcement Privacy

Do not give complainants confidential details about:

Explain what can and cannot be shared.

46.155Enforcement Closure

A resident may be told:

The matter has been reviewed and handled according to applicable process.

without receiving private enforcement information.

46.156Behaviour, Not Status

Community safety and enforcement should continue focusing on:

rather than labelling people by status.

46.157Planning and Building Service

These services deserve clear public milestones.

Possible:

The detailed housing/business outcomes appear elsewhere.

46.158Planning Time Should Be Stage-Based

Do not publish one processing number that mixes:

46.159Building Inspection Scheduling

Where appropriate:

Track inspection scheduling performance.

46.160Safety Cannot Be Rushed

Do not pressure building officials to approve unsafe work to meet a scorecard.

Standards should measure administration.

Not override professional obligations.

46.161Tax Service

Section 45 measures tax policy.

Section 46 can measure:

46.162Business Service

Section 50 will measure business outcomes.

Section 46 should measure Start-Up Desk service delivery.

46.163Start-Up Desk Service Measures

Possible:

The source commitment proposed a one-window business service and a ten-business-day answer standard or eligible fee waiver.

46.164Ten-Day Standard Measurement

If adopted:

Publish:

eligible files

met standard

missed standard

fee waivers triggered

average City-controlled time

No hidden exclusions.

46.165Ten Days Does Not Mean Permit in Hand

The standard should retain the definition adopted earlier:

Do not misrepresent it.

46.166Service Guarantee

Where a financial consequence exists for missing a service standard:

Track it publicly.

That creates accountability.

46.167Do Not Create Perverse Approval Incentive

A fee waiver should not pressure staff to approve an unsafe or incomplete application.

The financial consequence belongs to the City.

Not public safety.

46.168Housing Navigation Service

Measure:

Do not count an inquiry as:

46.169Seniors Service Access

Measure whether senior residents can access common services through:

without digital compulsion.

46.170Youth Service Access

Youth-oriented services should be:

Do not require unnecessary long-term profiles.

46.171Community Partner Referral

Where the City refers residents to a community organization:

Keep public information current.

Do not promise capacity the partner has not confirmed.

46.172Partner Availability

A directory entry should distinguish:

from

46.173Do Not Make the Partner the Wrong Door

If the City regularly sends people to a partner who cannot accept them:

Correct the referral system.

46.174Community Calendar Service

Measure:

Not just:

46.175Calendar Moderation Standard

Event submissions should have:

No political favour.

46.176Digital Service Score

The Services Scorecard should include selected digital reliability measures.

46.177Online Form Completion

Where practical:

Track form abandonment in aggregate if it can be measured without invasive tracking.

A high abandonment rate may indicate poor design.

46.178Do Not Add Surveillance to Measure Convenience

Do not deploy behavioural tracking merely to learn:

Use privacy-preserving analytics where possible.

46.179Digital Failure Alternative

Every critical public-facing digital service should identify:

What does the resident do if this system is down?

46.180Digital Downtime

Track major public-facing outages.

46.181Planned Versus Unplanned

Separate them.

46.182Accessibility Testing

A digital service is not complete until accessibility is tested.

46.183Mobile Is Not Enough

A website working on a smartphone does not prove it is:

46.184Account Requirement

Track which services require an account.

Ask annually:

Does this account still serve a necessary purpose?

46.185No Universal Account by Default

Residents should not be forced into one universal digital identity for unrelated municipal services without a compelling lawful case.

46.186Privacy-Minimizing Service

Where possible:

Allow residents to:

without identification.

46.187Identity Only When Needed

A tax account may require identity verification.

Reading garbage collection information does not.

Scale identity to risk.

46.188Service Security

Convenience must not weaken:

security.

46.189Fraud Prevention

Where an online service faces fraud risk:

Measure:

at an appropriate aggregate level.

Do not publish exploitable security details.

46.190AI in Public Service

If AI assists with:

measure whether it improves service.

46.191AI Accuracy Sampling

Periodically sample AI-assisted public answers for:

46.192AI Does Not Replace Official Decision

A chatbot response should not be treated as a final:

decision unless the City has explicitly authorized and governed that function lawfully.

46.193Human Escalation

AI-assisted systems need a clear:

talk to a person

route for complex matters.

46.194AI Failure Rate

If an AI tool repeatedly routes people incorrectly:

Turn it off or fix it.

Do not preserve it because it looks innovative.

46.195Translation Assistance

AI-assisted translation may help.

For critical legal or safety information:

Use appropriate verification.

46.196Service by Channel

Where useful, show performance across:

The goal is not to force everyone toward the cheapest channel.

46.197Channel Cost

Internally, the City may study cost per service channel.

Public reporting can summarize where useful.

Do not judge a channel only by cost.

46.198Complex Cases Need Humans

A more expensive human interaction may prevent:

Value matters.

46.199Simple Cases Should Be Easy

Routine information should not require:

Use self-service where it genuinely helps.

46.200Self-Service Success

Measure whether residents actually complete the task.

Not only page visits.

46.201Service Completion Funnel

For selected high-volume online processes:

Show aggregate stages such as:

started

completed

abandoned

required staff correction

This can reveal friction.

46.202No Individual Behaviour Profile

Measure the funnel in aggregate.

Do not build resident behavioural dossiers.

46.203Error Rate

For selected administrative transactions:

Track corrections caused by:

Use aggregate data.

46.204City Error

If City error causes:

develop a correction process.

46.205Resident Error

If many residents make the same error:

The form or instruction may be the real problem.

46.206System Error

Repeated technical failure is a service problem.

Not merely an IT issue.

46.207Rework Rate

Possible measure:

Rework Rate = Transactions Requiring Material Correction or Repeat Processing ÷ Eligible Transactions × 100

Use where it adds value.

46.208Rework Is Cost

Repeat processing consumes:

Reducing rework is a genuine efficiency.

46.209No Wrong Form

The City should minimize cases where residents complete a form only to be told:

wrong form.

Better front-end guidance.

46.210Service Instructions Tested by Residents

Before launching a high-volume new service:

Ask a few ordinary users to test the instructions.

Professional authors often overestimate clarity.

46.211Accessibility Users Included

Include users with disabilities in testing where relevant.

46.212Senior Users Included

Where the service is commonly used by older residents:

Test with them.

46.213Business Users Included

Likewise for business-facing services.

46.214Service Design Is Not Referendum

User testing improves:

It does not transfer lawful professional decisions to focus groups.

46.215Service Cost Per Transaction

For selected high-volume services:

Finance and departments may calculate:

Service Cost per Transaction = Total Relevant Service Delivery Cost ÷ Completed Eligible Transactions

Use carefully.

46.216Cost Per Transaction Can Mislead

A fire inspection and a tax receipt are not comparable.

Use within the same service over time.

46.217Lower Cost Is Not Always Better

A lower cost per transaction may result from:

Read with quality metrics.

46.218Productivity

Good productivity may mean:

Do not use crude counts for complex professional work.

46.219Planning Productivity

One planner handling more files is not automatically better if:

declines.

46.220Public Works Productivity

Likewise:

need context.

46.221Service Demand

Track demand changes.

A department missing standards because volume doubled is different from one missing them at stable volume.

46.222Demand Forecasting

Use service-request history to anticipate:

pressure.

46.223Demand Spike

When a large spike occurs:

Explain it publicly if it affects standards.

46.224Temporary Staffing

Temporary capacity may be justified for:

work.

Show complete cost.

46.225Permanent Staffing

A recurring demand increase may support a permanent business case.

Use actual service data.

46.226Service Staffing Ratio

Avoid generic:

staff per resident

targets.

Different services have different needs.

46.227Workload Evidence

Staffing proposals should use:

46.228Contractor Support

If contractors handle service work:

Include their performance in the resident service outcome.

A resident does not care which employer caused the delay.

46.229Contracted Service Standard

Municipal contracts should include appropriate service expectations where relevant.

46.230Vendor Failure

If a contractor repeatedly fails:

Use contract remedies.

Do not hide poor performance because delivery was outsourced.

46.231Shared Service

Where Grey County delivers a shared service:

The public scorecard should clarify ownership and agreed measures.

46.232No Double Counting

City and County should not both claim:

for the same outcome without explanation.

46.233Cross-Government Service Level

For important shared journeys:

Measure the resident's end-to-end experience.

Examples:

46.234One Passenger, One Applicant, One Resident

The public experience should not fracture because institutions are separate.

46.235Service Equity

The City should review whether some residents face systematically worse service access.

Possible factors may include:

Use appropriate lawful and privacy-respecting methods.

46.236Do Not Build Personal Vulnerability Profiles

Measure barriers through:

methods where possible.

46.237Geographic Service Equity

For physical services:

Look for recurring neighbourhood differences.

Examples:

46.238Geographic Difference Can Be Legitimate

Different road classes or asset conditions can require different service.

Explain the standard.

46.239Political Geography Is Not Legitimate

Ward, neighbourhood or polling results should not determine routine service priority.

46.240Supporter Neutrality

A resident's political support is irrelevant to:

46.241Councillor Neutrality

A councillor should not receive hidden priority for routine requests in their preferred area.

46.242Emergency and Safety Priority

Priority should follow:

Not political influence.

46.243Priority Framework

For routine operational work, possible factors:

  1. immediate safety;
  2. accessibility;
  3. infrastructure damage risk;
  4. service disruption;
  5. age of request;
  6. efficient batching.

Publish broad principles.

46.244No Public Priority Algorithm Needed

The City does not need to expose a detailed formula that could be gamed.

It should explain the principles.

46.245Manual Judgment Remains

Operations require professional judgement.

A scorecard should support judgement.

Not eliminate it.

46.246Service Exceptions

For every service standard:

Publish legitimate exception categories.

46.247Exception Rate

Track how often exceptions are used.

If 60% of files are exceptions:

The standard may be meaningless or the process broken.

46.248Exception Abuse

Do not reclassify difficult files as exceptions to protect the performance number.

46.249Standard Review

Review service standards at least annually.

46.250Raising the Standard

If performance consistently exceeds target and resources support improvement:

Consider a tighter standard.

46.251Lowering the Standard

Only if evidence shows the original standard was:

Explain publicly.

46.252Do Not Lower Because the Dashboard Is Red

Fix the process first.

46.253Service Standard Sunset

A standard may become obsolete when:

changes.

Replace it transparently.

46.254Baseline

The first year should establish baseline performance before aggressive targets.

Possible baseline:

46.255No Fictional Historical Data

If the City did not previously track:

do not estimate past numbers merely to create a trend.

Start honestly.

46.256Unknown Baseline

Use:

Baseline not previously measured.

Then establish it.

46.257Four-Year Trend

Where comparable:

MeasureBaselineYear 1Year 2Year 3Year 4

46.258Core Trend Measures

Strong candidates:

46.259Traffic Lights

If using:

publish thresholds.

46.260Grey Is Legitimate

Use grey when:

Do not manufacture confidence.

46.261Green Does Not Mean Perfect

Green means:

meeting the published standard.

There can still be individual failures.

46.262Red Does Not Mean Department Is Bad

Red means:

the measure needs action.

Avoid blame culture.

46.263Trend Arrow

A red metric improving rapidly can be important.

Show:

46.264Public Notes

Each major metric should have a short explanation of:

46.265No Greenwashing With Narrative

If backlog doubled:

Do not write:

We continued to enhance service capacity.

without stating backlog doubled.

46.266No Doom Language Either

If a metric worsens slightly:

Do not call:

Use proportional language.

MeasureBaselineCurrentStandardTrendStatusOwner

Possible rows:

46.268Service-Level Drilldown

Residents should be able to move from:

City-wide service performance

into selected services.

Do not publish 400 metrics on the home page.

46.269High-Volume Services First

Prioritize public detail where:

46.270Low-Volume High-Risk Services

Some low-volume services also deserve attention because of:

46.271No Metric Because It Is Easy

Do not measure:

merely because it is easy.

Measure what reflects public value.

46.272No Metric Without Decision Use

Every metric should answer:

What would we do differently if this worsens?

If the answer is:

nothing,

question why it is on the scorecard.

46.273Metric Owner

Every metric should have:

46.274Data Quality Review

Periodically audit whether staff are coding requests consistently.

A beautiful dashboard built on inconsistent data is misleading.

46.275Definitions Manual

Maintain a technical definitions page.

For each metric:

formula

inclusions

exclusions

data source

update frequency

limitations

46.276Versioning

If definition changes:

Record:

46.277Historical Restatement

If technically possible:

Restate prior periods using the new method.

If not:

Mark the break in trend.

46.278No Quiet Metric Change

Never change the denominator because performance looks bad.

46.279Data Integrity

Service-management systems should preserve enough history to verify public reporting.

46.280Privacy

Public data should be:

where appropriate.

46.281Small Numbers

Do not publish small-category data where it could reasonably identify:

46.282Sensitive Services

Use additional care for:

services.

46.283No Heatmaps of Vulnerability

Do not map vulnerable households to improve service analytics.

46.284Service Mapping

Map:

Not vulnerable people.

46.285Open Data

Publish safe service datasets where useful.

Examples:

46.286No Complaint Address Dump

An open-data commitment does not require publishing every:

Protect residents.

46.287Records

Service requests are municipal records and should follow applicable records management.

46.288Retention

Do not keep every service interaction forever merely because storage is cheap.

Follow lawful retention.

46.289Resident History

A service system should not become a permanent:

problem resident

profile.

Each file should be handled on its facts.

46.290Service Flags

Some legitimate operational flags may exist for:

They require appropriate governance.

Not political or behavioural scoring.

46.291Public Access to Own File

Where law and systems permit:

Residents should understand how to obtain relevant records or status.

Do not promise access to information the City cannot lawfully disclose.

46.292Correction of Resident Information

Where a resident identifies incorrect personal or application information:

Provide the applicable correction process.

46.293Service Quality and Open Government

The public scorecard should reveal failures before:

are needed.

Aggregate operations should be open by default.

46.294Individual Privacy Remains

Open Government does not mean open resident files.

46.295Quarterly Service Review

Each quarter:

Senior administration should review:

  1. standards missed;
  2. backlog;
  3. repeat contact;
  4. service interruptions;
  5. complaint themes;
  6. root-cause cases.

Then assign corrections.

46.296Council Review

Council should receive high-level performance.

Council should not micromanage individual routine requests.

46.297Mayor Review

The Mayor can ask:

Why is this service standard failing?

The Mayor should not say:

Move this person's file ahead.

46.298Resident Review

Residents should be able to challenge whether:

reflects actual experience.

46.299Staff Review

Frontline employees should also be able to say:

This metric is creating bad behaviour.

Listen.

46.300Metric Harm Review

At least annually ask:

Did any scorecard measure create a perverse incentive?

Examples:

Fix it.

46.301Service Standard and Staffing

If standards remain missed because:

Council must choose:

add capacity

reduce scope

change standard

improve process

Do not pretend the problem does not exist.

46.302Technology Is Not Automatic Answer

A bad process digitized remains a bad process.

Fix workflow before buying software.

46.303Software Business Case

Any service-management software should show:

46.304No App Requirement

First to Action should work through more than:

where practical.

Possible entry channels:

46.305One Back End, Many Front Doors

Residents may choose different channels.

The City should route them into a coordinated operational system.

46.306Duplicate Detection

The system should help identify:

without discarding valid new information.

46.307Duplicate Does Not Mean Resident Ignored

A resident reporting an already known issue should still receive:

This has already been reported. Current status is X.

where possible.

46.308Public Issue Count

Do not count ten reports of the same pothole as:

ten potholes fixed.

Separate:

46.309Unique Issue Measure

Where technically feasible:

Track:

This improves interpretation.

46.310First Report to Completion

For physical service:

Measure from:

not last duplicate report.

46.311Proactive Work

Not all service should originate in resident complaints.

The City should also identify problems through:

46.312Complaint Reduction Can Be Good or Bad

Fewer reports may mean:

or

Cross-check with:

46.313Proactive Detection

For selected services:

Measure percentage of issues identified proactively before resident complaint.

Use where meaningful.

46.314No Incentive to Hide Problems

Proactive detection should not penalize staff by making issue counts look worse.

The culture should reward knowing reality.

46.315Resident Time

One long-term service objective should be:

reduce unnecessary resident time spent dealing with City Hall.

46.316Resident Time Cost

Where useful:

Survey:

Do not attempt to assign a fake dollar value to every resident minute unless methodology is strong.

46.317One-Visit Completion

For selected in-person services:

Track whether residents can complete the process in one visit.

46.318One-Visit Is Not Always Possible

Complex services may require multiple stages.

Measure appropriate journeys.

46.319Documents Required

Publish checklists before residents arrive.

A missing-document return trip is preventable service failure when instructions were unclear.

46.320Appointment Preparation

Send residents:

Simple service improvement.

46.321Cancellation

If the City cancels an appointment:

Provide prompt rescheduling.

Track repeated City cancellations.

46.322Resident Cancellation

Do not mix resident no-shows into City service-failure statistics.

46.323Service Equity by Channel

Check whether:

users receive materially worse standards than digital users.

Digital residents should not become first-class residents.

46.324Digital Incentive Versus Penalty

The City may encourage efficient online service.

Avoid unreasonable penalties for residents needing another channel unless the fee reflects a legitimate cost and is lawful.

46.325Service Continuity

Each critical resident-facing service should identify:

46.326Power Failure

Can essential service continue?

46.327Internet Failure

Can staff still provide critical information?

46.328Vendor Outage

Can residents still:

through an alternative?

46.329Labour Disruption

Service continuity plans should respect lawful labour relations and essential obligations.

46.330Building Closure

Can key services move to:

46.331Continuity Exercise

Test selected high-priority resident services during emergency exercises.

46.332Recovery Time

Track how long a material service remained unavailable.

46.333Public Status During Outage

Residents should know:

46.334No False ETA

If restoration time is unknown:

Say:

Unknown. Next update at 2 p.m.

Better than inventing certainty.

46.335Service Reliability

For key digital or facility services:

Track unplanned downtime.

46.336Reliability Target

Targets should reflect:

A recreation booking page and emergency communications are not equal.

46.337Maintenance Window

Planned maintenance is legitimate.

Provide notice.

46.338After-Action Review

Material outages should produce:

46.339Resident Compensation

Where adopted policy provides:

for service failure:

Apply consistently.

46.340No Ad Hoc Mayoral Refund

Compensation should follow policy.

Not personal intervention.

46.341Service Cost Transparency

For high-cost public services:

Provide broad cost information.

Do not calculate individual resident worth.

46.342Unit Cost

Selected services can use unit-cost trends internally and publicly where useful.

46.343Complete Cost

Include:

where methodology supports it.

46.344Do Not Weaponize Overhead

Administrative cost can be necessary.

Use consistent allocation.

46.345Benchmarking

Compare service performance with peer municipalities where:

are similar enough.

46.346Apples to Apples

Do not compare:

with another city's differently defined service.

46.347Benchmark Purpose

Ask:

Why are they faster or cheaper?

Not:

They are faster, so copy them.

46.348Local Conditions

Winter, geography, staffing and service structure matter.

46.349Resident Expectations

Scorecards can change expectations.

Do not promise impossible standards simply because another municipality advertises them.

46.350Service Guarantee Standard

A guarantee should exist only when the City can:

it.

46.351Transparency Before Guarantee

It may be better initially to publish:

current average

than an unrealistic promise.

46.352Improvement Target

Once baseline is known:

Set a realistic target.

46.353Year One Service Target

Establish reliable measurement.

46.354Year Two Service Target

Improve recurring bottlenecks.

46.355Year Three Service Target

Institutionalize strong standards and resolve persistent friction.

46.356Year Four Service Target

Demonstrate stable service performance that can survive leadership transition.

46.357Four-Year Service Test

At term end:

Ask:

Did meaningful response improve?

Did overdue backlog decline?

Did residents repeat themselves less?

Did No Wrong Door improve?

Did clarity improve?

Did accessibility improve?

Did root-cause repair reduce repeat problems?

Did service remain equal regardless of politics?

That is the real record.

46.358Service Failure Disclosure

The final report should include significant service areas that did not improve.

Do not publish only winners.

46.359Persistent Red Metric

If a metric remained red for multiple years:

Explain:

46.360Service Success Example

A strong final example might say:

Meaningful response compliance improved from 68% at baseline to 92% in Year Four while repeat-contact rate fell from 24% to 11%.

Only use numbers if real data supports them.

Do not pre-fill fictional results.

46.361No Predetermined Success Numbers

The business plan should define:

Actual future results belong to the future scorecard.

46.362Service Scorecard Public Page

The first view should show:

Response

Did we answer meaningfully?

Resolution

Did we finish?

Backlog

What remains?

Repeat Contact

Did residents have to chase us?

Handoffs

Did No Wrong Door work?

Experience

Was it clear and respectful?

Accessibility

Could everyone reasonably use the service?

Root Cause

Are repeat problems being fixed?

Simple.

46.363Drill Down

Residents who want more detail can view:

46.364Do Not Build a Data Maze

More filters do not automatically create transparency.

Keep the core clear.

46.365Printable Service Report

Provide a simple quarterly or annual printable summary.

46.366Accessibility

All charts should also be available as:

46.367Colour

Do not use colour as the only status indicator.

46.368Last Updated

Every service page shows:

46.369Data Caveat

If data quality is still improving:

Say so.

46.370Correction Log

Material scorecard corrections should enter the public Correction Log.

46.371Election-Year Integrity

Year Four service reporting should continue on the same schedule and methodology.

46.372No Service Metric Campaign Manipulation

Do not:

during the election period.

46.373Incumbent Does Not Own the Scorecard

The scorecard belongs to:

46.374Candidates Can Debate It

Good.

That is the point.

46.375Staff Should Not Defend Politicians

Staff can explain:

They should not be asked to argue:

why the Mayor deserves credit.

46.376Public Service Credits the Institution

Where performance improves:

Recognize:

Not one politician.

46.377Four-Year Handoff

The next Council should receive:

46.378No Reset to Zero After Election

The next administration should not need to rediscover:

Preserve history.

46.379Future Council Can Change Standards

Yes.

But any change should:

46.380Resident Service Rights

The Scorecard does not create a new legal right to every stated service time unless law or Council policy expressly does so.

Use accurate wording.

46.381Published Commitment Still Matters

Even where not legally enforceable:

A published service standard is a public management commitment.

Misses should be visible.

46.382Service Standard Is Not Individual Entitlement to Queue Jump

A resident beyond standard deserves:

Not necessarily priority ahead of more urgent safety work.

46.383The Service Balance

The City should balance:

Speed

Accuracy

Fairness

Accessibility

Cost

Safety

Privacy

A service system that optimizes only one will often fail another.

46.384Speed Test

How quickly did we respond?

46.385Accuracy Test

Was the answer correct?

46.386Resolution Test

Did we actually solve or decide the matter?

46.387Clarity Test

Did the resident understand it?

46.388Fairness Test

Would another resident in the same situation receive the same treatment?

46.389Accessibility Test

Could the resident reasonably use the service?

46.390Privacy Test

Did we collect only what was necessary?

46.391Cost Test

Did the method provide reasonable public value?

46.392Root-Cause Test

If this keeps happening, why?

46.393No Wrong Door Test

If this is not our service, did we help the resident find the correct one?

46.394Closure Test

Did we tell the resident what happened?

46.395Repeat Contact Test

Did the resident have to chase us?

46.396Institution Test

Would this service still work if the Mayor changed tomorrow?

46.397What Success Looks Like

Success is not:

City Hall answered 100,000 contacts.

Success is:

46.398What Failure Looks Like

Failure includes:

46.399The Public Service Scorecard Commitment

Owen Sound should commit to:

Define every common public service clearly before measuring it.

Give every service an accountable administrative owner.

Publish realistic service standards.

Define exactly when each service clock starts, stops and pauses.

Never count an automated acknowledgement as a meaningful response when additional City action is required.

Measure meaningful first-response performance.

Measure resolution performance where a resolution standard makes sense.

Use median and outlier information where averages hide the real resident experience.

Show the percentage of files outside the standard.

Distinguish City-controlled delay from applicant and outside-government delay.

Never stop a service clock invisibly.

Never close and reopen files simply to improve performance statistics.

Respond promptly when information is missing and explain exactly what the resident must provide.

Distinguish informal inquiries from complete formal applications.

Measure first-contact resolution only for services where first-contact resolution is realistic.

Reduce unnecessary transfers.

Measure whether residents had to chase City Hall for status.

Make No Wrong Door a measurable service standard.

Maintain current referral information for Grey County, Ontario, Canada and community partners.

Help residents reach the correct government rather than simply saying "not us."

Do not create cross-government tracking merely to prove a referral succeeded.

Measure First to Action by actual outcomes rather than app activity.

Show routine service requests received, completed, open and overdue.

Do not count duplicate reports as multiple completed problems.

Use honest closure categories such as Completed, Referred, Duplicate, Scheduled and No Action Required.

Never call a deferred issue completed merely because its service ticket was closed.

Publish backlog and overdue backlog.

Explain seasonal or deliberately batched backlog.

Prevent work from disappearing into invisible personal systems.

Use Standing Work Lists for recurring operational work where they improve coordination.

Communicate final status to residents where possible.

Track reopened requests where they reveal incomplete or temporary fixes.

Use repeated issues at the same location to trigger root-cause review.

Balance closure speed with repeat-failure measures so staff are not pushed toward temporary fixes.

Maintain a Service Failure Log for recurring system problems.

Do not use the public scorecard to rank individual employees.

Measure whether residents were treated respectfully.

Measure whether residents understood the answer and next step.

Keep resident surveys short and optional.

Never overstate small survey samples.

Treat satisfaction as one measure rather than the final measure.

Provide accessible ways to complete significant resident-service surveys.

Use plain language in common service instructions.

Test service journeys for physical, digital and communication accessibility.

Do not treat website compliance as the complete accessibility experience.

Preserve reasonable non-digital service channels.

Measure telephone and appointment performance where those channels matter.

Do not pressure telephone staff to shorten conversations at the expense of solving the problem.

Keep emergencies out of ordinary service-request systems.

Publish seasonal service expectations.

Use weather exceptions honestly rather than as a generic excuse.

Track major unscheduled facility or digital service interruptions.

Communicate clearly during service interruptions.

Audit public service information for outdated or contradictory guidance.

Give printed material version dates.

Reduce unnecessary form fields and duplicate documentation.

Do not ask residents repeatedly for information the City can lawfully reuse for the same purpose.

Do not reuse information for unrelated purposes simply because the City already holds it.

Use coordinated public-facing files for multi-department matters where practical.

Do not assume one coordinated resident experience requires one giant database.

Give multi-department files a lead owner.

Track recurring contradictory instructions and correct the source.

Give every service an appropriate escalation route.

Do not allow councillor or mayoral involvement to create routine queue-jumping.

Track formal service complaints separately from ordinary requests.

Protect employee and resident privacy in complaint reporting.

Keep service complaints separate from statutory appeals.

Protect staff from threats and harassment while distinguishing harassment from ordinary criticism.

Use objective conduct standards.

Preserve a reasonable route for legitimate municipal business even when contact restrictions are necessary.

Keep enforcement service clear while protecting confidential enforcement information.

Measure regulatory service stages separately rather than hiding delays in one blended number.

Never rush professional safety decisions to improve service statistics.

Measure the Start-Up Desk against the adopted service standard and fee-waiver guarantee.

Keep the ten-business-day standard tied to its actual definition rather than pretending every application is fully approved within ten days.

Do not allow a service guarantee to create an incentive for unsafe approval.

Measure Housing Navigation as a service rather than claiming inquiries as homes.

Ensure seniors can obtain essential information without digital compulsion.

Protect youth-service privacy.

Keep community-partner referrals current and do not promise partner capacity that does not exist.

Measure Community Calendar quality, not simply listing volume.

Measure digital service completion rather than website visits alone.

Do not add behavioural surveillance merely to measure online convenience.

Provide a fallback when critical digital services fail.

Review whether service accounts are actually necessary.

Do not require universal digital identity for unrelated ordinary services by default.

Require identification only in proportion to the service risk.

Measure whether AI-assisted service improves routing and accuracy before expanding it.

Keep a human escalation route.

Disable AI systems that repeatedly provide incorrect municipal guidance.

Verify critical translated or AI-assisted public information appropriately.

Compare service channels without forcing residents into the cheapest one.

Keep humans available for complex cases.

Make simple cases genuinely simple.

Use service-completion funnels only with privacy-respecting aggregate analytics.

Track repeat work caused by City, resident or system errors where useful.

Treat repeated resident errors as a possible design problem.

Use resident testing before launching major new public processes.

Include people with disabilities and appropriate service users in testing.

Use cost-per-transaction metrics only within comparable services and never without quality measures.

Use actual service demand when making staffing decisions.

Support permanent staffing requests with workload, backlog, overtime and service-standard evidence.

Hold contractors accountable for the resident outcome as well as the contract deliverable.

Measure shared services across the resident's full journey where possible.

Review service equity without creating personal vulnerability profiles.

Review geographic differences in physical service while respecting legitimate service classifications.

Never allow political geography or voting patterns to determine routine service priority.

Use safety, accessibility and service consequence as priority factors.

Allow professional judgment within transparent principles.

Publish service-standard exception categories.

Track whether exceptions are being overused.

Review service standards annually.

Do not lower standards merely because the dashboard is red.

Start with an honest baseline even where prior data does not exist.

Never manufacture historical performance figures.

Use Grey or Unknown when measurement quality is insufficient.

Publish the definitions behind every scorecard status.

Give every public metric a decision purpose.

Remove metrics that create no useful management action.

Audit data quality and coding consistency.

Version metric definitions when they change.

Never quietly change a denominator to improve performance.

Publish service data in aggregate and protect small or sensitive groups.

Never create public heatmaps of vulnerable residents.

Publish safe service data where it creates public value.

Never dump complaint narratives or private addresses in the name of open data.

Retain service records according to lawful need rather than forever by default.

Never create a permanent "problem resident" profile.

Review standards, backlog, repeat contact and root causes every quarter.

Keep Council focused on service systems rather than individual queue management.

Allow frontline staff to identify metrics that create bad behaviour.

Review scorecard measures annually for perverse incentives.

Use persistent service failure to drive real budget or process decisions.

Do not assume software is the solution to a bad process.

Require public-service technology to have accessibility, privacy, portability and exit.

Allow multiple resident front doors to feed a coordinated internal workflow.

Notify residents when a duplicate issue is already known and give current status where possible.

Use the first valid report, not the latest duplicate, when measuring a physical issue's age.

Measure proactive maintenance alongside resident reports.

Do not assume fewer complaints automatically mean fewer problems.

Reduce unnecessary resident time spent navigating government.

Publish document checklists before appointments or applications.

Track City-caused repeat visits and cancellations.

Ensure non-digital residents do not receive systematically worse service.

Maintain continuity plans for critical resident-facing services.

Test what happens during internet, power, vendor or building outages.

Tell residents honestly when restoration time is unknown.

Measure service reliability according to its public importance.

Apply refunds or fee consequences consistently where adopted policy provides them.

Never issue ad hoc political refunds.

Use service-cost measures carefully and in context.

Benchmark only comparable services.

Use peer performance to ask questions rather than automatically copy.

Do not promise service guarantees until the City can define, measure and honour them.

Use Year One to establish baselines, Year Two to fix recurring bottlenecks, Year Three to institutionalize strong standards and Year Four to prove those standards survive leadership transition.

Publish service failures that remain unresolved at the end of the term.

Do not predetermine successful future numbers.

Use the same scorecard methodology through the election year.

Do not suppress poor service data because it harms an incumbent.

Keep staff responsible for explaining data rather than defending politicians.

Preserve service history for the next Council.

Allow future Councils to change service standards through an open, documented decision.

Treat published standards as serious management commitments without falsely describing every target as a statutory right.

Balance speed, accuracy, fairness, accessibility, cost, safety and privacy.

Measure the resident's problem, not simply the City's activity.

The Services Scorecard should make a simple promise possible:

If you contact Owen Sound about a municipal issue, you should know where your request went, what happens next and whether the City actually finished the work.

If the answer belongs to another government:

We should help you find it.

If the answer is no:

We should explain why.

If the City misses its own standard:

You should be able to see that.

If the same problem keeps coming back:

We should ask why.

And if our service system creates frustration:

We should measure the frustration as an operating problem, not dismiss it as a communications problem.

That is the difference between a government that counts contacts and a government that manages service.

Report once. Route correctly. Respond meaningfully. Resolve the issue. Close the loop. Measure what keeps coming back.

← Chapter 45: Tax: The Public Tax Pressure ScorecardChapter 47: Infrastructure: The Public Infrastructure Scorecard →