File attachment rate

File attachment rate is the percentage of items that include at least one attached file. An item can be a support ticket, a chat message, a deal record, an expense claim, or any object in a product where attaching a document is possible. If 1,000 support tickets are raised in a week and 350 of them include a screenshot or log file, the file attachment rate is 35 percent.

The metric matters because attachments usually carry context that plain text cannot. A bug report with a screenshot resolves faster than one without. An expense claim with a receipt clears compliance without a follow-up. A sales record with a signed document is further along than one with a note promising to send it later. Attachment rate is a proxy for how much supporting evidence is flowing through a process.

The metric reads in two directions depending on the context. In support, a higher attachment rate can mean faster resolution because agents have what they need up front, which often shows up as a lower average resolution time. In a process where attachments are mandatory, such as receipt capture, a rate below 100 percent is a compliance gap to close. Knowing which direction is good for your context is the first step to using it well.

The calculation divides the number of items that include at least one attachment by the total number of items, then multiplies by 100 to express it as a percentage. The judgement lies in defining the numerator, the denominator, and the period consistently.

1. 1

   Items with at least one attachment

   Count each item once if it has one or more files attached, regardless of how many. Decide whether an attachment added later in the lifecycle still counts, and apply that rule consistently.

2. 2

   Total items

   Count every item created in the period that could have had an attachment. Exclude item types where attaching a file is impossible, or the denominator will understate the true rate.

3. 3

   Measurement period

   Fix a window such as a day, week, or month. Use the item creation date consistently so the rate is comparable across periods and not skewed by attachments added much later.

4. 4

   Segment dimension

   Decide how you will slice the rate, for example by channel, team, or item type. The headline rate is far less useful than the same rate broken down by where the work originates.

A worked example keeps the definition honest. If a team handles 2,000 items in a month and 900 of them carry a file, the file attachment rate is (900 / 2,000) x 100, which is 45 percent. If half of those items are a type where attachments are not possible, you should remove them from the denominator first, which would lift the rate to 90 percent and give a truer picture of behaviour where attaching is actually an option.

A metric tree decomposes attachment rate into the factors that decide whether a file gets attached, and traces each back to something you can change. A single percentage tells you the level. The tree tells you why it is where it is.

The first level splits the rate into intent, ability, and friction. Intent covers whether people have a file to attach and a reason to. Ability covers whether the channel and device they are using even support attachments. Friction covers how hard the upload flow makes it once they decide to attach. Each branch decomposes further, into things like channel mix, file size limits, supported formats, and how prominent the attach control is.

This structure separates causes that look identical in the headline number. A low rate caused by people lacking a file to share needs a prompt or a template. A low rate caused by a clunky upload flow needs an interface fix. The tree keeps you from prescribing the wrong remedy.

Benchmarks for file attachment rate vary widely by context, because the right rate depends entirely on whether attachments are optional or expected. The table below frames typical ranges by use case rather than offering a single target, since a good rate for casual messaging would be a failure for receipt capture.

The most useful comparison is against your own past rate and against your peer teams, not against an industry figure. A support team whose attachment rate falls from 40 percent to 25 percent over a month has a problem worth investigating, whether the cause is a broken upload flow, a change in ticket mix, or a new channel that does not support files. Pair the rate with a downstream outcome such as resolution time to confirm whether attachments are actually helping rather than just accumulating.

Improving attachment rate is about removing friction and adding the right nudge, not nagging people to upload. Where a higher rate is genuinely better, start with the branch of the tree that is costing you the most attachments.

The metric tree approach starts by segmenting the rate by channel, team, and item type to find where attachments are leaking, then measuring intent, ability, and friction for that segment. If the gap is friction, a flow fix moves the number. If it is channel ability, the fix is structural rather than behavioural.

KPI Tree lets you connect each branch to the team that owns it. The teams behind the product own the upload flow and the attach control, support operations own the prompts and templates, and the channel owners own where work arrives. Each metric carries RACI ownership, so when attachment rate drops the accountable owner is notified rather than the dip sitting unnoticed on a dashboard. The verified impact loop then checks whether a change, such as raising the file size limit, actually lifted the rate it was meant to, closing the gap between the fix and its effect.

1. 1

   Leaving non-attachable items in the denominator

   Counting item types that cannot carry a file drags the rate down for reasons that have nothing to do with behaviour. Remove them from the denominator so the rate reflects items where attaching is actually possible.

2. 2

   Confusing attachment rate with attachment volume

   An item with ten files counts the same as one with a single file. If the number of files matters, track attachments per item separately rather than reading volume into this metric.

3. 3

   Assuming a low rate is a user problem

   A falling rate is often a broken upload flow, a low size limit, or a new channel without attachment support. Check the friction and ability branches before concluding people simply stopped attaching.

4. 4

   Reading the rate without direction

   Higher is not always better. In mandatory capture, a high rate is the goal, but in casual messaging an unusually high rate could signal spam. Decide which direction is healthy for your context before acting.

5. 5

   Ignoring the downstream outcome

   A rising attachment rate is only good if the attachments help. Pair the rate with a downstream metric such as resolution time so you measure value rather than just activity.