Unslop APIv1.3.0

What will an edit cost?

Add credit from $4. A dollar buys a dollar of credit. There’s no subscription or automatic top-up.

Paste your text below for an estimate, or compare real edits.

Try a draft

The estimate runs in your browser. Nothing is sent for editing yet.

Medium suits everyday writing. Higher levels offer more capable AI and cost more.

Loading current prices…

Edit this text

Open the editor to work on your draft.

Estimated cost, not a fixed price. The work needed and your chosen level affect the charge. Any tax is added at checkout.

What's included in the estimate?

An edit of the complete draft. Clear passages can stay as they are; awkward or inflated wording can change throughout. The range allows for a correction attempt if a revision does not pass validation.

The examples are original demo drafts of about 500 words. For files, paste the text you want to edit. Each text can contain up to 20,000 characters; split longer documents into sections. These are planning estimates, not measured averages or guaranteed limits.

Compare the edits

Choose a draft and an editing level. Each price is what that recorded edit would cost.

Customer support pilot

Low cleaned up this draft for about 2.3¢. The other levels produced similar results at higher prices.

Read the original draft · 485 words
A pivotal new chapter in customer support In today's rapidly evolving digital landscape, delivering seamless customer experiences is more important than ever. We are thrilled to unveil a groundbreaking initiative that will empower our customers to unlock the full potential of self-service. This isn't just a portal. It's a paradigm shift. At its core, this transformative journey is about fostering meaningful connections, streamlining workflows, and elevating every interaction. Together, we are reimagining what's possible, one click at a time. Let's dive in. On October 12, we will invite 24 existing customers to try a new support portal for two weeks. The pilot lets them download invoices and check the status of support requests. It does not support refunds, password changes, or adding teammates. Those tasks will stay on the current account page. Participation is optional, and customers can leave the pilot at any time. The wider release has no confirmed date. These details aren't just logistics. They're the foundation of a truly customer-centric ecosystem designed to meet people where they are. Why this matters: in a world where expectations never stop rising, clarity is the cornerstone of trust. The portal could reduce routine questions, but we do not yet know whether it will save customers time. We will measure task completion, time spent finding an invoice, and requests for help. A lower ticket count alone will not count as success. People may stop asking because they cannot find the contact button. That would be a problem, not evidence of improvement. It's worth noting that the goal is not to eliminate human support. It's to cultivate a frictionless experience that puts people at the heart of everything we do. Furthermore, our dedicated team is working tirelessly to ensure a robust and holistic approach to feedback. Support will read pilot comments each weekday. Engineering will investigate blocked invoice downloads before cosmetic problems. If a customer sees another customer's invoice, we will pause the pilot immediately and investigate. We will also pause if customers cannot reach support. These safeguards reflect our unwavering commitment to excellence, underscoring the critical importance of building a resilient foundation for sustainable growth. The future of support isn't on the horizon. It's already here. To navigate this exciting new chapter, account managers should send the invitation only to customers on the approved list. Please use the sentence "You can keep using the current support page" exactly as written. Do not promise faster responses or additional features. Send questions about eligibility to the support lead by Friday. We will share the pilot findings after the two-week trial, including problems and inconclusive results. No price changes are planned during the pilot. This is more than an experiment. It's a testament to the power of collaboration, a catalyst for innovation, and a bold step toward a brighter tomorrow. The journey ahead is filled with opportunity, and we cannot wait to embark on it together.
Low$0.0232 · 254 words

Removes the stock metaphors, promotional opening and empty conclusion throughout the draft. The operational details and caveats remain. This was the least expensive result and a strong edit of this sample.

Customer support pilot On October 12, we will invite 24 existing customers to try a new support portal for two weeks. The pilot lets customers download invoices and check the status of support requests. It does not support refunds, password changes, or adding teammates; those tasks will remain on the current account page. Participation is optional, and customers can leave the pilot at any time. The wider release has no confirmed date. The portal could reduce routine questions, but we do not yet know whether it will save customers time. We will measure task completion, time spent finding an invoice, and requests for help. A lower ticket count alone will not count as success. Customers may stop asking for help because they cannot find the contact button. That would be a problem, not evidence of improvement. The goal is not to eliminate human support. Support will read pilot comments each weekday. Engineering will investigate blocked invoice downloads before cosmetic problems. If a customer sees another customer's invoice, we will pause the pilot immediately and investigate. We will also pause if customers cannot reach support. Account managers should send the invitation only to customers on the approved list. Please use the sentence "You can keep using the current support page" exactly as written. Do not promise faster responses or additional features. Send questions about eligibility to the support lead by Friday. We will share the pilot findings after the two-week trial, including problems and inconclusive results. No price changes are planned during the pilot.
Medium$0.1001 · 254 words

Removes the filler throughout and keeps the factual paragraphs close to their original wording. The output is very similar to Low. Its longer review made this particular run cost more than High.

A new customer support pilot On October 12, we will invite 24 existing customers to try a new support portal for two weeks. The pilot lets them download invoices and check the status of support requests. It does not support refunds, password changes, or adding teammates. Those tasks will stay on the current account page. Participation is optional, and customers can leave the pilot at any time. The wider release has no confirmed date. The portal could reduce routine questions, but we do not yet know whether it will save customers time. We will measure task completion, time spent finding an invoice, and requests for help. A lower ticket count alone will not count as success. People may stop asking because they cannot find the contact button. That would be a problem, not evidence of improvement. The goal is not to eliminate human support. Support will read pilot comments each weekday. Engineering will investigate blocked invoice downloads before cosmetic problems. If a customer sees another customer's invoice, we will pause the pilot immediately and investigate. We will also pause if customers cannot reach support. Account managers should send the invitation only to customers on the approved list. Please use the sentence "You can keep using the current support page" exactly as written. Do not promise faster responses or additional features. Send questions about eligibility to the support lead by Friday. We will share the pilot findings after the two-week trial, including problems and inconclusive results. No price changes are planned during the pilot.
High$0.0814 · 252 words

Removes the promotional framing and connects the warning about ticket counts to its explanation. All factual details and qualifications remain. A clear edit, with little practical difference from the less expensive Low result.

Support portal pilot On October 12, we will invite 24 existing customers to try a new support portal for two weeks. The pilot lets them download invoices and check the status of support requests. It does not support refunds, password changes, or adding teammates. Those tasks will stay on the current account page. Participation is optional, and customers can leave the pilot at any time. The wider release has no confirmed date. The portal could reduce routine questions, but we do not yet know whether it will save customers time. We will measure task completion, time spent finding an invoice, and requests for help. A lower ticket count alone will not count as success: people may stop asking because they cannot find the contact button. That would be a problem, not evidence of improvement. The goal is not to eliminate human support. Support will read pilot comments each weekday. Engineering will investigate blocked invoice downloads before cosmetic problems. If a customer sees another customer's invoice, we will pause the pilot immediately and investigate. We will also pause if customers cannot reach support. Account managers should send the invitation only to customers on the approved list. Please use the sentence "You can keep using the current support page" exactly as written. Do not promise faster responses or additional features. Send questions about eligibility to the support lead by Friday. We will share the pilot findings after the two-week trial, including problems and inconclusive results. No price changes are planned during the pilot.
Max$0.2867 · 258 words

Removes the promotional framing and uses a specific heading about the two-week pilot. The factual paragraphs remain almost unchanged. It is a strong cleanup, but this sample does not show enough extra value to justify its higher price. The first request failed; this is the single retry.

A two-week pilot for the new support portal On October 12, we will invite 24 existing customers to try a new support portal for two weeks. The pilot lets them download invoices and check the status of support requests. It does not support refunds, password changes, or adding teammates. Those tasks will stay on the current account page. Participation is optional, and customers can leave the pilot at any time. The wider release has no confirmed date. The portal could reduce routine questions, but we do not yet know whether it will save customers time. We will measure task completion, time spent finding an invoice, and requests for help. A lower ticket count alone will not count as success. People may stop asking because they cannot find the contact button. That would be a problem, not evidence of improvement. The goal is not to eliminate human support. Support will read pilot comments each weekday. Engineering will investigate blocked invoice downloads before cosmetic problems. If a customer sees another customer's invoice, we will pause the pilot immediately and investigate. We will also pause if customers cannot reach support. Account managers should send the invitation only to customers on the approved list. Please use the sentence "You can keep using the current support page" exactly as written. Do not promise faster responses or additional features. Send questions about eligibility to the support lead by Friday. We will share the pilot findings after the two-week trial, including problems and inconclusive results. No price changes are planned during the pilot.
How we ran this comparison

Each level edited the complete draft and received a separate meaning review. All four passed on their first completed edit. Max's first request returned a server error; we retried it once. The outputs above are unchanged.

We read each output against the original. The dates, participant count, feature limits, qualifications, stop conditions, pricing promise and required quotation were retained.

Prices use measured usage from these runs and the September 25, 2026 customer rates, before tax. They are what a customer would pay for these results; our test account did not spend prepaid credit. Failed or rejected rewrites cost customers nothing. This is one example, not an average or a ranking of the levels.

The previous workflow made only three or four small changes. Full-draft editing produced substantially cleaner text on this sample, and Low, High and Max cost less than their previous runs. Medium's previous edit was rejected and cost nothing.

Recorded requests and responses · Previous phrase-editing results

Team update email

Read the original draft · 499 words
Hi everyone, As we head into the final month of the quarter, I wanted to take a moment to reflect on the progress we have made together. The customer portal project has brought several moving pieces into one place, and the next few weeks will be pivotal in turning that work into a reliable experience for customers. This isn't just a software launch. It's an opportunity to rethink how we support people after they sign up. The first version of the portal will let customers update their contact details, download invoices, and check the status of support requests. We are keeping the initial release focused. Password changes, team permissions, and subscription changes will continue through the existing account page until the second release. Please avoid promising those features during customer conversations, even if a customer has seen an early design that includes them. Testing starts on Monday with twelve customers who volunteered during the spring interviews. Each participant will receive a short set of tasks and a link to a feedback form. We will also offer two optional video sessions for people who prefer to talk through their experience. The research team will summarize the results each afternoon so engineering can distinguish problems that block a task from smaller issues we can address later. Why this matters: a seamless experience can reduce unnecessary support tickets and empower customers to find answers on their own. However, we should not assume that fewer tickets automatically means people are happier. We will look at task completion, abandoned sessions, and the comments customers leave alongside the ticket count. If customers stop asking because they cannot find the contact button, that is a failure, not an improvement. There are three decisions we need to make this week. First, finance needs to confirm which invoice fields can be edited after an invoice has been issued. Second, support needs to choose an owner for messages submitted outside normal business hours. Finally, product needs to approve the wording for requests that are waiting on a customer response. Please add your answers to the project document by Thursday afternoon, with a link to any relevant policy. For launch week, we will keep the old help page available and add a clear route back to it from the portal. Nobody should have to learn a new system to resolve an urgent billing problem. The support team will have a shared list of known issues, and engineering will nominate one person each day to handle reports that need immediate attention. We will postpone the wider release if the pilot reveals problems with invoices or account access. Thank you for the care you have put into the details so far. Small things like a clear error message or a sensible default can make a meaningful difference. Together, we can build a more intuitive and customer-centric experience while keeping the launch manageable. I will send the pilot schedule on Friday once we have the final participant list. Best, The portal team
Low$0.0343 · 450 words

Replaces the inflated opening and removes the “Why this matters” framing. Keeps the feature limits, testing plan and deadlines. Some familiar phrasing, such as “moving pieces,” remains.

Hi everyone, As we enter the final month of the quarter, here’s an update on the customer portal project. The portal brings several moving pieces together, and the next few weeks will be important to making it reliable for customers. The project also gives us a chance to rethink how we support people after they sign up. The first version of the portal will let customers update their contact details, download invoices, and check the status of support requests. We are keeping the initial release focused. Password changes, team permissions, and subscription changes will remain on the existing account page until the second release. Please avoid promising those features in customer conversations, even if a customer has seen an early design that includes them. Testing starts on Monday with twelve customers who volunteered during the spring interviews. Each participant will receive a short set of tasks and a link to a feedback form. We will also offer two optional video sessions for people who prefer to talk through their experience. The research team will summarize the results each afternoon so engineering can distinguish problems that block a task from smaller issues we can address later. We hope the portal will reduce unnecessary support tickets and help customers find answers on their own. But fewer tickets do not necessarily mean customers are happier. We will review task completion, abandoned sessions, and customer comments alongside ticket counts. If customers stop asking for help because they cannot find the contact button, that is a failure, not an improvement. We need to make three decisions this week. First, finance needs to confirm which invoice fields can be edited after an invoice has been issued. Second, support needs to choose an owner for messages submitted outside normal business hours. Finally, product needs to approve the wording for requests that are waiting on a customer response. Please add your answers to the project document by Thursday afternoon, with a link to any relevant policy. During launch week, we will keep the old help page available and add a clear route back to it from the portal. Customers should not have to learn a new system to resolve an urgent billing problem. The support team will have a shared list of known issues, and engineering will nominate one person each day to handle reports that need immediate attention. We will postpone the wider release if the pilot reveals problems with invoices or account access. Thank you for the work you have put into the details so far. Clear error messages and sensible defaults can make a meaningful difference. I will send the pilot schedule on Friday once we have the final participant list. Best, The portal team
Medium$0.2179 · 451 words

Needed one correction attempt. It removes some filler but keeps “pivotal” and “more than a software launch.” The facts remain, but this is a less thorough cleanup than Low or High on this draft.

Hi everyone, As we head into the final month of the quarter, the customer portal project has brought several moving pieces into one place. The next few weeks will be pivotal in turning that work into a reliable experience for customers. This is more than a software launch: it is an opportunity to rethink how we support people after they sign up. The first version of the portal will let customers update their contact details, download invoices, and check the status of support requests. We are keeping the initial release focused. Password changes, team permissions, and subscription changes will continue through the existing account page until the second release. Please avoid promising those features in customer conversations, even if a customer has seen an early design that includes them. Testing starts Monday with twelve customers who volunteered during the spring interviews. Each participant will receive a short set of tasks and a link to a feedback form. We will also offer two optional video sessions for people who prefer to talk through their experience. The research team will summarize the results each afternoon so engineering can distinguish problems that block a task from smaller issues we can address later. The portal can reduce unnecessary support tickets and help customers find answers on their own. However, we should not assume that fewer tickets automatically mean people are happier. We will look at task completion, abandoned sessions, and customer comments alongside ticket counts. If customers stop asking because they cannot find the contact button, that is a failure, not an improvement. We need to make three decisions this week. First, finance needs to confirm which invoice fields can be edited after an invoice has been issued. Second, support needs to choose an owner for messages submitted outside normal business hours. Finally, product needs to approve the wording for requests that are waiting on a customer response. Please add your answers to the project document by Thursday afternoon, with links to any relevant policy. For launch week, we will keep the old help page available and add a clear route back to it from the portal. Nobody should have to learn a new system to resolve an urgent billing problem. The support team will have a shared list of known issues, and engineering will nominate one person each day to handle reports that need immediate attention. We will postpone the wider release if the pilot reveals problems with invoices or account access. Thank you for the care you have put into the details so far. Clear error messages and sensible defaults can make a meaningful difference. I will send the pilot schedule Friday once we have the final participant list. Best, The portal team
High$0.1104 · 426 words

Tightens the opening and turns the three decisions into direct requests. Retains the testing details, deadlines and condition for postponing release.

Hi everyone, As we head into the final month of the quarter, we’re preparing the first version of the customer portal. The next few weeks are a chance to make it reliable and rethink how we support customers after they sign up. The first version will let customers update their contact details, download invoices, and check the status of support requests. We are keeping the initial release focused. Password changes, team permissions, and subscription changes will continue through the existing account page until the second release. Please avoid promising those features during customer conversations, even if a customer has seen an early design that includes them. Testing starts on Monday with twelve customers who volunteered during the spring interviews. Each participant will receive a short set of tasks and a link to a feedback form. We will also offer two optional video sessions for people who prefer to talk through their experience. The research team will summarize the results each afternoon so engineering can distinguish problems that block a task from smaller issues we can address later. The portal may reduce unnecessary support tickets and help customers find answers on their own. But fewer tickets won’t necessarily mean people are happier. We will look at task completion, abandoned sessions, and customer comments alongside the ticket count. If customers stop asking because they cannot find the contact button, that is a failure, not an improvement. We need to make three decisions this week. Finance needs to confirm which invoice fields can be edited after an invoice has been issued. Support needs to choose an owner for messages submitted outside normal business hours. Product needs to approve the wording for requests that are waiting on a customer response. Please add your answers to the project document by Thursday afternoon, with a link to any relevant policy. For launch week, we will keep the old help page available and add a clear route back to it from the portal. Nobody should have to learn a new system to resolve an urgent billing problem. The support team will have a shared list of known issues, and engineering will nominate one person each day to handle reports that need immediate attention. We will postpone the wider release if the pilot reveals problems with invoices or account access. Thank you for the care you have put into the details so far. A clear error message or a sensible default can make a difference. I will send the pilot schedule on Friday once we have the final participant list. Best, The portal team
Max$0.3600 · 443 words

Reworks the opening and cuts the promotional closing while keeping the operational paragraphs close to the source. Clearer than the original, with little extra benefit over High here.

Hi everyone, As we head into the final month of the quarter, the customer portal project has brought several parts of our support service into one place. Over the next few weeks, we will focus on making the portal reliable for customers and improving how we support them after they sign up. The first version of the portal will let customers update their contact details, download invoices, and check the status of support requests. We are keeping the initial release focused. Password changes, team permissions, and subscription changes will continue through the existing account page until the second release. Please avoid promising those features during customer conversations, even if a customer has seen an early design that includes them. Testing starts on Monday with twelve customers who volunteered during the spring interviews. Each participant will receive a short set of tasks and a link to a feedback form. We will also offer two optional video sessions for people who prefer to talk through their experience. The research team will summarize the results each afternoon so engineering can distinguish problems that block a task from smaller issues we can address later. An easy-to-use portal can reduce unnecessary support tickets and help customers find answers on their own. But we should not assume that fewer tickets automatically means people are happier. We will look at task completion, abandoned sessions, and the comments customers leave alongside the ticket count. If customers stop asking because they cannot find the contact button, that is a failure, not an improvement. We need to make three decisions this week. Finance needs to confirm which invoice fields can be edited after an invoice has been issued. Support needs to choose an owner for messages submitted outside normal business hours. Product needs to approve the wording for requests that are waiting on a customer response. Please add your answers to the project document by Thursday afternoon, with a link to any relevant policy. For launch week, we will keep the old help page available and add a clear route back to it from the portal. Nobody should have to learn a new system to resolve an urgent billing problem. The support team will have a shared list of known issues, and engineering will nominate one person each day to handle reports that need immediate attention. We will postpone the wider release if the pilot reveals problems with invoices or account access. Thank you for the care you have put into the details so far, from clear error messages to sensible defaults. I will send the pilot schedule on Friday once we have the final participant list. Best, The portal team

Product announcement

Read the original draft · 510 words
A clearer home for your project notes We are excited to introduce a new chapter in the way your team captures ideas, shares context, and moves work forward. Our redesigned project notebook brings notes, decisions, and reference material into a single workspace. It's not just a place to store information. It's a foundation for more connected collaboration, designed to help you turn scattered conversations into shared understanding. The biggest change is the project overview. Instead of opening a long list of documents, you will see a short introduction, the most recent decisions, and the pages your team has marked as useful. You can change the order of those sections or hide one entirely. Existing projects will keep their current documents, permissions, and links. We will not move or rename your files as part of the update. Search now includes the text inside meeting notes and the descriptions attached to uploaded files. Results show a short excerpt so you can check whether a page is relevant before opening it. You can narrow a search to one project, one author, or a date range. The search box will remember those filters while you browse, but you can clear them with a single click whenever you want to look across the whole workspace. We have also added a simple way to mark a decision. Select a paragraph, choose the decision option, and add the name of the person responsible for following up. The original paragraph stays where it was written, while a link appears in the project overview. This helps preserve the surrounding discussion instead of turning every decision into a separate document that nobody remembers to update. Why this matters: knowledge should be an asset that empowers your team, not a maze that slows it down. When someone joins a project halfway through, they need more than the latest task list. They need to understand what the team considered, what it ruled out, and which questions are still open. Keeping that history connected to the work can make those first conversations more productive. The rollout begins with a small group of workspaces next week. Workspace owners will receive a notice before the new overview appears, and they can choose to wait until the following month if the timing is inconvenient. During the first two weeks, a switch in settings will let you return to the previous layout. Please tell us if you cannot find something you use regularly so we can understand what needs attention. Your existing plan includes these changes. There is no additional charge for the overview, improved search, or decision links. Storage limits and guest permissions remain the same. Administrators can read the setup guide for details about shared projects, archived pages, and the settings that control who can edit the overview. We believe great tools should get out of the way while helping people do their best work. This release is a meaningful step in that direction. Open a project, try a search, and let us know which part saves you time and which part still needs work.
Low$0.0447 · 389 words

Cuts the promotional opening and closing, simplifies the instructions, and removes “Why this matters.” Keeps the feature details, rollout choices and no-extra-charge promise.

A clearer home for your project notes The redesigned project notebook brings notes, decisions, and reference material into one workspace, helping your team share context and keep work moving. The main change is the project overview. Instead of opening a long list of documents, you’ll see a short introduction, recent decisions, and pages your team has marked as useful. You can reorder these sections or hide one. Existing projects will keep their documents, permissions, and links. The update will not move or rename files. Search now includes text in meeting notes and descriptions attached to uploaded files. Results include a short excerpt so you can check whether a page is relevant before opening it. You can narrow a search by project, author, or date range. The search box will keep those filters as you browse; clear them with one click to search the whole workspace. To mark a decision, select a paragraph, choose the decision option, and add the name of the person responsible for following up. The paragraph stays where it was written, and a link appears in the project overview. This keeps the surrounding discussion with the decision, rather than moving it to a separate document that may not get updated. When someone joins a project midway through, they need more than the latest task list. They need to know what the team considered, what it ruled out, and which questions remain open. Keeping that history connected to the work can make initial conversations more productive. The rollout begins with a small group of workspaces next week. Workspace owners will receive a notice before the new overview appears. If the timing is inconvenient, they can wait until the following month. During the first two weeks, a switch in settings will let you return to the previous layout. Let us know if you can’t find something you use regularly so we can identify what needs attention. These changes are included in your existing plan. There is no additional charge for the overview, improved search, or decision links. Storage limits and guest permissions will remain the same. Administrators can read the setup guide for details about shared projects, archived pages, and settings that control who can edit the overview. Open a project and try a search. Let us know which parts save you time and which still need work.
Medium$0.0776 · 399 words

Uses a short factual opening and removes the repeated marketing framing. Keeps the practical instructions and rollout conditions close to the source.

A clearer home for your project notes Our redesigned project notebook brings notes, decisions, and reference material into one workspace. The biggest change is the project overview. Instead of a long list of documents, you will see a short introduction, the most recent decisions, and the pages your team has marked as useful. You can reorder those sections or hide one entirely. Existing projects will keep their current documents, permissions, and links. We will not move or rename your files as part of the update. Search now includes text in meeting notes and descriptions attached to uploaded files. Results show a short excerpt so you can check whether a page is relevant before opening it. You can narrow a search to one project, one author, or a date range. The search box will remember those filters while you browse, and you can clear them with one click to search the whole workspace. You can also mark a decision. Select a paragraph, choose the decision option, and add the name of the person responsible for following up. The original paragraph stays where it was written, and a link appears in the project overview. This preserves the surrounding discussion rather than turning each decision into a separate document that may not be updated. When someone joins a project halfway through, they need more than the latest task list. They need to understand what the team considered, what it ruled out, and which questions are still open. Keeping that history connected to the work can make those first conversations more productive. The rollout begins with a small group of workspaces next week. Workspace owners will receive a notice before the new overview appears. They can choose to wait until the following month if the timing is inconvenient. During the first two weeks, a switch in settings will let you return to the previous layout. Please tell us if you cannot find something you use regularly so we can identify what needs attention. Your existing plan includes these changes. There is no additional charge for the overview, improved search, or decision links. Storage limits and guest permissions remain the same. Administrators can read the setup guide for details about shared projects, archived pages, and the settings that control who can edit the overview. Open a project, try a search, and let us know which parts save you time and which still need work.
High$0.1198 · 424 words

Cuts the inflated framing while retaining most of the explanatory detail. A clear edit, although Low achieves a similar cleanup at a lower price.

A clearer home for your project notes Our redesigned project notebook brings notes, decisions, and reference material into a single workspace so your team can find the context behind its work. The biggest change is the project overview. Instead of opening a long list of documents, you will see a short introduction, the most recent decisions, and the pages your team has marked as useful. You can change the order of those sections or hide one entirely. Existing projects will keep their current documents, permissions, and links. We will not move or rename your files as part of the update. Search now includes the text inside meeting notes and the descriptions attached to uploaded files. Results show a short excerpt so you can check whether a page is relevant before opening it. You can narrow a search to one project, one author, or a date range. The search box will remember those filters while you browse, but you can clear them with a single click whenever you want to look across the whole workspace. You can also mark a decision. Select a paragraph, choose the decision option, and add the name of the person responsible for following up. The original paragraph stays where it was written, while a link appears in the project overview. This keeps the surrounding discussion with the decision instead of putting each one in a separate document that nobody remembers to update. When someone joins a project halfway through, they need more than the latest task list. They need to understand what the team considered, what it ruled out, and which questions are still open. Keeping that history connected to the work can make those first conversations more productive. The rollout begins with a small group of workspaces next week. Workspace owners will receive a notice before the new overview appears, and they can choose to wait until the following month if the timing is inconvenient. During the first two weeks, a switch in settings will let you return to the previous layout. Please tell us if you cannot find something you use regularly so we can understand what needs attention. Your existing plan includes these changes. There is no additional charge for the overview, improved search, or decision links. Storage limits and guest permissions remain the same. Administrators can read the setup guide for details about shared projects, archived pages, and the settings that control who can edit the overview. Open a project, try a search, and let us know what saves you time and what still needs work.
Max$0.3392 · 416 words

Makes the decision-marking instructions more direct and removes the promotional framing. The result is close to the other levels on this draft.

A clearer home for your project notes Our redesigned project notebook brings notes, decisions, and reference material into a single workspace to help your team capture ideas and share context. The biggest change is the project overview. Instead of opening a long list of documents, you will see a short introduction, the most recent decisions, and the pages your team has marked as useful. You can change the order of those sections or hide one entirely. Existing projects will keep their current documents, permissions, and links. We will not move or rename your files as part of the update. Search now includes the text inside meeting notes and the descriptions attached to uploaded files. Results show a short excerpt so you can check whether a page is relevant before opening it. You can narrow a search to one project, one author, or a date range. The search box will remember those filters while you browse, but you can clear them with a single click to look across the whole workspace. You can now mark a paragraph as a decision. Select a paragraph, choose the decision option, and add the name of the person responsible for following up. The original paragraph stays where it was written, while a link appears in the project overview. This preserves the surrounding discussion without creating a separate document to keep updated. When someone joins a project halfway through, they need more than the latest task list. They need to understand what the team considered, what it ruled out, and which questions are still open. Keeping that history connected to the work can make those first conversations more productive. The rollout begins with a small group of workspaces next week. Workspace owners will receive a notice before the new overview appears, and they can choose to wait until the following month if the timing is inconvenient. During the first two weeks, a switch in settings will let you return to the previous layout. Please tell us if you cannot find something you use regularly so we can understand what needs attention. Your existing plan includes these changes. There is no additional charge for the overview, improved search, or decision links. Storage limits and guest permissions remain the same. Administrators can read the setup guide for details about shared projects, archived pages, and the settings that control who can edit the overview. Open a project, try a search, and let us know which part saves you time and which part still needs work.

Research proposal

Read the original draft · 520 words
Proposal: understanding the first month of customer use This proposal outlines a focused research project to understand why some new customers stop using the service during their first month. The aim is to identify the moments where expectations and experience diverge, then recommend a small set of improvements that the team can test. By taking a holistic approach to the customer journey, we can uncover actionable insights and create a more seamless onboarding experience. The project will focus on customers who created an account in the last eight weeks. We want to hear from people who became regular users, people who tried the service once, and people who started setting it up but did not finish. Comparing those experiences should help us avoid treating every inactive account as evidence of the same problem. Some customers may have completed a short task and simply have no reason to return yet. We propose twelve interviews, each lasting about forty minutes. Participants will be asked to describe what they hoped to accomplish, show how they approached their first task, and explain any points where they became uncertain. We will ask for specific examples rather than general ratings. A statement such as the interface was confusing is a starting point; the useful detail is what the person expected a particular button to do. Recruitment will happen through an invitation sent to eligible customers who have agreed to receive research messages. Participation will be optional, and declining will not affect their account or support. We will offer the same thank-you payment to every participant, regardless of whether their feedback is positive or negative. The invitation will explain how the interview notes will be used and whether the participant wants to allow recording. This isn't just about collecting feedback. It's about building a deeper understanding of the people behind the metrics. Alongside the interviews, we will review existing support questions and the steps customers complete during setup. These records can help us decide where to ask better questions, but they will not replace the conversations. A drop in activity tells us where something happened, not necessarily why it happened. The work will take four weeks. The first week covers recruitment and preparation. Interviews will run during the second and third weeks, with time between sessions to compare notes and adjust unclear questions. During the final week, we will present the findings and work with product and support to choose the next experiments. We will share observations during the project if a problem needs attention before the final report. The main deliverable will be a short report containing the recurring problems, the evidence behind them, and the limits of what we learned. Recommendations will name a specific change and explain how the team could tell whether it helped. We will also include cases that contradict the main pattern, since those differences may matter when deciding which customers an improvement will serve. Success means leaving the project with a few testable decisions rather than a long collection of interesting quotes. With the right insights, we can foster stronger customer relationships and set the stage for sustainable growth.
Low$0.0337 · 453 words

Removes the promotional framing and keeps the research plan. Two lines become more certain: “The aim is to identify” becomes “We will identify,” and “should help” becomes “will help.” Review those changes before using this version.

Proposal: understanding the first month of customer use This proposal describes a research project to understand why some new customers stop using the service during their first month. We will identify where expectations and experience diverge and recommend a small set of improvements for the team to test. The project will focus on customers who created an account in the last eight weeks. We want to hear from people who became regular users, people who tried the service once, and people who started setting it up but did not finish. Comparing these experiences will help us avoid treating every inactive account as evidence of the same problem. Some customers may have completed a short task and simply have no reason to return yet. We propose twelve interviews, each lasting about forty minutes. Participants will describe what they hoped to accomplish, show how they approached their first task, and explain any points where they became uncertain. We will ask for specific examples rather than general ratings. A statement such as “the interface was confusing” is a starting point; the useful detail is what the person expected a particular button to do. Recruitment will happen through an invitation sent to eligible customers who have agreed to receive research messages. Participation will be optional, and declining will not affect their account or support. We will offer the same thank-you payment to every participant, regardless of whether their feedback is positive or negative. The invitation will explain how the interview notes will be used and ask whether the participant wants to allow recording. Alongside the interviews, we will review existing support questions and the steps customers complete during setup. These records can help us decide where to ask better questions, but they will not replace the conversations. A drop in activity tells us where something happened, not necessarily why. The work will take four weeks. The first week covers recruitment and preparation. Interviews will run during the second and third weeks, with time between sessions to compare notes and adjust unclear questions. During the final week, we will present the findings and work with product and support to choose the next experiments. We will share observations during the project if a problem needs attention before the final report. The main deliverable will be a short report containing recurring problems, the evidence behind them, and the limits of what we learned. Recommendations will name a specific change and explain how the team could tell whether it helped. We will also include cases that contradict the main pattern, since those differences may matter when deciding which customers an improvement will serve. Success means leaving the project with a few testable decisions rather than a long collection of quotes.
Medium$0.0905 · 452 words

Cuts the stock marketing language and keeps the tentative wording about research outcomes. Retains recruitment consent, equal participant payments, the schedule and limits of the findings.

Proposal: understanding the first month of customer use This proposal outlines a research project to understand why some new customers stop using the service during their first month. The aim is to identify where expectations and experience diverge and recommend a small set of improvements for the team to test. The project will focus on customers who created an account in the last eight weeks. We want to hear from people who became regular users, people who tried the service once, and people who started setting it up but did not finish. Comparing these experiences should help us avoid treating every inactive account as evidence of the same problem. Some customers may have completed a short task and have no reason to return yet. We propose twelve interviews, each lasting about forty minutes. Participants will be asked to describe what they hoped to accomplish, show how they approached their first task, and explain where they became uncertain. We will ask for specific examples rather than general ratings. A statement such as the interface was confusing is a starting point; the useful detail is what the person expected a particular button to do. Recruitment will happen through an invitation sent to eligible customers who have agreed to receive research messages. Participation will be optional, and declining will not affect their account or support. We will offer the same thank-you payment to every participant, regardless of whether their feedback is positive or negative. The invitation will explain how interview notes will be used and ask whether the participant allows recording. Alongside the interviews, we will review existing support questions and the steps customers complete during setup. These records can help us decide where to ask better questions, but they will not replace the conversations. A drop in activity tells us where something happened, not necessarily why. The work will take four weeks. The first week covers recruitment and preparation. Interviews will run during the second and third weeks, with time between sessions to compare notes and adjust unclear questions. During the final week, we will present the findings and work with product and support to choose the next experiments. We will share observations during the project if a problem needs attention before the final report. The main deliverable will be a short report containing recurring problems, the evidence behind them, and the limits of what we learned. Recommendations will name a specific change and explain how the team could tell whether it helped. We will also include cases that contradict the main pattern, since those differences may matter when deciding which customers an improvement will serve. Success means leaving the project with a few testable decisions rather than a long collection of quotes.
High$0.1071 · 457 words

Makes a focused cleanup, removing the inflated opening, artificial contrast and promotional ending. Leaves the detailed research plan and its qualifications largely unchanged.

Proposal: understanding the first month of customer use This project will examine why some new customers stop using the service during their first month. The aim is to identify where their expectations and experience diverge, then recommend a small set of improvements the team can test. The project will focus on customers who created an account in the last eight weeks. We want to hear from people who became regular users, people who tried the service once, and people who started setting it up but did not finish. Comparing those experiences should help us avoid treating every inactive account as evidence of the same problem. Some customers may have completed a short task and simply have no reason to return yet. We propose twelve interviews, each lasting about forty minutes. Participants will be asked to describe what they hoped to accomplish, show how they approached their first task, and explain any points where they became uncertain. We will ask for specific examples rather than general ratings. A statement such as the interface was confusing is a starting point; the useful detail is what the person expected a particular button to do. Recruitment will happen through an invitation sent to eligible customers who have agreed to receive research messages. Participation will be optional, and declining will not affect their account or support. We will offer the same thank-you payment to every participant, regardless of whether their feedback is positive or negative. The invitation will explain how the interview notes will be used and whether the participant wants to allow recording. Alongside the interviews, we will review existing support questions and the steps customers complete during setup. These records can help us decide where to ask better questions, but they will not replace the conversations. A drop in activity tells us where something happened, not necessarily why it happened. The work will take four weeks. The first week covers recruitment and preparation. Interviews will run during the second and third weeks, with time between sessions to compare notes and adjust unclear questions. During the final week, we will present the findings and work with product and support to choose the next experiments. We will share observations during the project if a problem needs attention before the final report. The main deliverable will be a short report containing the recurring problems, the evidence behind them, and the limits of what we learned. Recommendations will name a specific change and explain how the team could tell whether it helped. We will also include cases that contradict the main pattern, since those differences may matter when deciding which customers an improvement will serve. Success means leaving the project with a few testable decisions rather than a long collection of interesting quotes.
Max$0.3933 · 458 words

Cuts the filler and makes recruitment and recording consent more direct. Preserves the research caveats. The result is close to High, at a higher price.

Proposal: understanding the first month of customer use We propose a research project to understand why some new customers stop using the service during their first month. The aim is to identify where expectations and experience diverge, then recommend a small set of improvements that the team can test. The project will focus on customers who created an account in the last eight weeks. We want to hear from people who became regular users, people who tried the service once, and people who started setting it up but did not finish. Comparing those experiences should help us avoid treating every inactive account as evidence of the same problem. Some customers may have completed a short task and simply have no reason to return yet. We propose twelve interviews, each lasting about forty minutes. Participants will be asked to describe what they hoped to accomplish, show how they approached their first task, and explain where they became uncertain. We will ask for specific examples rather than general ratings. A statement such as the interface was confusing is a starting point; the useful detail is what the person expected a particular button to do. We will recruit participants by sending an invitation to eligible customers who have agreed to receive research messages. Participation will be optional, and declining will not affect their account or support. We will offer the same thank-you payment to every participant, regardless of whether their feedback is positive or negative. The invitation will explain how the interview notes will be used and ask whether the participant wants to allow recording. Alongside the interviews, we will review existing support questions and the steps customers complete during setup. These records can help us decide what to ask, but they will not replace the conversations. A drop in activity tells us where something happened, not necessarily why it happened. The work will take four weeks. The first week covers recruitment and preparation. Interviews will run during the second and third weeks, with time between sessions to compare notes and adjust unclear questions. During the final week, we will present the findings and work with product and support to choose the next experiments. We will share observations during the project if a problem needs attention before the final report. The main deliverable will be a short report containing the recurring problems, the evidence behind them, and the limits of what we learned. Recommendations will name a specific change and explain how the team could tell whether it helped. We will also include cases that contradict the main pattern, since those differences may matter when deciding which customers an improvement will serve. Success means leaving the project with a few testable decisions rather than a long collection of interesting quotes.

These fictional drafts were written for the demo. The rewrites are unchanged API outputs. The notes flag problems we found when reviewing them. Prices are calculated customer charges before tax; our test account did not spend prepaid credit.

Recorded requests, responses and review notes

Before you add credit

What if the edit fails?

You pay nothing if a request fails or a rewrite makes no accepted changes. Any credit set aside for it is returned. If processing is interrupted, it can take ten minutes before that credit is available again when you check your balance.

Which editing level should I choose?

Start with Medium for everyday writing. Low costs less and suits routine edits. High offers more capability for demanding writing. Max is the most capable option and costs the most. Higher levels can also take longer; they do not guarantee a better result.

Do credits expire?

Credits have no scheduled expiry. Choose $4, $10, $25 or $50 and top up when you need to. There are no renewals. Credits cannot be transferred. For a refund of unused credit, contact the service owner through Nathan's website. Payment-processing fees may not be recoverable; applicable consumer rights still apply.

What happens to my text?

Estimating a price keeps your text in your browser. When you open the editor or follow its sign-in link, your draft is kept in this browser tab until you return to the editor. Editing sends your text and instructions to AI services. Paid results may be stored temporarily so you can retry without paying twice. Saved writing profiles keep the samples you choose to save.

Read about text handling and payment and storage details.

Building something with Unslop? See API pricing or read the API guide.