Tell us how we could make the product more useful to you. We URGE you to use the Pelcro Discovery GPT to help structure your thoughts and recommend a feature request that will be quickly digested by our team!
Have something to say?
Send SMS and Facebook Messenger Messages via Automations
π Problem Statement As a business user, I can only send campaigns to my segments over email, which limits reach to customers who don't engage by email. π‘ User Story As a business user, I want to send campaigns to my existing segments via SMS and Facebook Messenger, so that I can reach customers on their preferred channel. π― Definition of Done (DoD) β Given a segment in the automation tool, when a business user creates a campaign, then they can select email, SMS, or Facebook Messenger as the send channel and the message is delivered to that segment. β This change will impact UI, API, and Integration, specifically the campaign/automation engine and the Integration Orchestrator (Twilio for SMS, Messenger Platform API for Facebook). β This solution will include the following limitations: [clarify SMS provider]; sends to existing segments only; [clarify whether inbound replies are handled].
Improve collaborator on-boarding experience
The process for adding a collaborator in Pelcro is clunky and error-prone, especially for Pelcro clients with multiple accounts. When we hire a new employee, we often end up adding them as a collaborator on all of our Pelcro accounts. This results in them receiving 15 to 30 invite emails, and they must click a link in each email to confirm each account. Should they fail to do so, we must delete their collaborator record in each account, and re-add them to generate a new invite email. Here is what I would suggest: Pelcro should only send an invite email to the user if they have not yet set up their login details (name, password, etc). For users that fail to set up their login details, Pelcro should provide some mechanism for admins to re-send the invite email or some other way for them to finish the process. Adding a collaborator to additional Pelcro accounts should not put them in βpendingβ status and should not require them to click a link for each account. Nice to have: a centralized interface where admins can view/add/remove collaborators across all Pelcro accounts without having to switch between accounts.
Search function for collaborators
Please add a search function to the collaborators view so I can easily find existing collaborators by name or email. Background: Our Pelcro accounts have over 100 collaborators. The collaborators page only displays 25 at a time, so finding an existing collaborator often requires clicking through several pages of results.
Add first and last name to membership list export
Problem Statement The Membership List export does not currently include the customer's First Name and Last Name as separate columns, even though this information is already available on the customer record. User Story As a user exporting the Membership List, I want the customer's First Name and Last Name included as separate columns so that I can easily identify and work with member information in the exported file. Definition of Done Add First Name and Last Name as separate columns in the Membership List export. Pull both values from the associated customer record. Ensure the exported values match the names stored on the customer. Existing export columns and functionality remain unchanged. Feedback: We regularly export membership lists for group/corporate licenses and send them to customers so they can review and clean up the users on their license. The membership list export currently includes each member's email address but not their first and last name. Many members use email addresses in a first-initial-plus-last-name format (e.g. jsmith@company.com), which makes it hard for customers to tell who each user is. We'd like to request that first name and last name be added as separate columns in the membership list export. Current Behavior Customer search and customer export: First and last name appear for almost all of these users. Membership list export: Only the email address is included, with no first or last name. Why We Can't Use the Customer Export Instead We no longer delete customer records, so the customer export includes users who have been removed from a license but still exist as customers. The membership list is the only accurate source of who is currently on a license, which is why we need the names in that export specifically. Requested Change Add First Name and Last Name as separate columns in the membership list export, pulled from the customer record (where the names are already stored).
Improve Coupon Management & Flexibility
π Problem Statement Pelcroβs current coupon functionality has limitations that make it difficult to support more flexible promotional campaigns. Coupon activation is primarily controlled through dates, promotions cannot be scheduled at a specific time of day, and discounts on annual plans cannot repeat across multiple years before returning to the regular subscription price. Coupon functionality should be enhanced to provide publishers with greater control over activation, scheduling, and discount duration. π‘ User Story As a Pelcro admin, I want more flexibility when configuring and managing coupons, so that I can run different promotional strategies without manual workarounds. π― Definition of Done (DoD) βοΈ Active / Inactive Toggle Add an Active/Inactive toggle for coupons. Deactivating a coupon immediately prevents it from being used. Reactivating it allows it to be used again, subject to its other conditions. Toggle is available from the coupon management UI. βοΈ Start & End Date/Time Allow admins to configure a specific start date/time and end date/time. Coupon automatically activates and expires at the configured times. Supports time-sensitive promotions such as flash sales. βοΈ Multi-Year / Repeating Annual Discounts Support repeating coupon discounts for annual plans across multiple years. Admin can specify how many annual billing cycles the discount applies to. Example: apply a discount for 4 annual renewals, then automatically renew at the planβs regular price starting in year 5. Supports use cases such as student pricing and multi-year rate-lock campaigns. βοΈ Existing coupon functionality and previously configured coupons continue to work without disruption.
Sync Membership Address with Customer Default Shipping Address
π Problem Statement Customers currently cannot update the address associated with their active memberships when they change their default shipping address, particularly when the custom UI does not expose the memberships view. This requires customers to contact Customer Service to make the change. π‘ User Story As a user, I want active memberships to automatically use the customerβs default shipping address when it is changed, so that customers can update their membership address without needing to contact Customer Service. π― Definition of Done (DoD) β οΈWhen a customer changes their default shipping address, the new address is automatically assigned to their active membership(s). β The behavior can be enabled/configured through the appropriate Pelcro setting.
Consumer Data Platform/CDP
π Problem Statement As a publisher, I experience paywall targeting as a fixed attribute list set inside each individual paywall, which results in audiences I cannot express β anonymous readers with more than five page views in the last 30 days, for instance β receiving the same meter and gate as everyone else. π‘ User Story As a publisher, I want to define paywall targeting as a Pelcro segment rather than per-paywall attributes, so that an audience is described once and reused across paywalls. As a publisher, I want every attribute available in today's paywall targeting to also exist as a segment condition, so that deprecating paywall-level targeting costs me no capability I have now. As a publisher, I want to select a segment when I create a paywall, so that the paywall applies only to readers in that segment. [TBD: one segment per paywall, or several] As a publisher, I want to build segments over anonymous visitors from referral source and page-view frequency, so that I can target readers I know nothing else about. π― Definition of Done (DoD) β Given the segment builder, when a publisher creates a segment, then every attribute usable in paywall targeting today β country, platform, tag, URL, adblock β is available as a condition. β Given a paywall, when a publisher configures targeting, then they select a segment, and the per-paywall attribute fields are deprecated in the UI. β Given a reader in a targeted segment, when they load an article, then that paywall's frequency_limit and type_of_paywall apply instead of the untargeted paywall. β Given each segment condition type, we should make sure the data will be available and can be evaluated client-side at paywall time. β Given a paywall is displayed, when Paywall Displayed is logged, then the matched segment ID and applied meter limit are recorded. β This solution will include the following limitations: anonymous identity is per-browser and resets on cookie clear; activity events are logged-in only and retained 3 months; geo is country-level at decision time; per-segment products, plans and campaigns out of scope.
Trigger Renewal/Expiration by Shipments Remaining for Print Subscriptions
π Problem Statement As a publisher managing shipment-based print subscriptions, renewal and expiration are tied to end_date/renewal_date, which don't reflect actual shipments remaining. π‘ User Story As a publisher, I want auto-renewing (or scheduled-phase) shipment-based subscriptions to activate renewal automatically once shipments remaining hits 0, so subscribers aren't held to an unrelated date. As a publisher, I want non-auto-renewing shipment-based subscriptions to be marked expired once shipments remaining hits 0, so expiration reflects actual fulfillment status. π― Definition of Done (DoD) Given a print subscription is auto-renewing or has a scheduled renewal phase, when shipments remaining reaches 0, then renewal activates regardless of end_date or renewal_date. Given a print subscription is non-auto-renewing with no scheduled renewal phase, when shipments remaining reaches 0, then the subscription is marked expired. Given an existing print subscription currently tracked by end_date/renewal_date, when this change ships, then it is migrated to shipment-count-based renewal/expiration logic. This change will impact API / SDK, specifically shipment-based subscription renewal and expiration logic. This solution will include the following limitations: applies only to pure print subscriptions (no print+digital combined pricing plans); end_date and renewal_date are not used as renewal/expiration triggers for shipment-based subscriptions; manual early-activation override is out of scope (superseded by automatic shipment-count trigger).
[Merged] Customizable Invoice Due Date
[Merged into Configurable Invoice Due Dates for Subscriptions] π Problem Statement The default due date for subscription invoices is currently fixed at 30 days and cannot be customized. We need the ability to set a different default due date for all future subscription invoices. π‘ User Story As a user, I want to configure the default due date for subscription invoices so that I can choose a payment period that fits our billing workflow. π― Definition of Done (DoD) β οΈ Add an option to configure the default due date for subscription invoices, with options such as 30, 60, or 90 days. β The selected setting should apply to all future subscription invoices.
Add Test Send Option for Automation Emails
π Problem Statement The Send Email (via Pelcro) automation currently only provides a basic preview and does not offer a test-send option using a real customer from the segment. This makes it difficult to verify how dynamic variables, such as {{customer.magic_link}}, will render before activating the automation for a live segment. π‘ User Story As a user setting up an automation email, I want to send a test email using a real sample customer from the segment so that I can validate the email's final rendering and dynamic variables before activating the automation. π― Definition of Done (DoD) β Add a test-send option to the Send Email (via Pelcro) automation that allows users to send a test email using a selected/sample customer from the segment.
[Merged] Allow Partial Refunds for Prepaid Invoices / Advance Payments
[Merged into Improve/Add Controls to Refund Processing] π Problem Statement Pelcro currently only supports full refunds for future phases/prepaid invoices. This prevents users/admins from applying a partial refund when they need to retroactively discount a future order. As a workaround, we have been processing these refunds directly through Stripe, but refunds processed outside Pelcro do not create the corresponding credit note and therefore are not reflected correctly in the deferred revenue accounting. π‘ User Story As a user, I want to be able to issue partial refunds on prepaid invoices/future orders directly through Pelcro so that I can apply partial discounts or refunds while keeping the related accounting records accurate. π― Definition of Done (DoD) Users can issue a partial refund against a prepaid/advance invoice through Pelcro. The partial refund creates the appropriate accounting records, including the corresponding credit note and deferred revenue adjustment.
Support Tax Rates With Plan Bundling
π Problem Statement As a publisher, I need to apply different tax rates to individual line items within a bundled plan based on the product type, customer billing country, and VAT ID status. For example, a publisher may create a bundled plan priced at $100, consisting of: Print: $50 β 7% tax Digital: $50 β 5% tax The applicable tax rate for each line item must be dynamically resolved based on the customer's billing country, VAT ID, and the line item's content code/product type. Certain tax scenarios also require specific legal text to be dynamically added to the invoice. The tax calculation mechanism may be implemented through AvaTax or Pelcro's AI Tax module. π‘ User Story As a publisher, I want each line item within a bundled plan to have its tax calculated independently so that Print, Digital, and other components can follow their applicable tax rules. As a publisher, I want tax rates to be dynamically determined based on the customer's billing country, VAT ID status, and the line item's content code so that the correct tax treatment is applied. As a publisher, I want the appropriate legal text to be dynamically added to invoices when a transaction qualifies for a tax exemption or reverse-charge treatment. As a subscriber, I want the correct tax to be calculated for each component of my subscription so that my checkout total and invoice reflect the applicable tax treatment. π― Definition of Done (DoD) A feature is done when: Tax Calculation per Line Item β Given a bundled plan contains multiple line items, tax is resolved independently for each line item. Example: Create a bundled plan for $100: $50 Print $50 Digital The Print and Digital components can receive different tax rates depending on the applicable tax rules. β Tax resolution takes into consideration: vat_id billing_country content_code / product type β The resolved tax is calculated against the amount of the corresponding line item rather than against the bundle as a single taxable amount. β For bundled Digital & Print products, Print and Digital are evaluated independently whenever the applicable rules require different rates.
Introduce Bundle Manifest Report
Problem Statement The client uses a Truck Manifest every print day to determine the number and size of newspaper bundles required for distribution. The required bundle size varies by print day. Their standard bundle sizes are 30 copies on Sundays and 50 copies on Wednesdays, with the ability to change the size when the publication is heavier due to large or heavy inserts. Currently, there is currently no report that converts these quantities into the number of bundles and remaining copies required for distribution. The legacy manifest performs this calculation using total draw and standard bundle size. User Story As a Distribution Manager, I want to generate a Bundle Manifest for a selected print day, so that I can see how many bundles and remaining copies need to be prepared for each route. Definition of Done A new Bundle Manifest Report is available under Reports. The user can select a fulfillment creation/delivery date. The report is grouped by Vendor/Carrier β Route. Delivery points within each route are ordered by their existing Delivery Sequence. For each delivery point, the report displays: Delivery Sequence Subscriber / Account Name Delivery Address Phone Number Total Draw / Copies Bundle Size Number of Full Bundles Remaining Copies A default Bundle Size can be configured by delivery day: Sunday: 30 copies Wednesday: 50 copies Users can override the bundle size for a specific print/delivery date when needed for heavy or large inserts. Bundle quantities are automatically calculated based on the Total Draw: Full Bundles = Total Draw Γ· Bundle Size Remaining Copies = Total Draw % Bundle Size Existing Pelcro data is reused for Vendor/Carrier, Route, Delivery Sequence, Subscriber, Address, Phone Number, and Total Draw. The report displays totals per Route and Vendor/Carrier. The report can be exported/downloaded. Insert mix, returns, ad zones, and other legacy manifest fields are out of scope for V1.
Introduce Fulfillment Activity Report
Problem Statement District Managers need a daily operational report to review and follow up on circulation changes, including starts, stops, vacation pauses/restarts, and missed deliveries for each print day. Pelcroβs Bundle Tops already capture this delivery activity at the fulfillment level, including the associated vendor/carrier and route. However, there is currently no consolidated report that presents this information across fulfillments in an operational format similar to the existing District Manager Report. A generic Fulfillment Activity Report is needed to consolidate daily fulfillment activity and group it by Vendor/Carrier for all vendors. User Story As a District Manager, I want to view the circulation activity for a selected print day, grouped by Vendor/Carrier and Route, so that I can review and follow up on starts, stops, vacation pauses/restarts, and missed deliveries with the responsible carriers. Definition of Done A new Fulfillment Activity Report is available under Reports. The report is generic and is not tied to a specific fulfillment. The user can select a fulfillment creation/delivery date. Activity is consolidated across the relevant fulfillments and Bundle Tops for the selected date. The report is grouped as: Vendor/Carrier Route Subscriber activities Each vendor/route displays the applicable: Starts Stops Vacation Pauses Restarts Missed Deliveries Each subscriber activity displays: Subscriber Delivery address Phone number Quantity/Copies Activity type Effective/Delivery date Resume date, when applicable Totals are displayed per route for the supported activity types, following the approach of the existing District Manager Report, which provides starts/restarts/stops/complaint totals after each route/vendor. Totals are displayed per Vendor/Carrier across its routes. Existing Bundle Top data is reused for starts, stops, pauses, routes, carriers and resume dates. Missed deliveries are included using Pelcro's existing applicable delivery issue data. The report can be exported/downloaded. Legacy District β Zone β Region β Area rollups and legacy source/reason codes are out of scope for V1. Legacy District/Zone/Region hierarchy, source/reason codes, complaint-per-1,000 calculations and other legacy District Manager Report fields are out of scope for V1.
Add Ability to Write Off Debit Customer Balances
π Problem Statement Payment processors such as Stripe accept payments when the amount received is short by $0.50 or less, which results in the invoice being marked as paid. Pelcro then adds the remaining amount as an outstanding debit balance on the customer's account, which is carried over and included as an amount due on the customer's next invoice. Currently, the write-off functionality does not support writing off these debit balances. This can leave small outstanding balances on customer accounts, including test accounts that may never have another invoice to which the balance can be applied. It can also cause confusion for customers when these small balances appear on their accounts or are carried over to a future invoice. The client would like the ability to write off these debit balances when appropriate. π‘ User Story As a finance/accounting user, I want to be able to write off small debit customer balances, so that I can clear immaterial outstanding balances from customer accounts and prevent them from carrying over to future invoices or creating confusion in customer statements. π― Definition of Done (DoD) Users can write off debit customer balances through the dashboard, clearing the outstanding balance to zero.
Editorially-placed paywall break within an article body (inline "subscriber break")
π Problem Statement As an editor, I cannot choose where inside an article the paywall appears, which limits me to all-or-nothing gating per article. π‘ User Story As an editor, I want to insert a subscriber-only break at any point in an article, so that non-subscribers read only the content above it. As a publisher admin, I want only articles containing a break to be gated, so that free stories stay open without meter rules. π― Definition of Done (DoD) β Given an article contains a subscriber break marker, when a non-entitled user loads the page, then content below the marker is withheld and the embedded paywall renders at the marker. β Given an entitled subscriber loads a marked article, when the page renders, then the full article displays with no paywall. β Given an article contains no marker, when any user loads the page, then no paywall renders. β Given a search crawler requests a marked article, when the page renders, then the full article body is served, preserving current crawler-bypass behaviour. β Given an editor publishes an article, when they place the break in the CMS editor, then no Pelcro dashboard configuration is required per article. β This change will impact UI, SDK, and API, specifically Pelcro Elements embedded paywall rendering, JS-SDK content gating, and paywall product configuration. β This solution will include the following limitations: one break per article; marker authoring requires a CMS-side plugin or shortcode; client-side content withholding only unless server-side truncation is scoped separately; no A/B testing of break position; interaction with metered paywalls out of scope.
Allow Scheduled Renewal Phase to Start Early
π Problem Statement For shipment-based subscriptions, a subscription can reach 0 shipments remaining while there is still time left in the current subscription period. The renewal is scheduled to begin once the current period ends, but there is currently no way to activate the renewal early. This prevents the subscriber from being included in an upcoming fulfillment when the publisher needs to start the next shipment cycle before the current period ends. π‘ User Story As a publisher managing shipment-based subscriptions, I want to manually activate the next scheduled renewal before the current subscription period ends, so that subscribers who have exhausted their shipments can be included in an upcoming fulfillment without waiting for the current period to expire. π― Definition of Done (DoD) β Authorized users can manually activate the next scheduled renewal before the current subscription period ends. β The subscription moves to the renewal phase and receives the appropriate shipment allocation when activated. β The subscriber becomes eligible for the next fulfillment/shipment list. β Scheduled renewals continue to activate automatically at the end of the current period when no early activation is performed.
Saving skills to account settings in AI Agent
π Problem Statement As an AI Agent user running recurring reports, I must re-explain rules and business processes in every new conversation, wasting time and causing inconsistent output. π‘ User Story As an AI Agent user, I want to save reusable rules/processes to a shared project, so that new conversations reuse them automatically without re-explaining. As a teammate, I want access to shared project rules, so that I can run the same reports consistently without rebuilding context. π― Definition of Done (DoD) β Given a saved project with stored rules, when a new conversation starts within that project, then the AI Agent applies those rules without re-entry. β Given a project with multiple members, when a teammate opens the project, then they see and can use the same stored rules.
Expose payment_method_status, institutional_member & seat_status in webhook payloads
Problem Statement As a Pelcro integration developer, I experience three required fields being unavailable from the Pelcro webhook payloads when building ESP and CRM syncs, which results in either dropping the field from the integration or making an extra authenticated API call per event β added latency, rate-limit pressure, and a per-integration workaround instead of one platform fix. User Story As a Pelcro integration developer, I want payment_method_status, institutional_member and seat_status to arrive on the existing customer and subscription webhook payloads, so that any downstream integration can map them directly with no supplementary API calls. Definition of Done A feature is done when: Given a subscription with a payment method, when a subscription.* webhook fires, then the payload's payment method / source object includes status (chargeable / pending / failed / ...) matching that payment method's actual state in Pelcro. Given a customer holding an institutional or membership seat, when a customer.* or subscription.* webhook fires, then the payload includes institutional_member and seat_status, resolvable without a supplementary API call. [TO BE DETERMINED] β exact semantics pending client clarification, see Open Questions. This change will impact the API (webhook payload serialization in pelcro-core β app/WebHooks/Resources/, including SourceResource). No SDK, UI, or Integration changes in this task. This solution will include the following limitations: additive fields only, no existing field renamed, removed or retyped; no backfill or replay of historical webhook events; seat_status semantics for individual (non-membership) subscriptions remain undefined until the client confirms.
Pelcro Tickets vs Zendesk
π Problem Statement As a support engineer, I lack ticket triage, internal collaboration, and SLA visibility in Pelcro, which results in reliance on Zendesk for core support workflows. π‘ User Story As a support engineer, I want inbound emails to support@ to auto-create a ticket assigned to an agent, so that no request is missed or manually re-entered. As a support engineer, I want to add internal notes on a ticket, so that I can coordinate with teammates without exposing context to the client. As a support engineer, I want to set a Priority on each ticket, so that I can triage the queue by urgency. As a support engineer, I want Open/Pending/On-hold/Solved statuses with auto-reopen on client reply, so that ticket state always reflects reality. As a support manager, I want tickets to track first-reply and resolution time, so that I can report on SLA compliance. π― Definition of Done (DoD) β Given a Settings page for Support, when an admin selects a collaborator as the default ticket assignee, then that setting is saved and used for all future auto-created tickets. β Given an email sent to the support inbox, when it's received, then a ticket is auto-created with Source=Email, Status=New, and assigned to the collaborator configured in Settings. β Given an open ticket, when an agent adds a note marked "Internal," then it appears in the ticket timeline but is never sent to or visible by the client. β Given the Create or Edit Ticket drawer, when an agent sets Priority (Low/Medium/High/Urgent), then it saves and displays on the ticket and in the global list. β Given a Solved ticket, when the client replies via email, then the ticket status automatically changes to Open. β Given a ticket, when the first agent email is sent, then first-reply time is recorded from ticket creation to that timestamp; resolution time is recorded from creation to Solved.