The Unexpected Consequences of a Standardised System
About this practice test
A critical case study of Marlow’s OneForm platform, tracing its early gains, the distortions caused by excessive standardisation, and the reforms that restored room for local judgement.
What you’ll practice
Finding detail
Locate specific information and evidence.
Interpreting ideas
Connect main points and inferences.
Evaluating arguments
Assess claims, evidence, and limitations.
What to expect:
2 questions with explanations to review after submission.
Study the questions and tasks
Work through the material below, or start the interactive practice above to complete an attempt. Try the exercises before opening any answer or transcript sections, then use them to review your work.
- Practice level
- C2. Try this level if you can follow the instructions and understand most of the language; choose an earlier level if you need more support.
- Question formats
- Cloze (dropdown)
How to approach this practice
Read the passage for its main idea, then return to the relevant sentence or paragraph for each question. Base answers on the passage.
The Unexpected Consequences of a Standardised System
In the spring after a series of embarrassing service delays, the city of Marlow adopted OneForm, a platform intended to replace a patchwork of departmental screens, paper slips, and email chains. Residents would submit every request through a single digital form. The language used by the project team was careful and almost disarmingly modest: no one claimed that the city would become wiser overnight, only that all problems could be made comparable. That promise appealed to budget officers, because budgets favor things that can be lined up, counted, and contrasted. It also appealed to managers who were tired of arguing across silos about whose numbers were real. The first months looked like a small triumph. Requests moved faster than the old paper route, and the dashboard produced what executives called a cleaner picture. For the first time, they could see that one district logged twice as many streetlight complaints as another, or that leaks in public buildings peaked after heavy rain. The system seemed especially useful because it did not merely store data; it rearranged it into a common shape. A director who once spent meetings explaining why one department's figures could not be compared with another's now had a chart that appeared to settle the matter. It was tempting, then, to assume that standardisation had made the city more objective. The trouble was that objectivity on a screen is often purchased by compression. Frontline staff began to translate awkward cases into the nearest category, because the software rewarded speed and punished ambiguity. A resident who reported a cracked path, a tree root, and a blocked drain in one phone call had to be broken into separate tickets. The work looked neat afterwards, but only because the mess had been cut into fragments, and the small details that later proved decisive were lost along the way. By the second quarter, several teams had discovered that the quickest way to satisfy the dashboard was to close tickets on the first pass and let follow-up complaints become someone else's problem. In that sense, the system was efficient, but only if efficiency meant moving the problem out of sight. The deeper irony was that the very metrics designed to support accountability began to narrow judgment. Staff members learned that a complicated case could damage their average if they recorded it honestly, so some of them smoothed the edges of reality. A leaky roof might be entered as a simple maintenance visit, even when it had triggered repeated ceiling damage. A school whose heating failed in five classrooms would look manageable if each room was logged separately. The hidden costs were not visible in the first reports. On paper, the city was improving; in practice, it was accumulating what one supervisor called good on the dashboard but slow in the street. The phrase stuck because it captured the mismatch between the official picture and the lived one. Citizens adapted too. They are often treated as passive users of public systems, but they learn the rules quickly when those rules affect whether anything gets fixed. People discovered which words produced a faster response, which category led to a visit from a senior inspector, and which forms vanished into routine queues. Some learned to exaggerate urgency; others deliberately simplified a complaint so it would fit the system at all. The result was not dishonesty in any crude sense. It was a kind of strategic translation, the civic equivalent of speaking in code to a machine that understood only the language of its own boxes. Standardisation had not eliminated interpretation; it had merely moved interpretation to the front door. The consequences were uneven. For repeated, well-defined tasks, OneForm did exactly what it promised. But for services whose value depended on local knowledge, the system flattened differences that should have remained visible. A park team dealing with old trees needed one set of judgments; a housing officer handling vulnerable tenants needed another. Once both were squeezed through the same templates, the city could compare them more easily and understand them less well. Some of the most experienced staff became critics not because they hated order, but because they knew that order can become blind when it is asked to do too much. Their complaint was not that the software was useless, but that it was too successful at making unlike things look alike. In response, the quieter forms of resistance began. Teams kept shadow spreadsheets to record the context that the official system ignored. Others used local codes in parallel with the central categories, a compromise that restored nuance while increasing the risk of inconsistency. None of this was dramatic; there were no rebels in the heroic sense, only employees trying to repair the gap between how work was described and how it was actually done. That gap mattered, because it determined whether the council learned from experience or merely repeated it under new labels. The irony, again, was that the standardised platform generated more data than before, yet some of the most useful knowledge survived only outside the platform. Eventually, the leadership accepted that the problem was not standardisation itself but its reach. They added a free-text field for unusual cases, created an exception route for urgent cross-department problems, and allowed certain teams to retain local codes where the common template proved too blunt. The language changed as well. Senior managers stopped saying that the template was a rule and started calling it a floor, not a ceiling. That shift was small but important: a floor can support variation, whereas a ceiling limits it. The council did not abandon the system; it taught itself how to use it without mistaking uniformity for understanding. What made the episode interesting was not simply that technology had unexpected consequences, but that those consequences were embedded in a plausible success. The system did speed things up. It did make some comparisons fairer. It did reveal patterns that had been hidden in departmental habits. Yet it also altered incentives, encouraged selective reporting, and exported judgment to the places least equipped to carry it. The lesson is not that standardisation is a mistake. It is that standardisation is rarely neutral: it changes what can be seen, what can be said, and which forms of uncertainty get tolerated. In Marlow, the platform was flexible only in the wrong places.
-
Question 1 · Cloze (dropdown)
Choose the correct option for each blank.
Complete the summary below. Choose ONE option from the list for each gap. At first, Marlow introduced 1___ so that complaints from different departments could be handled together. Officials believed that 2___, which would produce a 3___ for managers. However, staff soon began to send awkward cases into 4___, and in doing so they lost 5___. The process therefore looked efficient while concealing 6___.
Return to the passage, recording or visualChoices for blank 1
- local codes
- a single digital form
- a free-text field
- shadow spreadsheets
Choices for blank 2
- all problems could be made comparable
- local knowledge would be preserved
- urgent cross-department problems would disappear
- all tickets could be closed quickly
Choices for blank 3
- floor, not a ceiling
- hidden costs
- strategic translation
- cleaner picture
Choices for blank 4
- the nearest category
- a free-text field
- the wrong places
- its own boxes
Choices for blank 5
- small details
- local codes
- hidden costs
- repeated complaints
Choices for blank 6
- the wrong places
- urgent cross-department problems
- hidden costs
- a cleaner picture
Check answers and explanations
- Blank 1
- a single digital form
- Blank 2
- all problems could be made comparable
- Blank 3
- cleaner picture
- Blank 4
- the nearest category
- Blank 5
- small details
- Blank 6
- hidden costs
Gap 1: The city initially replaced its patchwork system with a single digital form, through which every request was submitted. Gap 2: The project team promised that all problems could be made comparable. Gap 3: The dashboard gave managers what executives called a cleaner picture. Gap 4: Staff translated awkward cases into the nearest category. Gap 5: This fragmentation caused small details to be lost. Gap 6: The apparently efficient process concealed hidden costs, including unresolved problems and misleading reports.
Residents would submit every request through a single digital form
the dashboard produced what executives called a cleaner picture
Frontline staff began to translate awkward cases into the nearest category
local codes: These come later as a response to the platform, not as the initial tool.
a free-text field: This appears later, when the leadership tries to repair the system's limits, not at the beginning.
shadow spreadsheets: This is part of the later workaround by staff, not the original replacement.
local knowledge would be preserved: The passage says the opposite: the standardised system flattened local differences.
urgent cross-department problems would disappear: The text does not claim that problems disappeared; it says they became comparable.
all tickets could be closed quickly: Speed was an effect, but the passage says the aim was comparability rather than fast closure.
floor, not a ceiling: That phrase belongs to the later reformulation of the template, not the early dashboard.
hidden costs: These are concealed later; they are not the direct description of the dashboard's appearance.
strategic translation: This describes how citizens and staff adapted later, not the dashboard's output.
a free-text field: This is a later repair to the system, not the category staff were forced to use.
the wrong places: That phrase describes where flexibility failed, not where staff sent awkward cases.
its own boxes: The passage uses this idea to describe the machine's limits, but not the exact summary point here.
local codes: These are part of the later workaround by teams, not what was lost in the summary's early stage.
hidden costs: Those costs appear later as a result of the system, not the details lost during compression.
repeated complaints: The passage mentions follow-up complaints, but not as the missing element in this sentence.
the wrong places: This phrase is about where flexibility failed, not the losses created by the process.
urgent cross-department problems: These are later managed by an exception route, not what the early process concealed.
a cleaner picture: That describes the first dashboard view, not the negative consequences.
-
Question 2 · Cloze (dropdown)
Choose the correct option for each blank.
Complete the summary below. Choose ONE option from the list for each gap. Later in the story, residents learned that writing to the platform was itself 1___, because the wording of a complaint could determine the response it received. To preserve context, some teams kept 2___, while others relied on 3___ beside the central system. The council then added 4___ for unusual cases and began to describe its template as 5___. The final lesson is that standardisation can be useful, but only if flexibility is provided in 6___.
Return to the passage, recording or visualChoices for blank 1
- local codes
- shadow spreadsheets
- strategic translation
- cleaner picture
Choices for blank 2
- single digital form
- the nearest category
- free-text field
- shadow spreadsheets
Choices for blank 3
- hidden costs
- cleaner picture
- good on the dashboard but slow in the street
- local codes
Choices for blank 4
- a free-text field
- a single digital form
- the nearest category
- local codes
Choices for blank 5
- a cleaner picture
- the wrong places
- a floor, not a ceiling
- all problems could be made comparable
Choices for blank 6
- its own boxes
- hidden costs
- the wrong places
- the right places
Check answers and explanations
- Blank 1
- strategic translation
- Blank 2
- shadow spreadsheets
- Blank 3
- local codes
- Blank 4
- a free-text field
- Blank 5
- a floor, not a ceiling
- Blank 6
- the right places
Gap 1: Residents' adaptation was described as strategic translation because they learned which wording influenced the system's response. Gap 2: Teams kept shadow spreadsheets to preserve context ignored by the official system. Gap 3: Other teams used local codes in parallel with the central categories. Gap 4: Leadership added a free-text field for unusual cases. Gap 5: Managers began describing the template as a floor, not a ceiling, allowing variation above a basic structure. Gap 6: The conclusion implies that flexibility should be available in the right places, because the platform was flexible only in the wrong places.
It was a kind of strategic translation, the civic equivalent of speaking in code to a machine that understood only the language of its own boxes
Teams kept shadow spreadsheets to record the context that the official system ignored
The council did not abandon the system; it taught itself how to use it without mistaking uniformity for understanding
local codes: These are used by teams to preserve nuance, not the complaint-writing itself.
shadow spreadsheets: These are a later workaround used by staff, not the general way citizens wrote complaints.
cleaner picture: This describes the dashboard's early appearance, not the citizens' behaviour.
single digital form: This was the original platform design, not the later private record-keeping.
the nearest category: That phrase belongs to staff forcing cases into the system, not to their workaround records.
free-text field: This is a later feature added by leadership, not the workaround kept by teams.
hidden costs: Those are consequences of the system, not the local parallel used to preserve nuance.
cleaner picture: This describes the dashboard, not the extra coding used by teams.
good on the dashboard but slow in the street: This is the supervisor's judgement about the system, not an alternative code used by teams.
a single digital form: That was the original platform, not the later exception feature.
the nearest category: This is what staff used before the reform, not the new feature added later.
local codes: These were retained by some teams, but the blank refers to the new addition for unusual cases.
a cleaner picture: This refers to the dashboard's early effect, not the leadership's later metaphor.
the wrong places: That phrase describes where flexibility fails, not how the template is now defined.
all problems could be made comparable: This was the original promise of standardisation, not the later revision of its role.
its own boxes: This phrase is about the machine's limits, not the final judgement about flexibility.
hidden costs: These are one result of the system, not the places where flexibility should be available.
the wrong places: The source criticises flexibility for being available in the wrong places; this sentence asks where it should be provided.
What to review next
Find the words that support each answer. For a mistake, compare the question with the evidence and identify the detail or inference you missed.
A focused practice result shows how you did on these tasks. Use several activities across skills to decide what to study next; one practice score does not certify an overall CEFR level.
Before you practise: a worked example
Look for evidence in the text. Separate what the writer says from what you already know about the topic.
The library normally closes at six, but on Fridays it stays open until eight. When does it close on Friday?
The answer is eight. But introduces an exception to the normal closing time, so the first time mentioned is not the answer.
This teaching example is separate from the scored questions. After your test, compare any mistakes with the explanation and revisit the topic before trying again.