Treat the file as part of the message: identifiable before opening, readable after downloading, and connected to the requested action.
Design the file for a phone
A 50-page PDF designed for print may be a poor campaign attachment. Keep what the recipient needs and compress images without making text blurry.
Test on a real phone. Wide tables, tiny type, and small links create friction even when the file opens correctly.
Preserve the real name and type
Use a descriptive file name such as “july-workshop-program.pdf,” not “final_v8.pdf.” Remove local path fragments and unusual characters.
Send the MIME type that matches the actual content. Do not rely only on an extension entered by a user.
- Short descriptive file name.
- Extension matches content.
- MIME type detected or validated.
- File size known before sending.
- Resource available to the sending service.
Upload content, not a local path
A messaging service cannot read a path that exists only on a web server or user device. Transfer the file using the method required by the integration.
Confirm the upload before launching the campaign. Keep a stable file reference and block launch when the resource is missing or expired.
Write a self-contained caption
Explain what the document contains and why the person should open it. The caption should still make sense when the file is downloaded later.
Put the next action after that description. Do not hide an important deadline only inside the document.
Test the complete download
A successful preview does not prove the file is intact. Download it from the test message, open it, and compare its size or checksum with the original.
Review failure handling too. A campaign report should identify recipients without a delivered document so the team can investigate without resending to everyone.
