The Friction Tax, Part 3: Technology That Gives Capacity Back
- by Buoyancy Works
- |
- - 9 min read
In This Article:
Better Technology Should Remove Work, Not Move It to Another Screen
Community organizations are often told that technology will make their work more efficient.
Yet many teams already use a large collection of digital tools.
They have client databases, spreadsheets, online forms, shared drives, calendars, email, survey platforms, reporting tools, funder portals, and messaging systems.
Staff may still spend hours copying information, reconciling records, chasing missing fields, reviewing separate task lists, and reconstructing service activity for reports.
The work is digital.
The burden remains.
This is the central technology problem facing many community organizations. The issue is not simply that they need more software. It is that their existing tools often do not reflect how the work moves from first contact through service, follow-up, measurement, and reporting.
When systems are fragmented, staff become the integration layer.
They carry information between tools. They remember what is due. They preserve context across visits. They decide which activity belongs to which program. They reconnect surveys, referrals, actions, and outcomes after the fact.
Technology gives capacity back only when it reduces that work.
Otherwise, it simply changes the form of the friction tax.
Digital Tools Can Become Sludge Too
Replacing paper with a screen does not necessarily improve a process.
A digital form can still be too long.
A client database can still require duplicate entry.
An automated reminder can still arrive at the wrong time.
A reporting dashboard can still be based on incomplete or badly structured information.
A new platform can add another login without replacing an existing system.
Digital systems often make inefficient work faster without questioning whether the work should exist.
This is digital sludge: technology that preserves or adds avoidable friction through poor fit, fragmentation, duplication, excessive steps, or unclear workflows.
The risk is especially high when organizations buy tools designed for a different operating model.
A traditional case-management system may assume:
- one client;
- one assigned caseworker;
- one formal case plan;
- scheduled appointments;
- sequential services;
- and a clear opening and closing of the case.
That model fits some programs well.
It fits less well when support is:
- episodic;
- team-based;
- walk-in;
- multi-channel;
- short-term;
- crisis-responsive;
- or organized around discrete acts of advocacy rather than a continuous formal case.
When the technology assumes a structure the service does not have, staff must bend either the work or the data to fit the system.
They create generic cases, use notes to hold structured information, maintain parallel spreadsheets, or invent local workarounds.
The technology remains technically operational.
The organization pays for the mismatch in staff effort.
The Work Needs an Operating Layer
Community support is rarely one clean transaction.
A person may arrive through a walk-in, telephone call, referral, voicemail, online form, appointment, or conversation with another agency.
The first need may lead to several actions:
- replacing identification;
- checking benefit eligibility;
- completing an application;
- making a referral;
- booking a callback;
- gathering a document;
- assigning a survey;
- or scheduling another interaction.
The work may be completed by several staff members over time.
A useful platform therefore needs to reflect the actual units of work.
Depending on the organization, these may include:
- clients and households;
- interactions;
- actions;
- appointments;
- callbacks;
- forms;
- applications;
- referrals;
- programs;
- surveys;
- outputs;
- outcomes;
- and follow-up.
This is the idea behind a different way to think about case-management technology.
We don’t mean less care, weaker accountability, or the abandonment of case management where it is appropriate.
It means not forcing every form of community support into a traditional case file.
Some people need intensive, continuous case management.
Others need timely navigation, several coordinated actions, a warm referral, a short period of follow-up, or the ability to return without restarting the entire process.
The technology should support both depth and flexibility.
The aim is to create a light operating layer that helps teams answer practical questions:
- What does this person need today?
- What has already been done?
- What happens next?
- Who owns the follow-up?
- Which program or funder does the work relate to?
- Is anything overdue or incomplete?
- What should the next staff member know?
- What evidence is being created as the work happens?
When the operating layer matches the service model, staff do not need to reconstruct the work later.
Capture Information Once, Use It More Than Once
A basic principle of low-friction system design is:
Information should be captured once, as close as possible to where it is created, and reused wherever it has a legitimate purpose.
In practice, that means a client’s household information should not need to be re-entered for every form.
An interaction should be able to generate:
- a service history;
- program participation;
- follow-up work;
- relevant outputs;
- and reporting evidence.
A submitted form should remain connected to the client, interaction, program, and reporting period it belongs to.
A referral should not disappear into a note. It should remain visible until it is completed, declined, redirected, or no longer required.
A survey should not be an isolated link. The system should know why it was assigned, when it is due, whether it has been completed, and how it connects to the service journey.
This does not require that every tool become one enormous database.
Some organizations will continue to use specialist platforms, funder systems, financial tools, or government portals that cannot be replaced.
The design question is whether staff must manually rebuild the connections among them.
Integration can take several forms:
- direct system connections;
- shared identifiers;
- structured exports;
- prefilled forms;
- reusable data;
- linked records;
- or workflows that clearly define where each item belongs.
The goal is not technological purity.
It is fewer points at which a person must copy, remember, reconcile, or repair information.
Measurement Should Be Embedded in Service Delivery
Measurement becomes sludge when it sits outside the workflow.
If outcomes, surveys, funder indicators, and program requirements live in separate systems, staff must remember:
- what is due;
- when to collect it;
- which instrument applies;
- where to record it;
- and how to connect it to the right person and program later.
That is a heavy reliance on human memory.
It also makes measurement feel like an extra task imposed after the service has already happened.
A better model embeds measurement into the journey.
The system should help staff see:
- which baseline measures are required;
- which follow-up surveys are due;
- which outputs have been confirmed;
- which fields are missing;
- which indicators relate to each program;
- and which reporting obligations are being met through ordinary service activity.
Measurement then becomes part of the workflow rather than a second job.
This does not mean collecting more data.
In many organizations, the better intervention is to collect less.
Every field, survey, and indicator should have a clear use:
- direct service;
- continuity;
- supervision;
- learning;
- reporting;
- compliance;
- or evaluation.
When nobody can explain how a field is used, that is a signal to review it.
Integrated measurement should make the organization more curious and more capable, not merely more compliant.
Reporting Should Not Require Organizational Archaeology
Too many organizations do the work first and reconstruct the evidence later.
At reporting time, staff search through notes, spreadsheets, forms, survey exports, email threads, and local trackers to answer basic questions:
- How many people received the service?
- What did staff actually do?
- Which programs were involved?
- What was completed?
- What changed?
- Which records are missing?
- Can the numbers be defended?
This is organizational archaeology: rebuilding the story of service delivery from scattered traces.
Well-designed technology should connect the work to reporting from the beginning.
Programs should connect to funders.
Interactions should connect to actions.
Actions should connect to services, applications, referrals, and outputs.
Forms should connect to the interaction and program that produced them.
Measurements should connect to the appropriate point in the journey.
Reporting periods should organize existing evidence rather than trigger a manual search for it.
The anchor principle is:
Reporting should be a byproduct of well-structured service delivery, not a seasonal act of organizational archaeology.
That does not mean every report can be generated with one click.
Funders may use different definitions. Narratives require interpretation. Outcomes often need explanation. Data must still be reviewed.
But the organization should begin the reporting process with structured, traceable evidence rather than a collection of disconnected files.
Real-Time Visibility Changes What Managers Can Do
Reporting is usually backward-looking.
Operational visibility is present-looking.
A manager does not only need to know how many clients were served last quarter. They also need to know:
- where demand is increasing;
- which follow-ups are overdue;
- which programs are experiencing pressure;
- whether forms are incomplete;
- where callbacks are accumulating;
- which surveys are due;
- and whether staff are relying on workarounds.
When information becomes visible only after manual reporting, leaders manage through anecdotes, periodic snapshots, and staff escalation.
When the operating system reflects work as it happens, managers can respond earlier.
They can:
- redistribute workload;
- adjust staffing;
- identify training needs;
- fix confusing categories;
- follow up on stalled processes;
- and distinguish isolated errors from recurring system problems.
Real-time visibility is not valuable because dashboards are attractive.
It is valuable because earlier information creates more options for action.
AI Should Reduce Burden, Not Create Noise
Artificial intelligence belongs in this discussion, but it should not be the starting point.
AI cannot fix a workflow that has not been defined.
It cannot reliably reconcile data whose meaning is unclear.
It should not make decisions that require human judgment, relational knowledge, or accountability.
Its most credible role is as a support layer within a well-structured system.
AI can help staff:
- summarize a long service history;
- prepare for an interaction;
- convert a conversation into a draft note;
- identify possible missing information;
- surface overdue follow-up;
- translate institutional language into plainer language;
- organize unstructured notes;
- detect recurring demand patterns;
- and prepare information for human review.
The standard should be practical:
AI should help staff see, remember, review, and act.
It should not create another stream of alerts, another place to check, or another output that requires extensive correction.
AI-supported documentation also requires clear safeguards:
- staff must be able to review and correct outputs;
- generated content should remain traceable;
- the system should distinguish facts from suggestions;
- sensitive data must be handled appropriately;
- and accountability must remain with the organization and practitioner.
The right question is not, “Where can we add AI?”
It is:
Which recurring cognitive or administrative task can be reduced without weakening judgment, privacy, accuracy, or client trust?
Technology Should Strengthen Human Continuity
Community support is relational work.
The purpose of technology is not to automate away the relationship.
It is to protect the conditions that make the relationship effective.
A useful system can preserve continuity when:
- a client returns after several months;
- a different staff member responds;
- an advocate is away;
- a referral stalls;
- a document remains outstanding;
- or a reporting requirement changes.
It can reduce the need for clients to repeat information.
It can help staff prepare rather than search.
It can make follow-up less dependent on memory.
It can free supervision from basic record reconstruction.
The strongest technology does not draw attention to itself.
It makes the work easier to continue.
A Practical Capacity-Back Test
Before adopting, renewing, or expanding a digital tool, organizations can apply a simple test.
Choose one real workflow and walk through it from beginning to end.
Then ask:
1. What work does the tool remove?
Be specific.
Does it eliminate duplicate entry, manual reminders, spreadsheet consolidation, repeated searches, or report reconstruction?
If the tool makes one task faster but adds another step elsewhere, the net gain may be small.
2. What work does it create?
Count:
- new fields;
- new logins;
- new training;
- new exports;
- new review tasks;
- new integrations;
- and new maintenance responsibilities.
Digital work is still work.
3. Does it match the service model?
Can it support walk-ins, team-based support, short interactions, repeat visits, households, referrals, follow-up, and multiple programs?
Or must staff distort the work to fit the system?
4. Can information be reused?
Can data captured during service support follow-up, measurement, supervision, and reporting?
Or will staff need to enter or translate it again?
5. What becomes visible sooner?
Will staff and managers be able to see overdue actions, missing data, demand patterns, or stalled referrals while they can still respond?
6. What happens when the workflow breaks?
Can staff recover from a missed appointment, incorrect entry, incomplete form, or interrupted process without rebuilding the record?
7. Does it give time back to the frontline?
Estimate the expected reduction in:
- duplicate entry;
- search time;
- reconciliation;
- follow-up tracking;
- and reporting preparation.
Then verify those estimates after implementation.
The most important measure of a new platform is not how many features it contains.
It is how much avoidable work no longer needs to be done.
Giving Capacity Back
Community organizations are routinely asked to absorb the complexity of the systems around them.
Technology cannot remove every external barrier. It cannot simplify every government process, align every funder requirement, or resolve every gap among institutions.
But it can stop requiring organizations to absorb that complexity manually.
The goal is not simply to store more information.
The goal is to give capacity back:
- fewer repeated entries;
- cleaner and more useful data;
- more reliable follow-up;
- stronger continuity;
- earlier visibility;
- integrated measurement;
- and reporting that reflects the work as it happens.
That is the promise of anti-case-management technology.
Not less care.
Not less accountability.
Less sludge between the work organizations do and the evidence they need to understand, improve, and sustain it.
About Buoyancy Works
Buoyancy Works develops accessible technology for community organizations delivering stabilization, navigation, advocacy, and coaching. Our work focuses on reducing administrative friction, preserving service continuity, and making frontline work easier to coordinate, understand, and sustain.
Learn more at https://buoyancy.works
Acknowledgement
This article was developed using AI-assisted research and drafting. The Buoyancy Works team reviewed the evidence, analysis, and final editorial decisions.
References
Bhargava, S., & Manoli, D. (2015). Psychological frictions and the incomplete take-up of social benefits: Evidence from an IRS field experiment. American Economic Review, 105(11), 3489–3529.
https://doi.org/10.1257/aer.20121493
Finkelstein, A., & Notowidigdo, M. J. (2019). Take-up and targeting: Experimental evidence from SNAP. The Quarterly Journal of Economics, 134(3), 1505–1556.
https://doi.org/10.1093/qje/qjz013
Herd, P., & Moynihan, D. P. (2018). Administrative burden: Policymaking by other means. Russell Sage Foundation.
https://www.russellsage.org/publications/book/administrative-burden
Moynihan, D. P., Herd, P., & Harvey, H. (2015). Administrative burden: Learning, psychological, and compliance costs in citizen-state interactions. Journal of Public Administration Research and Theory, 25(1), 43–69.
https://doi.org/10.1093/jopart/muu009
Office of the Auditor General of Canada. (2022). Access to benefits for hard-to-reach populations. Reports of the Auditor General of Canada to the Parliament of Canada.
https://www.oag-bvg.gc.ca/internet/English/parl_oag_202205_01_e_44033.html
Standing Committee on Public Accounts. (2023). Access to benefits for hard-to-reach populations. House of Commons of Canada.
https://www.ourcommons.ca/DocumentViewer/en/44-1/PACP/report-23/
Sunstein, C. R. (2021). Sludge: What stops us from getting things done and what to do about it. MIT Press.
Recommended for you
