Are you trying to use Perl 5.10 and the smart match operator? Here's the solution written with named captures, the nifty new 5.10 features that mean you never have to think about $1, $2, and so on. The names become keys in the new hash %+, and the matched text are the values:

#!/usr/local/bin/perl5.10.0

use 5.010;

my $text = "Grand Canyon   70%";

$text ~~ /
    (?<name>    .*\S        )
    \s+
    (?<percent> \d\d%       )
    /x;

use Data::Dumper;
print Dumper( \%+ )
[download]

The output automatically labels your values:

$VAR1 = {
          'percent' => '70%',
          'name' => 'Grand Canyon'
        };
[download]

Here's the boring Perl 5.8 way:

#!/usr/bin/perl

my $text = "Grand Canyon   70%";

$text =~ /
    (  .*\S    )
    \s+
    ( \d\d%    )
    /x;

print <<"HERE";
1: $1
2: $2
HERE
[download]

You can probably use the regex match operator "=~":

if (my @match = $text =~ /([A-Za-z\s]*)([0-9]{1,2})[%])/) {
  # do stuff here.
}
[download]

The regex above will capture trailing spaces in the $1 variable ([A-Za-z\s]*). It's probably easier to just get rid of them after the match, with $match[0] =~ s/\s+$//; otherwise you'll need a fancier regex :-)

IMO, it's "easier" to get rid of the trailing spaces (not required by OP, so Joost's correct answer is perfectly serviceable for the specs given) in the original match:

if ( $string =~ /([A-Za-z]*\s[A-Za-z]*)\s+([0-9]{1,2}[%])/ ) {
   print $1 . "\n" . $2;             #   ^
}
else ...
[download]

The double tilde ~~ operator is new in perl 5.10, so it won't work in any earlier version.

Damn. For a minute there I thought we'd run into an old awk programmer. But then, awk just uses a single tilde.

([A-Za-z]*\s[A-Za-z]*)\s([0-9]{1,2}[%])
[download]

For some reason I'm using the regex but its not working:

That is a pretty specific regex... will none of your text chunks be only 1 word? Also, the 2nd \s may cause a problem if the number is separated from the text by multiple tabs/spaces.

Again (cf above) making \s match multiple whitespace -- tabs or spaces, to judge from OP - is easily handled with a "+" after the second \s.

The point about the possibility of single word "text chunks" is well made... so long as the words "pretty specific regex" are not intended to deprecate specificity.

IMO, specificity is *GOOD* in a regex unless ambiguity (or at least, specific generalizations) are required because a less-than-specific regex can lead to hard-to-find problems where the source data includes unexpected content.

Consider,

H₂O     60%
or
Grand Canyon³     70%
or
Teller-Bose condensate     50%

Does one want the "water" entry or the footnoted "Grand Canyon" in the output?